Feeds

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

Software on the assembly line

Secure remote control for conventional and virtual desktops

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. ®

The essential guide to IT transformation

More from The Register

next story
The Return of BSOD: Does ANYONE trust Microsoft patches?
Sysadmins, you're either fighting fires or seen as incompetents now
Munich considers dumping Linux for ... GULP ... Windows!
Give a penguinista a hug, the Outlook's not good for open source's poster child
Intel's Raspberry Pi rival Galileo can now run Windows
Behold the Internet of Things. Wintel Things
Linux Foundation says many Linux admins and engineers are certifiable
Floats exam program to help IT employers lock up talent
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
Eat up Martha! Microsoft slings handwriting recog into OneNote on Android
Freehand input on non-Windows kit for the first time
prev story

Whitepapers

Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 10 endpoint backup mistakes
Avoid the ten endpoint backup mistakes to ensure that your critical corporate data is protected and end user productivity is improved.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Rethinking backup and recovery in the modern data center
Combining intelligence, operational analytics, and automation to enable efficient, data-driven IT organizations using the HP ABR approach.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.