Redeploy and roll back
Both actions live in a deployment's menu, and both create a new deployment rather than changing the one you chose. The difference is what they carry forward.
| Redeploy this commit | Roll back to this deployment | |
|---|---|---|
| Available on | Any settled deployment. | A Previous deployment that went live, while its image is still available. |
| Commit | The deployment's commit. | The deployment's commit. |
| Image | Built again. | The image it already built. No rebuild. |
| Variables | The service's variables as they are now. | The variables that deployment ran with. |
| Build settings | The service's settings as they are now. | The settings that deployment ran with. |
Redeploy
Choose Redeploy this commit to build the deployment's commit again using the service's current settings and variables, then move production traffic to it. This is not a rollback: anything you have changed since is picked up.
It is the answer to Runtime configuration has changed on the service's Variables tab, where the same action is offered as Redeploy now. It is also how a build that failed for a transient reason is tried again.
A redeploy deploys the deployment's commit, not the head of the branch. To deploy the newest commit, push, or choose Deploy on the service.
Roll back
Choose Roll back to this deployment to deploy that release again using the image it already built, and move production traffic to it once it is healthy. Your current deployment keeps serving until then.
A rollback restores the release as it was: the image, the build configuration and the variables it was prepared with. That last part is the one to remember. Rolling back past a changed secret restores the old value, because the previous deployment's snapshot is what runs.
Kuppit keeps the image of every deployment that went live, so any Previous deployment can be rolled back to. A deployment that never went live, or whose image is no longer available, cannot.
While a deployment is in flight
A service runs one deployment at a time, and rollback gets no exemption. If a deployment is in progress, redeploy and rollback are refused with Cancel the deployment in progress before redeploying or before rolling back. Cancel it, wait for it to settle, then roll back. Two steps, each of which visibly finishes, rather than a rollback racing the deployment it is trying to undo.
A deployment that has already started moving traffic cannot be cancelled; roll back once it has settled.
What each one records
Every deployment shows its trigger, so the history reads honestly: Git push, Pull request, Manual, Redeploy or Rollback. A rollback appears as the newest deployment of an old commit. Nothing about the deployment you rolled back from changes: it becomes Previous and can itself be rolled back to.