Continuous Delivery and Continuous Deployment are two fairly similar terms, but they describe two separate things. Let’s try to clear things up.

Continuous Delivery - as described in the book by Jez Humble and Dave Farley, is the process of streamlining the workflow from someone having an idea, to having that idea implemented in software, released into production, and available to the end users. It involves breaking down features into small parts that can be delivered one at a time, so that we can have a constant stream of updates. This allows us to get rapid feedback from our users and customers about the features we are developing, and to refine them iteratively. To achieve Continuous Delivery we try to automate any task that might be a bottleneck in releasing our code - but we don’t necessarily release every single build to production. We want releasing to be a business decision, not a technical one. If a version of the code running on a demo server looks good to the business, we would like to be able to release that at the push of a button.

Continuous Deployment - is a technical practice, first described by Timothy Fitz whereby every time that a developer checks in to version control, the latest version of the code is built, and if all the tests and other build stages pass, then this version of the code is promoted automatically to the live, production environment, without any further manual intervention. Performing the technical practice of Continous Deployment naturally means that a team is continuously delivering updates to the code into production (either that, or they very rarely check in, which would clearly be a negative outcome). However, doing Continuous Deployment doesn’t mean that we are necessarily breaking work down into meaningful, valuable chunks, and focussing our efforts to deliver the most important features for our users one at a time.

Continuous Deployment means that every potential release (good build), becomes a release. You might have business reasons why you don’t want to do this - for example you need to align the release of a feature with some user training, or a marketing campaign. However, it is worth performing the thought experiment of whether Continuous Deployment just seems “too scary” for your team. If it does, what are you worried about going wrong? What might break? What sort of test automation, monitoring etc would you need in order to feel confident in releasing a build without further manual testing. If you have a build that is currently green but which you wouldn’t necessarily put into production - what is your green build actually telling you?

CD Courses

Want to find out more? Register for one of my upcoming courses: Continuous Delivery Kickstart a two-day workshop on Continuous Delivery that we’re running in London at the end of September. Or Hands-On Continuous Deployment a day-long tutorial at the Agile Cambridge conference.