[RFC] From Releases to Deployments

[Janpot]

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:

• Instead of the "release" button, we provide a "deploy" button, after confirmation it will promote the current state to production, the underlying release management should be transparent for (CE) users.
• Instead of the releases tab, we provide a "deployments" tab, that lists all the previously made deployments, with the most recent one up top. Optionally, but not necessarily for CE we could provide for each deployment:
  • a permalink to view the app in that state
  • a rollback button to create a new deployment based on a older one

Relevant resources/benchmarks 🔗

Alternative to https://github.com/mui/mui-toolpad/issues/795#issuecomment-1229171634

[Janpot]

How is this different from releases:

• releases currently are about versioning, not about deploying. The list of releases is basically the list of versions through time, the latest one isn't necessarily what's deployed. This RFC instead proposes to make the list of deployments be a chronological record of the use of the deploy button, and therefore be less about "versioning" and more about tracking a history of pushing changes to rpoduction.

[apedroferreira]

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.

~~I don't think we need to have live preview apps for previous deployments.~~ Edit: but if it's easy actually it could be cool As for the ability to rollback, I agree we could allow rolling back to previous deployments/versions (paid feature or not). That should probably create a new deployment just like the one we're rolling back to, but with a new version number.

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.

[oliviertassinari]

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.

[Janpot]

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 👍

Hitting the nail on the head. Currently the underlying datamodel already separates both concepts. Practically it's a matter of

1. Shifting the UI from visualizing the "commits" towards visualizing the "deployments".
2. Creating a release and deploy at the same time

This won't be too big of a change