Releases as first-class entity MVC
Problem to Solve
We do not have a way to directly handle release management within GitLab today; you can see how we do release management using GitLab at gitlab-org/release/tasks#462 (closed) & gitlab-org/release/tasks#460 (closed). This works, but is not the most effective way to solve this problem from a product perspective. The capabilities that those release issues bring are:
- Defining the sequenced deployment steps for the release; some manual and some automated
- Configuration associated with the release that needs to be applied
- Defining the content of the release (for us, artifacts from pipelines built on branches in several projects)
From a meta perspective, this process also provides a template from which you can start a new release that is guaranteed to be consistent/have best-practice learnings in it
It would be better if, instead of a checklist in an issue, the release pipeline was a special case of an actual pipeline that supported automation and all the other great features that an actual pipeline brings.
Identify way to create and manage a new "release" entity in GitLab that contains the following:
- A pipeline to implement the sequenced deployment steps
- A collection of project deliverables, containing:
- Configuration associated with the release (or a way to point to the latest approved configuration)
- Artifacts associated with the release (or a way to point to the latest approved artifacts)
The pipeline should be defined just like a
gitlab-ci.yml in terms of defining stages and tasks. They will be different because there will be more manual steps, but these are already supported. One big difference will be either a work-back or work-forward due date for each step. For example, if your very simple release is composed of 3 steps: A, B, and C, you should be able to set a due value on each item. This could be relative to the start or planned end date of the release - for example, A and B may be due 2 weeks before the release date and C may be due the day of.
The way to point to artifacts/configuration is via a collection of projects and associated milestones within those projects. This would be the best way to do it because it would give us insight into issues and anything else in GitLab that relies on milestones. This presents a challenge for teams that use sprint milestones but not release milestones; they would need to start creating release milestones.
It should be possible to create, view, and edit these entities.
There are two important views for a release:
- For the jobs in the release pipeline, how they are tracking against due dates/release date. Are they done or overdue? This lends itself to a timeline view. Here is what a similar job view looks like in XL Release. Otherwise, this view can look the same as current pipeline views.
- For each project artifacts/configuration in the release, what is the status of the last build? What % of issues in that release milestone are closed?
For an MVC, we may be able to leave the release pipeline and associated view out, and only create the new entity containing pointers to milestones in a collection of projects and that view.
- Where is the release entity defined? For single-pipeline release processes, it makes sense to have it in the same repo. For multi-project release processes, probably it would go in its own project or exist at the group level.