Principles Of Continuous Delivery
The goal of Continuous Delivery (CD) is to allow you release as fast as want by implementing a repeatable and reliable way to build, deploy, verify and release software product. CD could be presented as a continuous deployment pipeline:
Amazon is a perfect example of properly implemented Continuous deployment scheme. In 2011, Amazon deploy new software to production every 11.6 seconds.
It’s really unbelievable how continuous delivery practices have radically changed the way software products are managed. This post will be focused on the things to remember when to introducing CD.
There are two major topics of discussion — test and deployment. Two basic ideas are:
- We should automate major part (nearly 100%) of our testing to have confidence in automating releases.
- Manual deployment can never be described as repeatable and reliable and should be automated as well.
Yes, you have to automate pretty much everything in order to be able to achieve continuous delivery.
Automating the entire testing effort has its own risks — test base changing and maintaining could cost the business large sums especially when changes in design happen. Continuous delivery is based on the use of smart automation.
Automation for deployment is a must requirement for CD. Automated deployment should be simple and smooth. But what if automated deployment is difficult and painful? Just do it more often! Nonsense? No. This will lead you to improve it, probably simplify it, and this will eventually make it painless and easy.
Usually this sounds like “Let’s implement Continuous Integration for integrating, building, and testing code. When our CI part is done — we ready to go into a production.” Continuous Integration is a strategy for how a developer can integrate code to the mainline continuously — as opposed to frequently. It’s a very reasonable and mature strategy.
A project with targeted quality metrics (unit test coverage, code styling, rules violations, complexity measurements — preferably, all of the above) will invariably be better than one without, and easier to maintain in the long run. Take the time to invest in your own quality metrics.
I would also stress the word “done”. There should be clear “definition of done”. If “done” means “developers declare it to be done” that’s much less believable than if it’s ready to deploy into a production.
The biggest risk to any software effort is that you end up building something that isn’t useful. Usually feedback directly associated with users (customers).
CD has two major benefits—fast development and smaller changes. As soon as code is developed & verified, your users are using it. Also these changes are so small and frequent that they are often invisible to users. Together they bring more visibility into development & maintaining progress.
In Continuous Delivery, the feedback loop provides feedback not only on the quality of the code, but on the quality of the requirements, and the quality of the processes for delivering software. What that means is to gather the feedback from everybody who is involved in the process. Let me give you an example on this — considering deployment. Let’s say we have hard and complex deployment procedure with multiple number of steps. Most probably one day development team face problems with understanding why build is failed. Surely there will be a negative impression on deployment from the team. This negative impression should be outlined as feedback and provided to the management. Feedback should be counted by management to improving the process.
Continuous Delivery is an approach in which team ensure that every change to the system is releasable. It all about three moments — total automation, focus on quality and feedback. And CD practice is continuous in nature, and that promote flow, small batch size, and continuous improvement.