Answers: <p>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.</p>
  
  <p>All is not lost... you can maximize the automation <em>around</em> the process, in order to minimize errors; all of the CD steps <em>except for</em> 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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-05-06T00:14:05.923Z
Answers: Yes, that's pretty much my assessment as well.  I was more curious how others with a CAB process dealt with things.
Answers: Erik Funkenbusch
Answers: CC BY-SA 3.0
Answers: 2017-05-06T00:15:53.763Z
Answers: Mostly by crying into alcoholic beverages. It's the eternal clash of management control against agile development.
Answers: Adrian
Answers: CC BY-SA 3.0
Answers: 2017-05-05T20:51:24.617Z
Answers: 2017-05-05T20:51:24.617Z
Answers: Adrian
Body: <p>I'm curious how others architect their DevOps practices in a strict change management environment, such as with a <a href="https://en.wikipedia.org/wiki/Change_advisory_board" rel="noreferrer">Change advisory board (CAB)</a> approval process.</p>
  
  <p>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?</p>
  
Tags: <continuous-deployment>
Title: Reconciling Continuous Deployment with strict change management policies
UserDisplayName: Erik Funkenbusch
ThreadText: # Reconciling Continuous Deployment with strict change management policies
  
  (Asked by: username_0 on 2017-05-04)
  
  I'm curious how others architect their DevOps practices in a strict change management environment, such as with a [Change advisory board (CAB)](https://en.wikipedia.org/wiki/Change_advisory_board) 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?
  
  **Tags:** continuous-deployment
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-05-05. Score: 7 | Accepted answer
  
  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.
  
  > **Comments:**
  > **username_0**: Yes, that's pretty much my assessment as well.  I was more curious how others with a CAB process dealt with things.  
  > **username_1**: Mostly by crying into alcoholic beverages. It's the eternal clash of management control against agile development.  
  
  ---
  
  