WIP: Feature: deploy history #38
Conversation
| } | ||
|
|
||
| // get or create deploys collection | ||
| deploysCollection = db.getCollection('deploys'); |
There was a problem hiding this comment.
I initially though of using file-based catalogue of deploys.
I.e. you'd have a top folder projectName and nested 3-5 folders with dates as name corresponding to deployments.
This way you don't need to maintain a DB (and its relation to files) and can easily figure out when a deploy happened and what files need to be used to run it.
Thoughts?
There was a problem hiding this comment.
Okay, I will first try whether it works with files. Adding data to the database later doesn't sound too complicated to me.
|
I've added a small comment to db code. IMO file-based approach would be easier to maintain.
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
Definitely want to have that, but that feels out of scope for this PR |
There was a problem hiding this comment.
I think I got your point of the single command to deploy idea.
Main reason I suggested this change was to somehow remove the /update endpoint and handle all requests by the /deploy endpoint.
This way the server would decide whether to deploy a new instance if username/projectName wasn't found or to update an already deployed instance.
If no exoframe.json config is found inside the current folder projectName could be the current folder name.
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
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.
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 🤔
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 |
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? |
|
Sure. There are two cases here:
|
Add deploy history exoframejs/exoframe#67 to list last x deploys.
Roadmap
Features
Bonus
Workflow redesign:
Deploying another instance each time you run
# exoframe deployfeels somehow strange to me! I would like to suggestion the following workflow:exoframe.jsonis missing (first deploy) => cli asks for config generation, createsexoframe.jsonand deploys to the serverexoframe.jsonexists in project => cli deploys to server, server detects running instance and starts updateA 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: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:{project-dir}/exoframe/config.json) to be able to update deployment{uuid}.example.org: (least favorite)@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?