Allow Owners/Maintainers to approve Deployments that were created by themselves
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Problem: Owners (most privileged users within a project) are unable to deploy their own changes into a protected environment.
Problem to solve
Problem: Owners (most privileged users within a project) are unable to deploy their own changes into a protected environment.
Relevant Support Ticket: https://support.gitlab.com/hc/requests/326523
Proposal
Proposed solution: Either create more granular configurations in the project settings that allows admins to decide whether this restriction should be in place, or, allow the general ability for owners to override this restriction. (much like when an admin can override merge restrictions in GitHub)
I feel it would be reasonable to allow administrators to decide whether this restriction is in place, or override the default restriction. While I understand its purpose, GitLab shouldn't be able to make that decision for a team. Every team has different rituals and processes, and an owners/maintainers ability to deploy their own code changes to protected environments should be decided at a team level, not by the GitLab product itself.
Intended users
There are several users/personas who would benefit from this change: In order of priority:
1.) Delany (Development Team Lead) The Development Team Lead in certain organizations may be tasked with an after-hours deployment to fix a major issue in production. With the current environment protections in place, the Dev Team Lead would need to wake up other teammembers after-hours or wait until normal work hours while an issue in production persists and affects users and stakeholders.
2.) Priyanka (Platform Engineer), Rachel (Release Manager), and Ingrid (Infrastructure Operator) All three of these roles may be making edits to the codebase that are relevant to the DevOps systems in place, infrastructure configuration, or other changes that aren't directly relevant to the code of the product itself. They have the ability to review each other's code before merging and look at the results of the changes in the CICD jobs/pipelines. On a particularly small team, one person might fill all three of these roles, and therefore could not have someone else available to approve the changes that they made.
Feature Usage Metrics
n/a so far.