Delivering software continuously and why you should


I’ve recently really been getting into a Software Delivery methodology which for me, wraps up a selection of the most potent benefits of Agile, TDD, Continuous Integration which requires Development and Operations to work very closely.
Holy cow, all those flashy words in a single description, that must mean this is some enterprisey buzzwordy new fangled thing, right? Nope. This is an extension of all those ideas that we know that we “should” and “could” have always been doing, and in fact some of you may already be doing it.
Continuous Delivery, in a nutshell, is about delivering your software in small, very frequent incremental updates through a huge quantity and quality of automation in build, testing and deployment. Traditionally, the release process for many teams culminates in a lockdown period for release followed by many hours or days of manual release process, followed by triage and observation. This is a broken and problematic approach and we all know it.
Instead, continuous delivery is the way forwards for delivering software and in future blog posts I will aiming to cover more of the implementation process, potential problems and cultural impact.
My interest was piqued when I attended a presentation by one of the authors of Continuous Delivery, which as the name would suggest is the currently definitive book on the subject. David and Jez developed the principles for Continuous Delivery at Thoughtworks, where Jez currently also works as the Product manager for Go (yes, neither this Go, nor this Go).
Continuous Delivery is about automating everything from build to deployment into production. This also means that methodologies such as Continuous Integration and Agile testing could be viewed as a specific subset of Continuous Delivery. I also recently attended ‘Evolving Continuous Delivery‘ with the London Continuous Integration Meetup where Chris Read gave us the quote of the night:
Until your code is in production making money or doing what it is meant to do, you have simply wasted your time
The Value proposition for Continuous Delivery is very simple: getting business value into production as quickly as possible. By repeatedly deploying to production in a controlled manner we also:

Validate the business decisions which we’ve made more quickly by taking small steps towards our goal and gaining feedback before you’ve invested the full cost.
Allow us to deliver our business value at lower risk because we make smaller changes at each step. Smaller changes are less risky than large packages of change.
Encourages the culture that nothing is truly “done” until it is delivered to your users and more importantly proven before delivery.

Every build artefact should be considered a potentially releasable artefact, your comprehensive suite of tests are there to prove that it is not suitable. With each test passed, the build should be promoted through the pipeline to the next test. In order to be confident that your release is not risky, you need to be able to test everything in a release. Obviously, this means testing code changes, but also deployment processes and configuration. Being certain of your configuration also means testing your system configuration as well as your application configuration. We’ve all seen how “minor” OS patches can cause massive knock on effects to the performance or stability of an application unknowingly, it’s vital that you should be able to monitor and roll back. When you begin to consider what conditions you may want to roll back or draw attention to your release, you may need add specific monitoring and instrumentation to your application to monitor if you notice:

Increased Latency
Increased Load
Lost Dependencies after a configuration change
Poorer Business Performance
Failed Basic Functionality of the application

Finally, deploying continuously may require cultural and process changes to the way you develop your products. In particular, your SCM and branching strategy may need to reflect the need to release partially implemented features as disabled (also known as feature toggles).  A presentation worth watching on this topic is Chuck Rossi on ‘How facebook releases software‘. Your application architecture may also need to be updated to allow continuous deployment in a safe manner.
Continuous Delivery isn’t just for Web Applications (although it, clearly has massive benefits to them) but as the Google Chrome team have demonstrated, can provide great benefits for Desktop applications (even Delphi ones!) too although requires different tools and approaches. Imagine being able to push a series of very efficient diffs to all the users of your application every time it successfully passes a full range of exhaustive tests.
Many companies currently use some form of Continuous Deployment to manage their operations, such as Flickr, Etsy, Netflix and more who I’ve forgotten. Continuous Delivery is a topic that impacts all areas of operations, development, marketing, and possibly any regulatory concerns. I intend on diving into detailed posts of various areas of the overall topic.
Further Reading

Continuous Delivery by Jez Humble and Dave Farley – The Book
Jez Humble at DevOps Days 2010 – A presentation by Jez on Continuous Delivery
Push the Button – A recent talk by Sam Newman, a principle consultant at Thoughtworks on Continuous Delivery.
The Value Proposition – An article about the value proposition on Continuous Delivery
Continuous Delivery using Build Pipelines and Ant – A great end to end article on the Build Tools side by James Betteley, who I met at the London CI meetup.

I would like to thank my good friend Kingsley Davies for encouraging me to pickup this vein of blogging.

Comments are closed.