"What about our compliance controls?" For DevOps evangelists, this refrain is a fear we know all too well when people from info-sec or release management first hear of DevOps. This question is a critical one, and part of a larger risk management conversation. With continuous delivery and DevOps in general likely to increase the rate of change in production, the risk of change must go down as well.
Failure to account for these controls is one of the most common causes of failure for developer lead continuous delivery initiatives. On the other hand, in the brief case studies I presented in last week's DevOps Teams webinar it was clear that in successful DevOps adoption efforts, compliance was top of mind. At the health insurer, they made the info-sec guys allies early in their delivery pipeline effort by demonstrating how the existing controls could be easily circumvented by a clever developer and how the pipeline would be more secure. For the tech company, the goal of streamlining compliance processes was explicit in their mandate to boost developer productivity.
The challenge then is to build controls into how you deliver that enable you to go faster while decreasing risk. A control meant to protect quality by requiring sign-off from the head of QA on any release, may turn into a series of automated tests that the head of QA has certified are good enough if they pass. The same protection is in place, but what was once a manual check becomes automatically enforced.
For more on this, check out the recent article "Towards Compliance as Code" by Jim Bird.