Continuous deployment (CD) is a software engineering approach in which software functionalities are delivered frequently through automated deployments. CD contrasts with continuous delivery, a similar approach in which software functionalities are also frequently delivered and deemed to be potentially capable of being deployed but are actually not deployed
Continuous deployment is a strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users.
Continuous deployment eliminates the human safeguards against unproven code in live software. It should only be implemented when the development and IT teams rigorously adhere to production-ready development practices and thorough testing, and when they apply sophisticated, real-time monitoring in production to discover any issues with new releases.
Continuous deployment vs. continuous delivery
Continuous integration, delivery and deployment are collectively referred to as continuous software development, and they are associated with the Agile and DevOps methodologies. Continuous delivery and deployment originate from continuous integration, a method to develop, build and test new code rapidly with automation so that only code that is known to be good becomes part of a software product.
Continuous deployment is not the same thing as continuous delivery, although the two terms are often confused and, indeed, share the acronym of CD.
Continuous delivery occurs when developers frequently hand off new code to the quality assurance (QA) and operations teams for testing. Continuous delivery usually involves a production-like staging area, and there is often a time lag between a release and when it is reviewed, when changes are manually accepted and when the new code is released to production.
In contrast, continuous deployment does not require a staging area for code changes to be manually reviewed and verified because automated testing is integrated early in the development process and continues throughout all the phases of the release. One of the main benefits of continuous deployment is that there is no time lag between when a code change passes application- and platform-level testing and when it moves into live production.
Both CDs rely upon real-time infrastructure provisioning and application monitoring tools to discover any problems that were not caught in the testing feedback loops before deployment. Testing and monitoring are more crucial in continuous deployment because there is no human verifying performance.
Regulatory compliance or other restrictions may prevent an IT organization from adopting continuous deployment. Other considerations, such as maturity of DevOps processes, as well as best practices within the IT organization, should also influence the decision of whether or not to deploy code on a continuous delivery basis, a continuous deployment basis, or some combination of the two approaches based on the application and users.
To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.
Instrumentation is needed to ensure that any suggestion of lowered quality results in aborting the deployment process, or rolling back the new features, and triggers human intervention.
Expected Benefits
The main benefits claimed for continuous deployment arise as a result of reducing lead time, with two main effects:
- earlier return on investment for each feature after it is developed, which reduces the need for large capital investments
- earlier feedback from users on each new feature as it is released to production, which affords techniques such as parallel (or A/B) testing to determine which of two possible implementation is preferred by users
Common Pitfalls
The extent that continuous deployment is viewed as a strategy for quality, it’s easy (in particular for developers enamored with the novelty and technical aspects of it) to pick the wrong target, and optimize for “maximum frequency of deployments” – that will not, by itself, result in increased quality
Potential Costs
- continuous deployment relies on extensive instrumentation to ensure that functionality newly made available to users does not result in incidents, lowering externally perceived quality
- for the same reason, continuous deployment relies on infrastructure that allows easily backing out new features when a defect has not been detected by automated tests
Continuous Delivery vs. Continuous Deployment
Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready.
Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.
There are business cases in which IT must wait for a feature to go live, making continuous deployment impractical. While application feature toggles solve many of those cases, they don’t work in every case. The point is to decide whether continuous deployment is right for your company based on business needs — not on IT limitations.
While continuous deployment may not be right for every company, continuous delivery is an absolute requirement of DevOps practices. Only when you continuously deliver your code can you have true confidence that your changes will be serving value to your customers within minutes of pushing the “go” button, and that you can actually push that button any time the business is ready for it.
Continuous deployment tools
Continuous deployment pipelines use similar tools to those in continuous delivery, with an enhanced emphasis on code testing prior to and after deployment into production.
During development, version control and build automation, along with specialized tools, such as the project management software Apache Maven, ensure smooth delivery of code using continuous integration pipeline software, such as Jenkins.
Unit tests and functional tests put code into as many execution scenarios as possible to predict its behavior in production. Unit testing frameworks include NUnit, TestNG and RSpec, among many others.
For continuous deployment, IT automation and configuration management tools, such as Puppet and Ansible, handle code deployment and hosting resource configuration. Integration and acceptance tests can be set up in tools such as Cucumber and Calabash.
Monitoring tools, such as those from AppDynamics and Splunk, track and report any changes in application or infrastructure performance due to the new code, and they can trigger IT incident response management tools, such as PagerDuty. Monitoring and incident response for continuous deployment setups should be as close to real time as possible to shorten time to recovery when there are problems in the code.
Rollback capabilities are necessary in the deployment tool set so that any unexpected or undesired effects of new code in production can be caught and mitigated quickly. Organizations can rely on canary deployment and sharding, blue/green deployment, feature flags or toggles, and other deployment controls to safeguard against user disruption from continuous deployment.
