How to build a deployment culture worth adopting
Continuous integration and continuous deployment/delivery (CI/CD) have long been considered best practice in digital product development, and with good reason. They enable controlled, automated, frequent and rapid deployment of new code into live services.
But for the businesses yet to make the leap over to CI/CD, the idea of pushing new code into production quickly can seem risky or uncomfortable. This can often be observed via resistance or an unwillingness to deploy changes during times of low staffing levels, such as evenings, weekends, bank holidays or Christmas.
Training, support and practice is needed to help organisations shift from heavily managed deployments towards a culture that embraces automated pipelines. To help organisations still making this shift, or working out the practicalities of where to start, we’ve laid out some guidance and a basic framework on how to get there.
Understanding the CI/CD pipeline
Continuous Integration is the process of integrating new code changes and improvements directly into a central repository. This streamlines code changes and prevents conflicting versions of code hitting live production.
Continuous Deployment is the automated delivery of packaged code to staging or testing environments and if tests pass, onto production.
Devops is the culture that underpins CI/CD. It favours fast release cycles, integration across teams (development, operations, quality assurance, management) and automated processes wherever possible.
Getting started with CI/CD
1. Visualise the ‘current state’
Workshop your current release process using a large group of stakeholders involved in the current process. The aim is to capture a visual representation of the current release programme using graphics (think lines and boxes) rather than a confluence document. Using a large group here will ensure the problem is seen as a shared one, and that you will end up with a broad consensus on your ‘as is’ state and confidence in the workshop outputs.
Reflect. How does this process make you feel? Does it seem accurate? Does it make individuals feel motivated? Can you see opportunities to reduce wasted time or resources?
2. Measure
Capture data on the time spent at each process step when a ‘happy path’ is assumed, and, if possible, combine it with rough financial cost for that time. Next, consider a typical or unhappy path; e.g. where there are errors, delays, or perhaps abandonment of a release. Capture the difference in terms of time spent and the associated financial cost.
Measuring this data will enable you to evaluate the value versus cost of each control and process step. If you don’t have quantifiable numbers, start with approximations, but also start introducing standardised ways of measuring these process step cycle times.
3. Prioritise
Seeking to optimise the whole of your release process at once will bring a large number of simultaneous risks. Start by making small but controlled changes based upon experimental hypotheses. Look at the process you mapped and your measurements (rough or otherwise) for unhappy paths. What’s the biggest delta, or largest time consumer in the process overall? What blocks parallel processing? What could be parallelised? Whatever your worst problem is overall, fix that one first.
Before incorporating any improvements, try to ensure monitoring metrics are in place first. This will enable you to evaluate the change (and any unexpected negatives), to define success, and to enable buy-in for further evolution.
4. Always challenge your assumptions
When it comes to making improvements, it is important to realise that there is no finish line. The environment, the needs of your customer and the business will keep changing, and every change you make has the potential for unintended consequences somewhere else in the process. But don’t get dismayed, focus on nurturing a continuous improvement culture so that everyone is prepared and relentless in their pursuit of improvement - similar to maintaining The Forth Bridge.
If work is assumed ‘complete’ then you will likely lose engagement and a bottleneck of business needs will develop. Instead, foster an attitude that welcomes continual re-evaluation, and focus on building a culture that welcomes the need for continual improvement.
Conclusion
Building a continuous deployment culture takes time, requires an open-minded attitude and a willingness to adopt new ways of working as things inevitably evolve. When done right, an empowered and autonomous team results; they are able to take calculated risks and seek efficiencies in their ways of working without request. You will have established a mindset that can add value to your organisation long into the future.
Sign up to the WORTH newsletter
At WORTH we believe that knowledge sharing should be free, enabling and impactful. Want further insight into our thoughts and ideas? Sign up to our newsletter.