If you are not doing, or not going in the direction of doing, Continuous Delivery (CD) I would say you are going down to the wrong path. I know, I have strong opinions (see my post Are you agile? really?). But this is the only way I could see software development in large scale* work. Not saying it is an easy path (I would mainly blame the culture of avoiding/blocking changes), just saying that you should start thinking on its benefits and also you should start trying out those techniques.
It is important to mention that this post will not discuss continuous delivery strategies, techniques or patterns. For that you should read the Jezz Humble’s book and search for it on web. I’m sure you will find hundreds of wonderful materials on this subject.
So, why you should be doing continuous delivery?
Lots of people think Continuous Delivery is an extension of Continuous Integration where the focus is on "solving the last mile”. Although this is kinda of true, it necessary to look at the whole idea behind Continuous Delivery to figure out that it is much more than “the last mile”. Let’s discuss some key points:
Manage IT risks in a simple and efficient way
Automate testing is one of the key strategies in continuous delivery world. A well design pipeline includes, at least, unit testing, service testing, functional or acceptance testing, smoke testing and provisioning testing. So, going down this pipeline means you are testing every piece of your software, including infrastructure. Knowing this will happens dozens of times per day you are then reducing the risk of going live.
Respond as fast as possible whenever an issue happens
Continuous Delivery does not eliminate all bugs/issues from going live -- although I’m secure to say it reduces most of them. So, when these unpleasant things happens, CD plays in your side. Let’s see an example:
The above picture shows the time spent to figure out a problem an then the respective time spent to fix that in an traditional delivery process.
On the other hand, it is possible note in the above picture that both time to discovery and to fix a problem in production is much smaller in CD than it is in traditional processes. This happens because:
- Once you goes frequently to production, you have much smaller batches, then you have much smaller problems. Simple like that.
- Even if you have an issue that requires to rollback the whole installation, it is much easier to do this task in CD since you have all the software and provisioning scripts marked into SCM.
- As you must already know, going back must be the last option. In CD world we used to say “go forward”. That means, fix the problem and reinstall. Your process was planned for that.
Delivery of reliable products
As discussed previously, continuous delivery depends on automated testing. So, it is all about doing regression tests many times per day. That means, whenever a developer makes a change in a module A that breaks another module B, in which he is not responsible for, it will be known as soon as the pipeline starts. Therefore, you get confidence whenever you deliver a new version of the product.
Refactoring
Another interesting point is that this amount of testing actually encourages refactoring. And, periodically doing refactoring we ensure that our software will ever be up to date. Without such strategy, delivering a new version of your software means you already have a legacy.
Reduce the cost of the product
As any software engineering knows, the cost of fixing a bug/issue grows in price according time passes (see the picture below). Continuous Delivery is all about discovering this kind of stuff as early as possible in the pipeline, reducing then the product’s cost as a whole.
Builted-in software quality
It is not possible to do continuous delivery without doing continuous integration. Therefore, all the good stuff of continuous integration is earn for free. ;-)
Repeatability
One of the main strategy behind continuous delivery is the “on click” slogan. That meas that with just one click or two (or a command or two) you are able to delivery your software -- including all the infrastructure it depends to run on top of. To make this possible, you must automate almost every step of your delivery process. Doing that, you have a fast, reliable and repeatable delivering process.
Spread delivery knowledge
In most of companies I’ve being working for, the delivery knowledge is focused in a delivery team. Some times, this team was composed by only one person. Whenever this person decide to look for new opportunities and you have an urgent deliver to do, certainly you got into trouble. Why?
Just because:
- You don’t know detailed steps to delivery your software
- Documentation is, usually, not up to date
- When you go into the delivery process you start to see the hack people do for delivering
With Continuous delivery you just press a button. Then, after delivering, you have enough time to look into the process for understanding and, maybe, improving.
Infrastructure fully documented
Every build and delivery step is “configured” in a programmatical way. So, whenever you would like to know how infrastructure work in any environment (i.e. development, staging, production, etc), just checkout the the code from SCM and take some time to understand the logic.
Documentation will never be out of date
Even better than have fully documented environments, is that this documentation will never be out of date. Whenever it gets out off date your continuous delivery process will advise you by failing some stuff in the pipeline... Amazing, don’t you think?!?!
This is one of the key benefits from Continuous Delivery that is not so commented in papers on this area.
Learning from real data usage
"When you think about it, the concept of continuous delivery isn't really new. Creating a hypothesis, developing the hypothesis, testing it, and controlling for other variables by isolating the one that changes—that is, the scientific method—isn't exactly controversial. While Agile certainly has made strides, putting a greater emphasis on making sure that testability is a first-order concern in software delivery work, continuous delivery closes the loop" [source]
Focus on customer necessity
Most of the time customers do not know what are they needs. In other times they do not have enough data for solid decisions. Continuous Delivery and its scientific method help us to focus on actual customers need (i.e. ROI) and not in what they want.
Fast feedback, visibility and control
The build pipeline used in Continuous Delivery is all about fast feedback, visibility and control. Where anyone is able to see the current status of the project just looking at a dashboard (usually shown in a large LCD).
Dashboards play a key job in CD world. Nobody should be asking for things like: Which version is being tested? Which version is in production? Which build has failed? Why it has failed? Where can I find the log? etc.. etc.. A good Dashboad should respond this and many other question for just looking at it.
Concluding remaks
All these good stuff guarantee that the product will arrive in production as fast, as mature, as stable and as reliable as possible. Besides this, doing continuous delivery is a fun task in which every time you finish a process automation you will find another part to automate or improve. As Jezz Humble once told: "we will never be done". :-)
So, my advise is: you are already late! Start using continuous delivery.
---
* In this context large scale means more than few developers. :-)
