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.
The series so far:
- 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
- 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