Before an application makes its way into production, it usually has to take an “exam” before moving into the next environment. These exams can come as testing criteria, or simply as stakeholder agreeing that the application is ready for the next environment. These “exams” are better known as deployment approvals and gates.
Deployment approvals are created in a process that specifies the job that needs approval and the role of the approver. When a request for approval is made, the users with the corresponding role are notified of the work item through email. The approver has the liberty to approve or reject a deployment as well as provide comments to the decision.
Approvals provide more visibility into deployments for audit trails. The approver can view the name of the process, when the deployment was requested, who requested the process, the snapshot or version used in the deployment, and the details of the environment, resource, and deployment target.
Approval behavior will differ based on schedule deployments and non-scheduled deployments. If a process with an approval does not have a scheduled deployment time, the process remains idle until a response is made. When a scheduled deployment that requires approval reaches its start time and the approval is not given, the process does not run and acts as a rejected request.
If a request is rejected, the process does not run. If approved, the process begins.
In IBM UrbanCode Deploy, you can specify the conditions that must be met before the application can be promoted to an environment by establishing gates. Gates are defined at the environment level; an environment can have a single gate and or conditionals. Gates provide a mechanism to ensure that:
- Component versions cannot be deployed into environments unless they have the gate-specified status.
- Applications reflect the agreed upon quality criteria for promotion.
- Applications that advance have auditable sign-offs.