Deployment Approvals - Feature Direction (#6832) · Epics · GitLab.org

Deployment Approvals - Feature Direction

*This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*  This epic describes the overall deployment approval feature and its direction. It also tracks the items required to make this feature [complete](https://about.gitlab.com/direction/maturity/). ### Feature overview [Deployment approvals](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html) enable teams to add another level of protection for deployments and ensure compliance and separation of duties requirements are met. The feature builds upon the [protected environment feature](https://docs.gitlab.com/ee/ci/environments/protected_environments.html) and allows you to specify a list of approvers and a number of required approvals needed before a deployment can proceed to a particular environment, e.g. production. ### Problem to solve  Teams and organizations require garnering explicit approvals for deployments to particular environments. https://gitlab.com/gitlab-org/gitlab/issues/15819 explains how to implement manual approvals from the `gitlab-ci.yml` file but there is no visual representation on the UI. We want to enable users with the right permissions to approve or reject manual jobs from the environments page, with the option to leave annotations. The main use case for this would be to improve the approval workflow for deployments, production or otherwise. ### Intended users * **[Software Developer](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#sasha-software-developer) (Requester)**: As a software developer, I want my code to be approved to go into production quickly, so I can move on to my next tasks * **[Release Manager](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#rachel-release-manager) (Approver)**: As a release manager, I want to make sure every deployment that is approved to go into production is in order, so I can reduce risk to our system's reliability * **[Development Team Lead](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#delaney-development-team-lead) (Approver)**: As a team lead, I want to approve my developers' code to go into production quickly, without introducing unnecessary risks, so we can deliver value to customers faster  <details><summary>Click to expand other details that influenced the MVC</summary> ### Further details <details><summary>The gitlab.yml file </summary> ```yaml deploy_prod: stage: deploy script: - echo "Deploy to production server" environment: name: production url: https://example.com when: manual only: - master ``` </details> ### Proposal  For every stage that the `gitlab-ci.yml` file defines that approvals are required, the pipeline execution of that run should pause before entering a stage that uses the environment. On the **environments page**, an option would be added to approve/deny the manual job that targets that environment, only available to people in that access list. Users configured as approvers must review and approve or reject the deployment. If you have multiple runs executing simultaneously, each one must be approved or rejected independently. This action must be recorded in the audit log. <details><summary>Click to expand audit log proposal</summary> |Action| Details| |--|--| |Approval action | `approve/deny`| |The user | `username`| |Environment |`<Environment name>`| |Time| `timestamp`| |Stage|`pipeline stage`| </details> ### What this currently looks like <details><summary>Click to expand</summary> | Pending Manual Job on Pipeline Graph and Job Page | | ------ | | ![image](/uploads/db4cc7fb31c6422c5cd6bb5ad1347284/image.png) | | ![image](/uploads/93b72de608b5dcf64e135ac3ccde8987/image.png) | | Pending Manual Job on Environments page | | ------ | | Manual job is not visible on environment page, even though it shows on pipeline list as `skipped` | | ![image](/uploads/d0f8f8163afcc9af57d13989afdfbd98/image.png) | | ![image](/uploads/2f59fc7672d09d22caf4760e6d3ce9cf/image.png) | </details> ### What we are currently missing | Feature | Part of MVC | |------|------| | Approval/Rejection interface | Yes | | Audit Log | Yes | | Add approval/rejection message (to be added as an MR comment) | No | | Notifications that your approval is required (TODO, email, slack...) | No | **Notes** - If a protected environment has has a “Deploy to” dropdown as one of its [action buttons](https://gitlab.com/gitlab-org/gitlab/-/issues/335228), then it should be disabled. - If a user rejects the manual job, we can either force it to fail, or create a new job status of `rejected`. [From the docs](https://docs.gitlab.com/ee/api/jobs.html), this is what we currently support: | Attribute | Type | Required | Description | |-----------|------|----------|-------------| | scope | string or array of strings | no | Scope of jobs to show. Either one of or an array of the following: created, pending, running, failed, success, canceled, skipped, or manual. All jobs are returned if scope is not provided. | #### Possible Future Iterations - Enable turning comments mandatory for allow/deny by adding a setting to environment YAML - Add rich-markdown editor capabilities to comment box (@mentions, smart links, etc) </details> ### What does success look like, and how can we measure that? Deployment approvals/rejections are widely adopted and usage can be measured by usage ping. Further customer research shows how users are successfully adopting this feature into their workflows, and how we can improve upon it.  ### Available Tier ~"GitLab Premium"  ### What is the type of buyer?  - [Alex - the Application Development Manager](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/buyer-persona/#alex---the-application-development-manager) - [Casey - the Release and Change Management Director](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/buyer-persona/#casey---the-release-and-change-management-director) - [Skyler - the Chief Information Security Officer](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/buyer-persona/#skyler---the-chief-information-security-officer) ### Feature direction #### Today The feature is working in production and can be used but there are certain improvements we want to complete to make the feature support common use cases, the UI streamlined, and easy to configure. #### Upcoming iterations * Being able to see approval and comment history * https://gitlab.com/groups/gitlab-org/-/epics/8533+ * Improving the workflow to ensure the deployment pending approval is always visible * Allow common configuration in the UI * Notifications * Group-level configuration ### Links / references * https://docs.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops * https://codefresh.io/continuous-deployment/manual-approval/

epic