WIP: Feature: deploy history

[anbraten]

Add deploy history exoframejs/exoframe#67 to list last x deploys.

Roadmap

Features

• [ ] list history

Bonus

• [ ] rollback
• [ ] rebuild
• [ ] restart
• [ ] scale: x instances of current deploy
• [ ] keep last x deploys running (could be nice for pipelines to be able to host prev versions)

Workflow redesign:

Deploying another instance each time you run # exoframe deploy feels somehow strange to me! I would like to suggestion the following workflow:

• exoframe.json is missing (first deploy) => cli asks for config generation, creates exoframe.json and deploys to the server
• exoframe.json exists in project => cli deploys to server, server detects running instance and starts update

A static url of a deployment would be nice as well (already requested in exoframejs/exoframe#275). Currently I can think of these options:

• {username}-{project}.example.org:
  • PRO: url can be easily guessed before deploying
  • CON: sharing the project (project name in exoframe.json) with git, etc. wouldn't allow the same user to deploy a second instance (you would have to change the project name to prevent an update) This however could be fixed in the future by adding the ability to scale deployments.
• {project}-{uuid}.example.org:
  • CON: cli would need to save uuid somehow locally (exp. {project-dir}/exoframe/config.json) to be able to update deployment
  • PRO: easily able to deploy multiple instance of same project
• {uuid}.example.org: (least favorite)
  • CON: url tells nothing about the project

@yamalight Any suggestions?

PS: I already changed code to only create one database file with all needed collections instead of multiple ones, except for the request token memory database. That shouldn't be a problem, should it?

[yamalight]

I've added a small comment to db code. IMO file-based approach would be easier to maintain.

exoframe.json is missing (first deploy) => cli asks for config generation, creates exoframe.json and deploys to the server

One of the points is to allow one command deployments for simple projects. This kinda breaks the flow. If you want to deploy with defaults - you just run exoframe. If you want custom config - you run exoframe config and set whatever you need. Not convinced this change is warranted 🤔

A static url of a deployment would be nice as well (already requested in exoframejs/exoframe#275).

Definitely want to have that, but that feels out of scope for this PR

[yamalight]

Main reason I suggested this change was to somehow remove the /update endpoint and handle all requests by the /deploy endpoint.

This separation exists for a reason - there are cases when you want to have same deployment executed multiple times. If you can suggest a way to merge those two, but still retain the functionality to do a second deploy under same project / URL - would be totally up for that 🤔

If we choose to store deployments without a uuid to a folder at "deploys/username/projectName", IMO the URL shouldn't use a uuid as well.

As I said - I'm totally up for that. I don't like UUID presence in URLs as well 😅 I just don't think it quite fits within deploy history feature

[anbraten]

This separation exists for a reason - there are cases when you want to have same deployment executed multiple times. If you can suggest a way to merge those two, but still retain the functionality to do a second deploy under same project / URL - would be totally up for that thinking

Could you give an example how and what you want to achieve by executing same deployment multiple times. Sounds to me like scaling. Maybe adding an option to config or a scaling-command would be a solution? Should a second deployment use the same project files and url?

[yamalight]

Sure. There are two cases here:

1. Scaling as you've said. Since there's no other way to scale right now 😅
2. Deploying new immutable versions of project (e.g. we have exoframe setup to deploy new version for each PR we open, then tear it down once it's closed). Uses same project, but generates new URL on every deployment.