Reconciling Continuous Deployment with strict change management policies

Question

I'm curious how others architect their DevOps practices in a strict change management environment, such as with a Change advisory board (CAB) approval process.

I understand that automation can improve your audit process by guaranteeing a more rigorous, provable, and repeatable process. But it feels like Continuous Deployment is more or less impossible in such a situation. Since it can take a week or more to get changes approved, you lose the ability to deploy fast and often. What steps do you take to work within these processes short of just submitting change requests and waiting for approval?

Answer 1

If you must adhere to the change process, you'll be limited according to the limitations of the change process, full stop. If changes must be approved prior to deployment, you cannot do continuous deployment. If approval takes a long time, you cannot deploy quickly. There's no workaround whereby you can both follow the process and not be impacted by it. That's the cost of following the change process, and it's a cost worth bringing to the attention of the stakeholders in that process.

All is not lost... you can maximize the automation around the process, in order to minimize errors; all of the CD steps except for the linkage between generating a stable artifact and deploying that artifact to production. That linkage would be replaced by either some kind of user intervention (button, CLI command, etc.), or linked to the record of approval (e.g. when a change request ticket is moved to the "approved" state, fire off the associated deployment). You just have to squeeze as much benefit as you can out of it, while following whatever mandatory process you've been saddled with. It won't make approvals go any faster, of course.