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.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
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.
Some applications can deploy in containers, such as Docker, to isolate updates from the underlying infrastructure.