Financial ServicesProviders Company Schemes Public Sector Third Party Administrators

JAX Conference 2017 Day 3

Nick Cooke

Principal Developer

describes 'The Road to Continuous Deployment'

11 October 2017

There was a great talk yesterday at JAX London from Michiel Rook covering 'The Road to Continuous Deployment' and how his team took an aging monolith system (a Netherlands-based recruitment website) from releases every few weeks to multiple deployments a day. Some of the key principles that worked for his team were:

  • Decouple deployment (a technical activity) from release (a business activity).
  • Commit only to the Trunk.
  • Use feature toggles instead of branches.
  • Pipeline speed is key - 30 minutes max (from commit to production).
  • If it hurts, do it more often (that is, if deployments are painful, do more - not less)!
  • Pair programming = continuous review (so no delays waiting for code reviewers).
  • Follow the 'Boy Scout Rule' (to avoid 'Broken Window Syndrome').

The result was a system with many deployments per day, fewer issues, improved metrics, increased team velocity, increased confidence in the system and a happier and more motivated team.

Along the 'Road to Continuous Deployment' there are three key stages:

Continuous Integration

The product is built every commit and a full set of unit tests run: a commit automatically produces an artefact that can be (by some means) deployed to a test environment.

Continuous Delivery

The product is built every commit and a full set of unit tests run, it is automatically deployed to a test environment and a full set of automated acceptance tests is run: a commit automatically produces a fully tested artefact that can be (by some means) deployed to a production environment.

Continuous Deployment

The product is built every commit and a full set of unit tests run, it is automatically deployed to a test environment, a full set of automated acceptance tests is run and the code is deployed immediately (and automatically) to production: a commit automatically produces an upgraded production service.

As you can see, Continuous Integration/Delivery/Deployment can be viewed as increments along a path to a fully automated deployment pipeline, so how far have we travelled in Aquila Heywood? We are already doing much of this - Continuous Integration has been in place for several years - any commits are automatically built and unit tested and the results published for anyone in the offices to see. Our pipeline also mostly meets the definition of Continuous Delivery – successful builds can result in our internal test services being automatically upgraded and a full set of automated UI tests run against them (though we do still have some manual tests and checks run prior to a product being releasable). When successful, we then have a product that can potentially be deployed. We are some distance from being able to achieve Continuous Deployment (certainly for our main products) and, given our industry, I'm not sure it is something customers are ready for yet, but I think that will change. I can certainly see a future where we automatically deploy to customer test environments, if not production. The challenge will be to build out our pipelines and architectures so that the benefits are clear to customers while ensuring they have trust and confidence in the system.

Nick Cooke is a Principal Developer at Aquila Heywood, the largest supplier of life and pensions administration software solutions in the UK.

Further Reading