Pipeline view of environments
Description
We currently show the list of environments, and which code is deployed to each. We can improve on the display a bit to convey upstream/downstream environments, and at the same time, add valuable information such as which merge requests are deployed to each environment, that are not in the downstream environment.
We support arbitrary deployment pipelines such as staging and production, but also UAT, QA, testing, whatever. Since we don't inherently know the direction of flow between environments, perhaps you could move the columns around to order the environments how you like.
We should show the current status of each environment, grouped by major category (review, staging, production), and let you trigger manual actions to promote between them.
Then a key value-add for us is to display the MR information for each environment. e,g. list out which MRs are in staging, but not yet in production.
Proposal
We can start implementing this for environments we are using for Auto DevOps (review/*
, staging
, production
) and then implement detection and ordering for any custom environment in a future iteration, based on the .gitlab-ci.yml
. This will give us some time to get feedback.
It will be a new tab in the Environments page, instead of just replacing the Available tab. This allows us to experiment more, and to see if our conventions are enough to guarantee users will not lose any information. If we keep the Available tab as well, users can use it as a fallback that fits any possible case. The view could be very similar to what shown in the mockup below (targeting a boarder vision we are not aiming to in this iteration), with a few changes to fit a first implementation:
- Review Apps, Staging, Production: groups that may contain more than one entry (actually plausible just for review apps)
- if a group has no environment, it is hidden
- each group is composed by environments, each environment is stacked vertically
- each enviroment reports basic information:
- name (link to environment details)
- url (link to deployment)
- the list of "new MR" that are still not in the next stage
- deploy status (instead of the deploy board, just a 1 line summary), like
100% operational
(optional) - commit (link to commit, author info, etc) (optional)
- pipeline status (badge + link to pipeline) (optional)
- a set of actions (rollback, promote)
I don't see the need of the stop action in this view, since it is not so common and could be probably more important in the detailed view for a specific environment. Also, we don't have this ability yet
The promote button is based on the next stage, so it will be the manual action targeting production
(this is the only case with fixed environments). But if we have incremental rollouts, we can support them properly turning the button into a dropdown button that will show you the possible options to rollout a specific percentage.
This is a mocked proposal, targeting a broader scope, but kept here until we have another proposal:
Notes
- I'm not sure the deployment pod status is necessary on this page.
- We can't detect review apps with 100% certainty. We suggest naming review app environments like
review/*
, but it's not enforced. We should degrade gracefully if not. For example, just call the column "Review" so it matches the rest of the column names and can be autogenerated however you name your folder. Maybe we hide the deployment information for any group of environments, which implies the current design would not show the nodes for Staging. Or maybe we just hide things that only have 1 pod. - Manual actions all have unique names that are user-specified in
.gitlab-ci.yml
. We could detect deploys between environments much like we do today for chat commands so we can still construct a Promote function.
Links / references
Plan of action
Redefining the problem to solve
Our core problem to solve is to show what is in an environment (production) in a way that is comprehensible to the user. (What would change if I would deploy X to production?)
Being able to identify merge requests will essentially make the comprehensibility of that comparison more effective. It is though not essential for solving the basic problem.
%11.1)
Stage 1 (MilestoneThe existing environments view already delivers on a way to know what is in a certain environment. However, it does not provide an easy way to show a comparison.
There is though an existing view which does provide an excellent comparison. The comparison view.
There are two ways to improve the environment page in order to solve this initial problem:
Show a summary
Compare all environments refs against a solid default => the default branch. Then show a summary of that comparison by default in the environments list view
This way it will be easy to gauge how far ahead/behind a certain environment will be VS the default branch.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/47881 (Issue created)
Provide an easy way to summon up a comparison view of environments
The current comparison view does not yet support environment refs. We can easily fix that with the following issues:
- https://gitlab.com/gitlab-org/gitlab-ce/issues/23508
- https://gitlab.com/gitlab-org/gitlab-ce/issues/31421
After that we should provide an option to summon up the comparison view to compare the environment with the "default branch" from the environments list view.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/47882 (Issue created)
%11.2)
Stage 2 (MilestoneWe will now have a basic way of comparing environments, with commits being the key information. There are now two ways to improve:
Stage 2-A
Be able to tie commits to merge requests.
The existing comparison view already defines a list of commits that are different between two refs. However, to make that view more comprehensible we could collapse commits that belong to a certain merge request and show that instead.
This way also rogue commits stay visible, making the solution more flexible and usefull from that start of a project (even if no merge requests are used yet!)
- https://gitlab.com/gitlab-org/gitlab-ce/issues/47884 (Issue created)
Stage 2-B
Create a pipeline view for environments similar to this.
We will create a list view that displays essentially the same information as our existing environments list view, but focusses in on only normal environments.
Display of environment will be based on .gitlab-ci.yml
info (stages, manual actions etc)
In other words it will essentially solve the following:
- The current list view of environments does not convey a flow from one environment to the next.
- This might make it possible to display comparison information and status data across environments more easily
See for a schema example:
┌───────────────────────────────────────┐ ┌───────────────────────────────────────┐
│ Stage name (staging) │ │ Stage name (Production) │
│ │ │ │
└───────────────────────────────────────┘ └───────────────────────────────────────┘
┌───────────────────────────────────────┐ ┌───────────────────────────────────────┐
│ ┌─────────────┐ │ │ │
│ │Manual action│─┼───┐ │ │
│ └─────────────┘ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ Environment │ │ │ Environment │
│ │ ├────▶│ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
└───────────────────────────────────────┘ │ └───────────────────────────────────────┘
│ ┌───────────────────────────────────────┐
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ Environment │
└────▶│ │
│ │
│ │
│ │
│ │
│ │
└───────────────────────────────────────┘
- https://gitlab.com/gitlab-org/gitlab-ce/issues/47888 (Issue created)
%11.3)
Stage 3/future (MilestoneWe will now have a proper pipeline environments view which we can extend on to solve additional problems.
Think of being able to show parts of the comparing view inline here or showing additional data pod health etc...
This is up to discussion.
Design
We'll progress with "Phase 1"
For that please see to the following sub issues: