MisCon about Continuous Deployment?
Actually, the thought of Continuous Deployment keeps 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 Continuous Deployment is not applicable / necessary or in some cases even feasible, for every organization.
What does deploying ‘multiple times’ a day means?
When an organization says, they are doing multiple deployments 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 truly full-fledged Continuous Deployment. It means, every change by every developer works its 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 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.
Continuously Deploy or not?
There is massive confusion between the concepts of Continuous Delivery and Continuous Deployment. Carl Caum of PuppetLabs states “Continuous Delivery doesn’t mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time”.
So, going by this distinction, the essence of what SHOULD be done Vs what MAY be done states “Continuous Delivery is a MUST, whereas 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. 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 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 continuously deliver should be every change 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.