What is Continuous Deployment?
Companies like flickr have in the past posted on their blog how many ‘deploys’ they had so far that day/week. Looking at the an organization that deploys to production 89 times in a week can be very intimidating. More importantly, it begs to ask – what do you deploy to production 89 times in a week?
This is a scenario that may actually keep some people away from adopting DevOps practices as they believe that they have to deploy every change to production. That is certainly not the case. First, you need to understand what is being deployed here and second, more importantly need to understand that this is not applicable, necessary or in some cases even feasible, for every organization.
What does one deploy ‘89 times’ a week?
When an organization says they are doing double-digit deploys to production every day, it does not mean that they are delivering tens of new features or bug fixes every day! What these companies have adopted is true and full-fledged Continuous Deployment. That means, every change by every developer works it way all the way out to production. These may not be complete features – several such changes by multiple developers, over days may make up a complete usable feature. They may not be visible to a customer at all – it is only after the complete feature is available and tested would it become visible. Then too, it may be a part of an A-B test effort, so only a few customers ever see it. The deployment may alternatively be a simple configuration or database schema change, that is never ‘seen’ by anyone, except it changes some performance or behavior. Yet another scenario is where the deployment is a deployment of a new environment change and not an application change at all – an OS or middleware patch, OS level configuration change, new OS version, whole new architectural topology of nodes, etc.
Such a process is not viable for many organizations. Your organization may have some (water-SCRUM-fall like) requirements and policies that requires a manual approval process before deployment to production. You may require a ‘segregation of duties’, that mandates that the person to deploy to production is a different person/team from the one who contributes to the development of the deployable asset.
To Continuously Deploy or not?
There is massive confusion between the concepts of Continuous Delivery and Continuous Deployment. Let me begin to ease the confusion by quoting a recent tweet by Carl Caum of PuppetLabs:
Continuous Delivery doesn’t mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time
This tweet in a simple (less than 140 character) set of sentences captures the essence of what SHOULD be done vs. what MAY be done, by your organization. Going by this distinction, Continuous Delivery is a MUST, Continuous Deployment is an OPTION. Having the capability to continuously Deploy is more important than actually doing it in a continuous manner out to Production (key word here is Production). Carl goes into more detail in his blog post on the same topic. These terms are however, still used interchangeably by most.
So, what is required is the tested and validated capability to deploy to any environment in your delivery lifecycle – all the way out to production. You may only continuously deploy to an environment before ‘Prod’ – UAT/Pre-prod…, but the environments you do deploy to should be ‘production-like’, so you know with very high confidence, that the final deploy to production will work without issues, when you do really need to deploy to it.
What you do continuously deliver should be every change – like Flickr does – to Dev and/or QA environments. What you choose to deploy finally to Prod will typically be a full feature or set of features or a full application or service.
What does this Continuous Delivery capability buy you? I will discuss that in more detail in my next post on adopting Continuous Delivery.
Update: A video I recorded on this topic:
Like to learn more about Adopting DevOps? Check out my new book – The DevOps Adoption Playbook.
The series so far:
Understanding DevOps:
- Understanding DevOps – Part 1: Defining DevOps
- Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
- Understanding DevOps – Part 3: The Battle of Dev vs Ops
- Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
- Understanding DevOps – Part 5: Infrastructure as Code
- Understanding DevOps – The Video (6 minute Intro to DevOps)
Adopting DevOps:
- Adopting DevOps – Part I: Begin with the Why
- Adopting DevOps – Part II: The Need for Organizational Change
- Adopting DevOps – Part III: Aligning Dev and Ops Teams
- Adopting DevOps – Part IV: Adopting Continuous Deployment
Home: sdarchitect.blog 
“Your organization may have some (water-SCRUM-fall like) requirements and policies that requires a manual approval process”
Yet it’s usually human interaction which introduces errors, slows things down, and isn’t really required but is in place because it’s “the way things have always been done”.
It’s exactly these types of organisations that usually should be implementing continuous deployment, but of course it’s hard to implement, when the new system is about to replace the jobs of the people who claim that manual intervention really is required.
Interesting discussion on Hacker News on this post: https://news.ycombinator.com/item?id=6559714
@Louis, could not agree more with you. But, one has to live in a Water-SCRUM-world as the corporate structures may take a long time to align/evolve to a DevOps way of thinking.
Changing a company’s culture can be very hard and challenging, also moving to continuous delivery has to be back and fully supported from the management and cannot be done otherwise because of the vast investment in the process. Management need to understand that this is a strategic goal and in the best interest of the company.
There is also a very good case study / guide of how Wix moved to continuous delivery http://www.aviransplace.com/2013/03/16/the-roard-to-continues-delivery-part-1/ which I also found very interesting
Very good article! Thanks a lot!