Continuous delivery: What works (and what doesn't)

Featured on Facebook

So who does continuous delivery and where does it work well? It is said that Facebook deploys it at least a couple of times (or more) a day with its “ship early and ship often” intonation; it therefore delivers continuously to facilitate this dynamism.

With a web-facing front end and a cloud-located back end, this is fine for Facebook. Users wouldn’t notice a new delivery any more than they would a page refresh. Outside the web application the process is slightly more involved.

“Continuous delivery is sometimes confused with continuous deployment. But continuous deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day,” says Fowler.

“Continuous delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do continuous deployment you must be doing continuous delivery.”

The trouble is that it works beautifully on paper, but the applied science may be somewhat less exact

The trouble with continuous delivery thus explained is that it works beautifully on paper, but the applied science may be somewhat less precise. Not everything is as easily automated as might be hoped.

For example building an integration or staging test platform that closely emulates a real production environment is probably not a trivial task. Databases have to be built and populated, licences for software installed and so on.

Mark Warren, European marketing director at Perforce, warns that the tests may take longer to execute than the cycle time between deliveries from development. Imagine the backing up of cream cakes from the production plant if the conveyor belt through quality control is running at only a tenth of the speed – it will get messy quickly.

“There are scenarios where automation is desirable, such as a front-end social network platform where the cost of continuous updates may be low and impact of failure cheap,” says Warren.

“However for a back-end payment processing system that needs the same level of availability as the national electricity grid, changes must be deployed less frequently. In highly secure environments, such as payment handling, there may need to be an air-gap between development and production systems.

“Someone will need to walk the floppy disk across the room. Where manual steps are required, the process and recording of progress has to fill the gap.”

Repeat after me

In some respects the most common continuous delivery pipelines are not all that different from traditional waterfall processes. In Continuous Delivery, the de facto Bible on the topic by Jez Humble and David Farley, you will find images of the lifecycle that include familiar phases such as “user acceptance testing”.

The difference is that there is a lot more automation so the process can execute more rapidly and can be repeated at will.

From Warren’s perspective inside Perforce, a company marked out for its distributed versioning service, automation depends on a couple of key capabilities: some kind of tooling that enables fast, predictable and cross-platform scripting and a single repository or “single source of truth”.

“The scripting angle is pretty well covered with tools like Puppet, Chef and a few commercial offerings. The single-source-of-truth repository is effectively the version management system (the production plant) that software developers are used to, but now there are additional demands on its performance,” says Warren.

Notably, this version management system needs to be able to version everything – not just source code but also the “entire build, test and deploy environment job, and possibly the built executables too”.

Warren concludes: “If multiple-version management tools are in use, the complexity involved in ensuring a consistent and whole deployment is hugely increased. If it can’t handle, say, large binary files as well as small JavaScript source, then there is no guarantee as to what is being deployed at any point.”

Where do we stand in 2013? We can say with some certainty that the shadow of cloud, mobile and web-facing applications on every corner dictates an increased need for continuously delivered rapid application development and deployment.

So why isn’t continuous delivery more prevalent across the common vernacular of tech?

It will be, trust us on that one. ®