Continuous Delivery NOT Continuous Deployment is key to successful DevOps
In this consumer driven era businesses are turning to DevOps to help them keep up with the demand for new software, features and functions, and to enable them to respond quickly to shifts in their markets. Most companies interpret this as needing to move to being “Continuous” but are unsure as to whether they should be implementing Continuous Delivery or Continuous Deployment.
What’s the difference?
Continuous Delivery (CD): Having the ability to deploy a change to production at any time. However, this does not mean that you deploy each change to prod.
Continuous Deployment (CDep): Deploying every tested change to production automatically.
Continuous Deployment is an evolution of Continuous Delivery where the decision process is typically automated and binary. For example test(s) passed = deploy / test(s) failed = don’t deploy. The diagram below by Carl Caum from Puppet Labs shows this small but significant difference clearly:
Continuous Deployment typically encounters resistance in companies under significant compliance or regulatory scrutiny. Production environments are ring fenced and segregated in what is ultimately a simple way of meeting perceived regulatory requirements. A CD pipeline requires an automated deployment solution spanning the lifecycle of an application from development through to Production. This brings DevOps into conflict with this traditional status quo. What we find most interesting as a DevOps solution provider and the key to this blog post is that once our customers understand the difference between CD and CDep the majority choose Continuous Delivery. They are telling us they’re looking for “the ability to deploy change on demand” with the confidence that the deployment will be accurate, tested, reproducible and traceable and not adversely impact the target environment or service. By definition this is Continuous Delivery and not CDep as it is the ability to deploy, not the act of deploying. The resistance to continual production deployments is not due to fear but instead concern about the associated overhead.
Continuous Deployment effectively means a larger number of smaller deployments. Whilst the “small batch” concept is a key component of the “lean” methodology there is a point at which greater deployment frequency can lead to diminished benefits. When something is deployed to production the full scope of the change must be deployed. You would not for example deploy a front-end change adding a field on a form without the corresponding database change adding that column to the database. Similarly if you are deploying 50 times a day and faults are reported with your systems there is an overhead in identifying exactly what was deployed at the time of the issue. What we’re experiencing is that many companies are satisfied with their tools and processes for managing development activity and scoping of releases. There are many well established methodologies and tools at this end of the lifecycle and there is limited appetite to change what is in place for the little or no perceived benefit that Continuous Deployment provides. When introducing change to organisations the adoption of that change is critical. Focusing on areas where maximum value will be derived gives a far greater chance of success.
One such company we worked with is an online Payroll & Benefits provider. During peak hours have 10,000+ customers logged into their web portal. Optimising Deployment duration and downtime were key requirements for their new CD/CDep pipeline. There starting assumption was CDep would clearly be more beneficial and that is where the project was focused. Once the differences between CD and CDep were clear the dramatic increase in the frequency of deployment to Production was positively rejected. Their reasoning was very simple. “If we get the same quality of deployment with CD as we do with CDep but we would require changes in our development process for CDep why would we adopt it?” The project was refocused on delivering a CD pipeline with a more aggressive goal of zero downtime rolling deployments and with the addition of on demand infrastructure provisioning (including application components and data). They achieved an improvement in deployment time from 6 elapsed hours of 6-8 skilled resources time to 45 minutes with zero downtime with a significant reduction in quality issues. Deployments are now executed as necessary including in the middle of the business day.
Time will tell if the practice of Continuous Improvement will once again shine the spotlight on the Deployment step of the delivery pipeline as all others are optimised. For now however our recommendation driven by customer feedback is that Continuous Delivery is the key to succesful DevOps.