Connection between releases and environments/deployments
Release notes
Problem to solve
As a user, I want to understand what release is deployed to what environments, so that I can better manage my application.
Intended users
User experience goal
The user should be able to connect understand what deployments and environments and connected to specific releases in the API and UI.
Proposal
Create a connection between Releases and Environments/Deployments.
Further details
GitLab has the concept of releases and also has a separate concept of environments/deployments. These two concepts are currently independent and have no first-class association/integration with each other.
Today with GitLab, it is a long process to look for SHA in the release, and then look for it in the environment pipelines, which is a challenge for non developers.
Users want to understand what release is deployed to what environments and be able to roll them back if there was issues deploying.
There are lots of things GitLab could do with this extra info:
- On the Releases page, show which environments are currently running the release
- On The Environments page, show which release is currently deployed to each environment
- On the Releases page, each release could have a "deploy to" action, which deploys the release to an existing environment
- Rollback an environments to the previous major/minor/patch release
- "Release pipeline" view, which shows how a release moves through environments (including manual approvals)
- For example:
dev→qa→staging→ manual approval →prod
- For example:
- Drag and drop a release onto an environment
Releases and deployments both have reference to a Git SHA. This SHA could be used to join a release to a deployment (and vice-versa).
A concrete next step would be to add this association to the GraphQL API:
- Add a
deploymentssub-property to the release type, which fetches all deployments for the given release - Add a
releasessub-property to the deployment type, which fetches all releases for the given deployment
Note: this relationship would be many-to-many, since multiple releases and multiple deployments can all be associated with the same Git SHA.
Permissions and Security
-
Add expected impact to members with no access (0) -
Add expected impact to Guest (10) members -
Add expected impact to Reporter (20) members -
Add expected impact to Developer (30) members -
Add expected impact to Maintainer (40) members -
Add expected impact to Owner (50) members
Documentation
Yes, this will require an update to our docs - Technical Writing