On its surface, Continuous Delivery sounds fairly straight forward, but a lot of pieces need to be in place before a team can adopt a full Continuous Delivery approach to software development. I will go over more advance Continuous Delivery topics in later blog posts. For now, I will give you an overview and talk about the benefits of adopting a Continuous Delivery approach in your software development lifecycle.
Definition
Continuous Delivery (CD), according to Wikipedia, is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.
While the Wikipedia definition of Continuous Delivery is detailed, it does not explain exactly what is contained within Continuous Delivery. Continuous Delivery, along with its counterpart, Continuous Deployment, is a deployment pipeline strategy that uses a number of tried and tested elements related to the software development lifecycle. It is largely an Agile based strategy, but does not require a software team to adhere to a strict Agile software development lifecycle.
Continuous Delivery and Continuous Deployment
Continuous Delivery and Continuous Deployment are very similar. Continuous Deployment is essentially an automated version of Continuous Delivery. In Continuous Delivery deployments of code to different environments are handled manually, but systematically. Continuous Deployment takes this one step further and does automatic deployment of code across the pipeline. Both practices will require very similar considerations when integrating into a team, and it is advisable to implement Continuous Delivery first, in order to fully understand the entire pipeline, prior to Continuous Deployment.
A Goal of CD
A main goal of a Continuous Delivery pipeline is to make all of the tasks involved in pushing code through a pipeline as automated and routine as possible. The goal is to remove any edge cases or gotchas as you build your pipelines so pushing code to all of your different environments is as routine as you can possible make them. A goal is to make “push button” deployments. This essentially means that each application that you are going to deploy only requires a single push of a button to deploy it to a given environment.
Benefits
Time and Money Savings
Repeatability is a very large benefit of Continuous Delivery that a lot of companies may overlook. Being able to repeat deployments over and over again the same way, by minimizing manual intervention, will help save a lot time and money.
More Frequent Changes
A repeatable process that developers have confidence in will also help support more frequent and smaller changes, which is shown to produce fewer bugs.
More Testing
Automated testing is a core part of Continuous Delivery. Each step in the pipeline is responsible for performing a number of automated tests, including unit tests, integration tests, regression testing, and more. This means every time software goes through the pipeline it is tested over and over again.
Fewer Bugs
When you couple more frequent changes with repeated testing you inevitably have less bugs in your code, and the bugs are easier to fix. Most bugs will be caught prior to a production deploy when good automated testing is implemented. On top of this, bugs that do get into production are usually caught earlier, which means the developer is more familiar with the changes and can fix the bugs with much less effort than if the change happened further in the past. This is in contrast with a pipeline that has less frequent changes. If a bug were introduced near the beginning of the development of a large suite of changes, the developer would have a difficult time remembering exactly how the code works. The developer would need to spend a lot more time re-learning what was done in order to fix the bug.
Rollbacks
There may be times when software is put into production with bugs, or the software was prematurely released, or released incorrectly in some other way. These cases would require the software to be rolled back to an earlier version. Following a Continuous Delivery pipeline would minimize these unwanted deploys, but when they do happen the changes can be easily rolled back at the push of a button. The Continuous Delivery pipeline should support being able to rollback to previous deployments at the push of a button, similar to deploying at the push of a button.