Are you Continuous Delivery ready?
Drag racing car burns rubber image via Shutterstock
I’m sure by now everyone reading this has heard a great deal about Continuous Delivery, which I’ll refer to as CD from here on. In short, you do it to accelerate the process of software delivery – which means you can see the value of coding more quickly.
As a cynic, I could say CD is all the rage, and a lot of execs and management have heard of it … But seriously … Are you being asked to do it by upper management so it’s a tick in the box to show you are meeting your objectives or something you passionately believe in? Ultimately the aim is to achieve a business goal such as improving quality, release frequency, time to market for new features, or saving cost.
If the latter is your aim, note that a greenfield pipeline is likely to reduce costs on the first major release. However, if you are working with a legacy pipeline, you will experience a cost “hump” to retrofit the techniques. Whichever applies to the project you have in mind, if you can do it faster, with less rework due to defects, you will end up saving costs in the long run. You’ll also remove waste – building the right features and saving valuable … hours.
What does success look like?
Be realistic. If you are greenfield, then setting a goal which you can deploy to a production-like environment by the end of each sprint is sensible. At a stretch, you might choose to deploy on every commit that passes all tests.
If you have a legacy development cycle with nine-month release cycles today, even shortening to monthly releases would be an aggressive target.
Pick an appropriate project
Start by recognising the differences between a project (the funding) and the product (the set of features delivered by a technology implementation – i. e. an app, system, service etc.). Remember you don’t do CD on funding – you do it on the system so it’s not going to come flooding in!
You may want to achieve CD across the board, but if this is new to you, then choose a suitable system and focus the efforts on implementing the techniques outlined. The ideal system will be:
- A relatively small and self-contained system. Dealing with external interfaces and dependencies from teams that are not practicing CD requires isolation strategies (i. e. service virtualisation).
- Not under demanding time pressures.
- Likely to have many iterations of its features – it is not a“one size fits all”.
- Ideally greenfield – it’s easier to start on the right foot. If the project is legacy, it has existing automated test packs at the unit, integration, and functional levels.
Evaluate the current situation
It helps to look through the lens of people, process, and finally technology:
- People: Does your team have the skills, or need coaching? Do you have the right culture – creating tests appears slower initially, so the temptation is to skip creating them.
- Process: Are you already following an iterative development model? Agile?
- Technology: Do we have the hardware/software/tools we need?
There are established maturity models to help you make an informed judgement about where you are now, and also where you might want to go next. It’s also taking a look around your organisation or conferences (blogs too) – what are other people doing? This will help you recognise your own pain points and bottlenecks.
Create the backlog
CD really demands you have adopted agile techniques and using a methodology that delivers iteratively – such as Scrum or Kanban. The latter is more suited to Continuous Deployment – i. e. each successful commit gets deployed into production automatically.
For each of the areas in the maturity model, identify the gap between where you are now and the minimum level needed to support CD.
To start with CD, what do you need to do to get to Intermediate level (i. e. you build on every commit)?
You need to get to the advanced stage to deploy. This is where CI really becomes CD, and where dev becomes what you might call “DevOps” because your collective team needs to automate the deployment of the full stack, not just application code.
This definitely includes data tiers (i. e. schema changes/reference data) and ideally networking elements utilising Software Defined Networking (SDN). But if not, at least cover the items that have to change on each deployment
If you are in the cloud, then it is often easier to automate everything with templates – such as CloudFormation templates – due to its ephemeral nature. Automating deployment is essential to make the pipeline repeatable, and it’s where you need to spend time creating a robust pipeline.
This is also where tool selection becomes important because you need to be able to model these pipelines. This is more that just a simple job that runs maven package and publishes the artifact to a repository. The key about the pipeline is that it needs to automate all the technical steps – human effort should be limited to applying judgement – i. e reviewing test results, deploying into production. Only then you can consider yourself ready to embark on your CD journey.