How Can I Tell If I'm Really Doing Continuous Delivery?
Should there be a Nokia test for continuous delivery? Actually, I don't think it's necessary, because there is a very simple way to know if you are really doing continuous delivery: your software is always production-ready. You could release it to users at the push of a button. If your release process is painful and infrequent, and you have a risky integration phase before you release, then you're not doing continuous delivery.
The most important metric for continuous delivery is cycle time: the delay between deciding to implement an idea, and having the software that embodies it available to users. This is a great metric for several reasons:
- First, it is a global metric that measures the effectiveness of your whole process.
- Second, it is a team metric rather than a personal metricit's only possible to change cycle time if your whole team focuses on improving the delivery process. However, it is a hard metric to measure.
The deployment pipeline provides part of the answer: An implementation of the deployment pipeline will provide the data you need to measure the time from check-in to release. Then you need a way to correlate check-ins with features, so you can see the cycle time for a whole feature. If your tools don't allow you to gather this data, it's time to find some that do.
Then you can put in place a process of continuous improvement, finding the bottlenecks in your delivery process and working to remove them, by applying the Theory of Constraints or using Kanban. Continuous delivery can and should be implemented incrementally, using a process of continuous improvement to reduce costs and improve revenue, turning your IT organization into a strategic asset that provides your business with a powerful competitive advantage.