Continuous Delivery vs. Continuous Deployment: An Overview

getting software updates to users quickly is paramount in today's world. you know from your own phone, mobile, and computer usage that software updates for applications are a daily occurrence. we live in "internet time." the ability to be quick and responsive with value to meet users' needs can mean great success for a company, but the inability to do so could mean the death dive.

in order to survive in this world, you must be able to produce both swiftly and frequently. this is how you get ideas out fast and bring business value to customers. and, being able to do this requires agility. working in the traditional waterfall process of software delivery where there was a long drawn-out series of investigation, analysis, and planning doesn't cut it anymore. agile development allows you the framework that is critical to optimize planning, testing, and implementation. agile development is a way to have faster cycle times, the goal being to achieve "internet time."

achieving continuous delivery and continuous deployment in the solution delivery pipeline means your organization is nimble and can release updates to users in a responsive manner; these 2 phases in the pipeline are very important to the overall goal of fast, responsive deployments. however, sometimes there is confusion about what they are. in this article, we clarify the difference between continuous delivery and continuous deployment and describe how each fits into an agile environment.

definitions

• "continuous delivery" means that you are ready and able to deploy any version to any supported platform at any time.

• "continuous deployment" means that you are engaging in actual deployment.

the solution delivery pipeline

in order to understand continuous delivery and continuous deployment and how they differ, it's necessary to look at the entire solution delivery pipeline.

this graphic depicts the phases that comprise the solution delivery pipeline.

the phases in the solution delivery pipeline lead you through a shortened cycle in order to be fast in response. for example, the planning phase is accelerated in that you plan just enough to get to the next 2-week sprint. contrast this with the traditional way of spending a lot of time planning for the entire project, which usually results in testing, scalability, and qa getting squeezed and ultimately a less-than-optimum product being released.

in shortening the cycle, it's imperative to incorporate feedback loops in order to get useful information that enables you to learn and improve. feedback is achieved by collecting metrics at each phase-plan, code, build, test, release, and so on, so the development team can improve the next integration.

being agile

working in an agile environment, you constantly learn from small pieces of work and thereby are able to make improvements before actual deployment.

planning for short cycles, such as 2-week sprints, allows you to have a smaller bit to review and improve. by incorporating feedback loops along the way you are given important information that illuminates what works and what doesn't work in order to make corrections quickly. being agile means you can have the infrastructure keep up with changes and match the application development cadence in order to avoid deploying on the "wrong" infrastructure.

an agile environment requires automating the testing phase so it happens fast and provides accurate feedback and can keep up with a continuous delivery pace. an agile response comes into play for issues that are reported through the help desk and other user input channels.

continuous delivery

when you are striving for continuous delivery, where you can deploy any version at any time on any platform, it forces you to optimize the development process.

it's a given that there is 10-30% technical debt on each sprint. technical debt includes such things as introducing defects or bugs and releasing a feature on infrastructure that hasn't been developed yet. it's difficult to be perfect. so, just realize that technical debt will occur and look for the feedback loops to give you the information necessary for corrections.

be sure that you get detailed feedback about how the test run went and how the process went at the end of the delivery cycle. these are some examples of questions you can answer in order to improve the process:

• did you finish what you thought you would finish?
• did you estimate properly?
• did it take the same amount of time you thought it would take?
• were the tasks done the actual tasks the team had to complete during sprint execution?
• were there a lot of tasks that had to be done that were not planned?

in looking at continuous delivery, the preferred goal is to be ready and able to deploy 10 or more times per day. if you hit that goal, then deployment can be done every 45 minutes.

continuous deployment

continuous deployment is actually deploying; however, it doesn't mean you must deploy to production or to the customer every time. for example, you can deploy to qa or to a deployment slot. a deployment slot is an a/b deployment method that allows you to get valuable information without inconveniencing users in the event that a defect leaks through a gap in the testing process. this takes some of the fear and anxiety out of the deployment.

one way of deploying to a slot might be to offer an "opt-in" choice for the customer to get an updated version, providing you with a smaller group of users that can serve as a "beta." you always give these users the ability to go back to the former version if they want to do so.

continuous improvement

engaging in continuous improvement is an important part of continuous delivery and continuous deployment. continuous improvement requires that you amplify feedback loops by:

• setting baselines. be sure you have a starting point from which you can measure.
• monitoring important metrics. the key metric is deployment frequency of 10 or more times per day. there are some other side effect metrics like mean time to recover, mean time to change, and defect to new work ratio, but these aren't as important as the deployment frequency.
• identifying bottlenecks. feedback loops during sprints give you information on any congestion or blockages in the cycle.

every time you find a gap in the process you have an opportunity to do a "gap fill" with a new test, new script, or new process. create tests that test for defects. set acceptance criteria based on input from the users. and, automate acceptance testing so that testing gets run on every commit to the source code.

delivery vs. deployment

in this graphic, you can see the point at which the difference between continuous delivery and continuous deployment exists.

with continuous delivery, "deploy to production" is a manual process, meaning that it is initiated manually. this differs from continuous deployment, which is automated all the way through "post deployment test."

in summary, continuous delivery is a state of being ready and able to release any version at any time on any platform, whereas continuous deployment is being able to continually deploy. both require an agile process that provides a framework where you work on small, frequent changes and obtain feedback. both require that you continually learn and improve on what you have done. and, both require open communication throughout the process. achievement means you can ultimately bring needed value to your customers.