Not your grandfather’s Continuous Delivery


“What’s a seven-course Irish meal?” the old joke goes.

“Six pints of beer and a potato.”

Continuous Delivery is beginning to sound more and more like that. An upstream-heavy continuum of activities from developers who eventually toss the deployable package to ops, the idea is that the package is self-contained, requires no additional configurations, and can be applied to the production environment with little to no help from dev.

The reality, as always, is quite different. Prod never looks like dev/test and seldom even like pre-prod. Even if all the services, configurations, and apps are the same, the data, usage, traffic, and data center are not.

Continuous Delivery needs to evolve into a mix of developer and operation activities, where developers are not only responsible for the code but also for the deployable image. The image in question is testable, portable, and deployable across a range of infrastructures. It is self-contained, so starting up a new instance is simply a question of instantiating the image on the target server — an ops activity.

For this “cattle” workflow, ops doesn’t need to define specific servers and lay OS, config, and app on top. Instead, they request available compute and memory resources from IaaS and lay the image on the provisioned machine so that you have a running app within seconds, not the minutes or hours it could take for each component of the app.

When a PaaS claims they can bring up new instances of your app in seconds, this is what they are attempting to accomplish.

The problem with PaaS is their inherent limitation of supported developer frameworks and services, their unavailability as on-premise services (though both Cloud Foundry and Open Shift provide that option) and, above all, the steep cost of hosting apps (or having to manage the infrastructure).

While we won’t go into the hotly debated topic of PaaS adoption, it is clear that enterprises are attempting to realize this vision through a variety of tools.

Atlas, Otto/Vagrant, Packer, Terraform, Consul, Serf from Hashicorp, vRealize/vCloud from VMware, Ansible/Salt/Chef/Puppet, ElasticBox, CliQr, Jenkins etc. all solve part but not all of the problem.

However, who wants to adopt a tech stack where you have to define the workflow for each new technology? As the number of scripts and complexity grows, who wants to manage the “management platform” like Chef and Puppet?  Who hires people with tool-specific expertise and manages them into what is now being called the “DevOps engineering” team?

Nobody, that’s who.

The time to democratize the Continuous Delivery process is here. The time of opinionated workflows is not far behind.

The new implementation of Continuous Delivery should (and will):

  1. integrate (not just orchestrate) developer and operation activities into a single platform,
  2. automate the entire process through opinionated workflows,
  3. accelerate essential tasks like deployment and infrastructure automation through immutable infrastructure approach, and finally
  4. control the app delivery (start, stop, reset) and make it transparent to minimize risk.

Not only does this make Continuous Delivery faster, but also lighter, with fewer tasks and technologies to manage.

Do it right and that Irish meal will become  a lighter, five-course meal — two pints of beer, colcannon, onion soup, and a coffeecake.