Continuous delivery is one of a set of capabilities that drive higher software delivery and organizational performance. These capabilities were discovered by the DORA State of DevOps research program, an independent, academically rigorous investigation into the practices and capabilities that drive high performance. To learn more, read our DevOps resources. Continuous delivery is the ability to release changes of all kinds on demand quickly, safely, and sustainably. Teams that practice continuous delivery well are able to release software and make changes to production in a low-risk way at any time—including during normal business hours—without impacting users. Show
You can apply the principles and practices of continuous delivery to any software context, including the following:
When your team practices continuous delivery, you can answer "yes" to the following questions:
Continuous delivery is commonly conflated with continuous deployment, but they are separate practices. Continuous deployment is when teams try to deploy every code change to production as soon as possible. Continuous deployment works well for web services, but can't be applied to software such as firmware or mobile apps. Continuous delivery is applied to all kinds of software including firmware and mainframe systems, and in highly regulated environments. You can and should start with continuous delivery, even if you never intend to start using continuous deployment. Continuous delivery and continuous deployment are mistakenly viewed as risky and not suited to regulated or safety critical domains. In fact, the goal of continuous delivery is to reduce software risk, and DORA research has shown consistently that high performers achieve higher levels of reliability and availability. The technical practices that drive continuous delivery—continuous testing, shifting left on security, and comprehensive testing and observability—are even more important in highly regulated and safety-critical domains. Continuous delivery has been successfully applied many times in highly regulated domains such as financial services and government. Although continuous delivery is possible for all kinds of software, it is hard work. Nevertheless it provides significant benefits. DevOps Research and Assessment (DORA) research shows that doing well at continuous delivery provides the following benefits:
The following diagram shows how a set of technical practices impacts continuous delivery, which in turn drives the outcomes listed above: Continuous delivery is only one aspect of driving the previously discussed outcomes, albeit a critical one. Other cultural and organizational capabilities discussed in the DORA research program also help drive these outcomes. You can achieve continuous delivery by implementing the technical practices described in this document. Implementing continuous deliveryDORA research found that the following technical capabilities drive the ability to achieve continuous delivery. Transformational leadership within the organization also drives the implementation of many of these technical capabilities. To help your team get higher throughput and lower risk releases, implement the following continuous delivery practices:
While continuous delivery is often combined with continuous integration and shortened to CI/CD, research shows that continuous integration is only one element of implementing continuous delivery. To achieve reliable, low-risk releases, you need close collaboration between everyone involved in the software delivery process, not just software developers, and your team needs to adopt new ways of working and learn new skills. Common pitfalls of implementing continuous deliverySome organizations mistakenly believe that they can implement continuous delivery by doing their existing deployment process more often. However, implementing the technical capabilities that drive continuous delivery typically requires significant process and architectural changes. Increasing the frequency of deployments without improving processes and architecture is likely to lead to higher failure rates and burned out teams. Many descriptions of continuous delivery focus on the tooling and patterns, such as the deployment pipeline that takes changes from version control to production. However, using modern tooling without implementing the necessary technical practices and process change described in this document won't produce the expected benefits. The following diagram shows the J curve that DORA research has found to be typical of transformation programs. To emerge from the bottom of the J curve, your team needs to include process redesign and simplification, architectural improvement, and capability and skills development, along with automation and tooling. In the diagram, the following stages are labeled:
A good way to mitigate the impact of the J-curve is to complete a value stream mapping (VSM) exercise to discover and anticipate the effect of bottlenecks. In a VSM exercise you look at a single change as it progresses from version control to production:
The purpose of the value stream mapping exercise is to help you find inefficiencies in your process. As a team, create a diagram of how you want the value stream to look in six months, and set aside team capacity to work on implementing this future state. Identify and remove obstacles that have a process with a long elapsed time compared to the value-add time or that have a poor %C/A. It is usually necessary to tackle significant process and architecture redesign as part of implementing a deployment pipeline. Because the deployment pipeline goes from check-in to release, it connects multiple teams. It's essential to have representatives from all teams complete a value stream mapping exercise, and to agree on a common toolchain and processes (for example for deployment to testing and production environments) as part of your future state. Implementing continuous delivery is a process of continuous, daily improvement work, guided by the outcomes that you want to achieve. Tools and patterns are valuable, but only in service to this essential improvement work. Measuring continuous deliveryUltimately, the goal of continuous delivery is to ensure that releases are performed in a low-risk way during normal business hours. The goal should be that nobody has to work outside of regular business hours to perform deployments or releases, so this is something that is important to measure. How well you are doing at continuous delivery is reflected in the outcomes that you achieve. You can take the DORA DevOps quick check to see how you're doing with the key continuous delivery metrics:
As discussed at the start of this document, implementing continuous delivery should also lead to lower levels of rework, reduced deployment pain, and less time spent doing rework and unplanned work. Which is an example of continuous delivery in DevOps?So, in DevOps, continuous delivery is also called 'Automated deployment pipeline'. This will include few manual testing as well like 'User acceptance testing' which generally will be run by the end user and also few manual approval gates, as the code comes close to the production environment.
What is example of continuous delivery?It typically includes automation of additional steps in releasing new software to minimize the manual processes required. For example, a continuous deployment pipeline may automatically release the development team's changes from the repository to the production environment, where customers can use it.
What is the difference between continous delivery and deployment?Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.
What is meant by continuous deployment?Continuous deployment (CD, or CDE) is a strategy or methodology for software releases where any new code update or change made through the rigorous automated test process is deployed directly into the live production environment, where it will be visible to customers.
|