Show Deployment Rollback/Re-deploy labels
Problem
This is a long standing UX and backend issue and recently brought-up in an MR, which should be a part of environments page improvement epic.
GitLab CD has a feature to rollback to an older version of deployments. The concept is to re-deploy a stable version on a production environment when operators figured out that something went wrong on the latest deployment, however, this feature is still pretty bare bone that is not practical in actual deployment practices.
For example, a project has the following deployment history:
- Deployment ID: 2, Version: SHA-2 (latest)
- Deployment ID: 1, Version: SHA-1
Now, an operator re-deploys ID: 1
and GitLab triggers a new pipeline job to execute a deployment script with SHA-1
(an older source code):
- Deployment ID: 3, Version: SHA-1 (latest)
- Deployment ID: 2, Version: SHA-2
- Deployment ID: 1, Version: SHA-1
What's confusing here is that ID: 3
is latest in terms of deployment records, however, it's NOT latest in terms of Git versioning. In general, developers and operators want to keep the production environment up-to-date with the latest source code, but it's not obvious in the UI that the latest deployment is actually associated with an older source code.
Proposal
We show "rollback" labels to deployments that were triggered by rollback action, for example:
- Deployment ID: 3, Version: SHA-1 (latest, rollback)
- Deployment ID: 2, Version: SHA-2
- Deployment ID: 1, Version: SHA-1
A sample image:
In addition, we should show these information:
- The "rollback" label should link to the original deployment. e.g.
ID: 3
was initiated byID: 1
.
Technical Proposal
backend adds the rollback_by_id
column (bigint, default NULL
) in deployments
database table. We set it to an existing deployment record ID if SHA matches (i.e. when a deployment record was created from rollback action).
FYI, we shouldn't dynamically calculate the "rollback" status with Gitaly, as it's likely to be a bottle neck on performance.
Further improvement
This rollback tracking in database records will be beneficial in a long run that we can accomplish more complex filtering/searching in deployment page. For example, we can know:
- Show Mean Time to Restore stats
- Show Rollback frequency
- Annotate Stable/Unstable deployments. e.g. Deployment records that are sandwiched by an initial deployment and a rollback deployment are considered as unstable. Otherwise, it's stable.
- etc