Multi Access Levels in Deployment Approval (API-base)
Release Notes
Previously, the deployment approval feature supported a simple model where the ability to execute a deployment and to approve a deployment were both controlled with a single list of users. With this update, you have more flexibility with these rules and can specify multiple levels for control using the API. One particular model is when there is separation of duties between deployment executors and approvers in your organization. Another model is when approval is needed separately from multiple levels such as a QA tester group and a security group.
Problem
In the initial MVC, both Deployment Executors and Deployment Approvers were managed in the same access level. This could be a problem that Approvers can accidentally gain an access to the critical environment, where they are supposed to approve/reject only. To resolve the problem, we should separate access levels between executors and approvers. For example:
- Production Environment:
- Who can deploy?: @operator-group
- Needs approval for deployment?:
- At least one approval from @qa-tester-group
- At least one approval from @security-group
Proposal
Let users to define separate lists. To illustrate:
production environment:
- Required one approval from @qa-group
- Required two approvals from @security-groupand the deployment job won't be triggered until all of the approval conditions are satistifed.
Technical Proposal
Add protected_environment_approval_access_levels table as a clone of protected_environment_deploy_access_levels table. The functionalities are the same, but the data can be distinguished.