Best practices for automated change management
Change management automation is an important part of the DevSecOps pipeline reference implementation. Developers, approvers, and auditors can monitor the compliance aspects of deployments. Every deployment must follow an organization's change management policy.
The pipelines collect evidence from every part of the build and deployment lifecycle. Every piece of evidence correlates to a specific build and deployment of the artifacts. So, for each deployed artifact, you can tell if its build or test deployment has incidents. This correlation is implemented through the inventory model.
Change management data flow
The following image shows the data flow and connection between evidence, inventory, and change management.
- Continuous Integration (CI) runs build artifacts and leaves evidence of what happened during the creation of those artifacts.
- CI runs create entries about the created artifacts in the inventory.
- Built artifacts in the Inventory are promoted to deployment environments, like staging or pre-production.
- Change management automation uses data from the inventory, the evidence locker, and the promotion PR to create the change request deployments. Change management automaton also leaves evidence of acceptance tests, for example. Successfully deployed and tested artifacts are further promoted to production environments.
Every deployment to every environment and region must file a change request on the Change Management System. Change management automation helps you to create change requests based on all the evidence and information that is collected from the pipelines. For more information, see Automating change management.
Change management command order
The sequence of change management command order are an important part of the DevSecOps pipeline implementation, and every deployment must follow an organization's change management policy to ensure compliance. The following command order is a guideline for how to handle change management.
Create change request
Everything that changes the baseline must be tracked by using a change request. The changes include, for example, updates to the existing code level, changes to the configuration, and updates of the worker nodes. Collecting peer review compliance data is based on the data that is accessible in the inventory, the evidence locker, and the incident issue repository.
Finally, this step creates the change request that is based on the Promotion PR fields, and attaches available compliance data. Deployment readiness is calculated by the collected compliance status, based on the available evidence.
Request for approval
If the created change request deployment state is not ready, this step requests approval for the change.
Check for approval
If every compliance check (for example, unit test, CRA tasks, branch protection, detect secrets) is successful, the change request is approved automatically, and the task runs successfully.
If a compliance check fails, the change request state is not approved.
You can approve the change request manually and add the change-request-id to the environment properties to use the already created change request in the next run.
Another solution is to use the emergency label in the promotion pull requests. For more information, see Add emergency label.
Set to implement
This step sets the status of the change request to implement depending on the success or failure status of the change.
Close change request
Details about the deployment are uploaded to the closing summary change task, and the change request is closed. In the close change request task, the close_category is added with these values:
successfulsuccessful with issues(if the summary has issues)