-
-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] From Releases to Deployments #868
Comments
How is this different from releases:
|
I think this proposal makes sense, even though deployments should probably just be something like automatically versioned releases? I think that's how Heroku, for example, works, it automatically assigns a new version number to each deployment.
And if there are changes in the live "working-version" of the app compared to the latest deployment, we could maybe show this temporary version at the top of the "deployments list", but marked as "not-deployed"/"undeployed changes"/something like that, or show it in some other way. |
The direction this RFC is going is interesting. What I hear is that our "Releases" currently merge two different notions, each equivalent to: git commits and Netlify deployments. We could focus on deployments. A deployment would create a commit, only that there can't be a commit that is not deployed. Sounds simpler π Now, I don't think that this directly closes #795, since this issue stated from https://www.notion.so/Toolpad-Pricing-50df8f336b3d4120b8df8a8cef0b7fa9?d=0af1ff513e5b4bdf9bfe3f748d10035d#de48ce63c7c34c149c2aa68a57299e9d. If we consider that the community plan is about spinning the contributions flywheel, we have to have enough features for the basic use cases. What does a user with a basic use case need? I think that it needs to allow you to undo your mistakes, there wouldn't be a worse DX if it was not the case. But to deploy an older version? Personally, I didn't need it, so far, with Pipedream (I needed a git reset of my working environment) same with Toolpad. |
Hitting the nail on the head. Currently the underlying datamodel already separates both concepts. Practically it's a matter of
This won't be too big of a change |
What's the problem? π€
Releases are a too high level concept for basic users. We should support the simplest workflow to promote your app to production. For pro plan we can think of more elaborate use cases
What are the requirements? β
A user must be able to "save" the state of their application to share with stakeholders without locking themselve into being blocked from making any changes.
What are our options? π‘
We currently have the releases, where we let users create snapshots and have them switch freely between them to designate one production snapshot.
Proposed solution π’
We would focus less on releases and more on the "deployment". This would simplify the way users think about the app lifecycle. Working in the editor would "stage" the changes, and a deploy button would promote the state to production. Concretely:
Relevant resources/benchmarks π
Alternative to #795 (comment)
The text was updated successfully, but these errors were encountered: