Continuous Deployment

Continuous Deployment

Continuous what? Integration/Delivery/Deployment… Oh, we just say CI/CD and brush the differences under the rug… And in the process devaluing the advantages of going the whole hog. You start talking to someone about how we’re trying to go full-on CD (Deployment) and why, and they go - oh yeah, we’re doing CI/CD - we’ve got Gitlab-CI/CD! Yay!.

As per my previous blog about DevOps “meaning” automating infrastructure, this is another sad loss.

So, with DevOps you have to be conscious of “batch size” and “bottlenecks”. So as completed widgets sat in the loading bay waiting for a truck is value going to waste, the same is true of completed code sat waiting for deployment. CI has some value but is limited if the work just sits there, with more work piling up on top of it, but unable to be used by your customers. CD (Delivery) is nearly there, instead we have loaded the truck, but are waiting for something like sign-off before our customers are allowed to have it. Sometimes, this is forced upon us - regulatory restrictions, Apple app approval, and so on. Sometimes we have made artificial gates… somebody released a broken build that took down our system for 15 minutes causing us infinite harm and so we have guarded against it ever happening again.

CD (Deployment) is the grail. I commit a working change, and 5 minutes later my customers are using it. To do so in such a way as to avoid the gates requires a lot of discipline. Building trusted systems and responding to the occasional failures by improving those systems while keeping the primary directives of small batches and no bottlenecks pure.

We are still greenfield, setting up the initial systems, so the following concepts are a baseline, which will no doubt evolve over time.

  • All commits must be deployable. We use techniques such as feature toggling, maintaining deprecated code paths, forward evolution of databases and contracts to ensure no changes have to sit in limbo for immeasurable periods of time
  • Trunk-based development. Work sitting in a feature branch is accumulating work in progress - widgets on the shop floor.
  • Test, test, test. Automate as many of the blockers to release as possible.
  • Have a team responsible for everything up to and including the infrastructure. Minimise handoffs between teams, preferably to zero.

My advice is don’t stop at CI, or even CD (delivery)… push all the way through.