Date: 24 July 2018
Continuous Delivery encompasses a set of principles, practices and tools for delivering valuable software sooner, with improved quality and reduced manual involvement.
Continuous Delivery is key to modernising your technology, epitomising the three ways that underlie DevOps:
- Improving Flow of the software value stream from development through to production
- Providing Fast Feedback to the teams on the current status of the value stream
- Continuous Experimentation and Learning helps your organisation continually evolve and improve its value stream delivery
Improving flow
Software delivery is a team sport. Collaboration and communication are key to the effectiveness of any team. The practices that we introduce to improve flow also improve your team’s culture, collaboration and communication. This requires that your team is open to continuous improvement, technical excellence and adopting ways of working that may be new to them.
Continuous Integration
The first stage of automating your value stream is normally Continuous Integration – the act of continuously integrating your work with that of your team, at least once per day, preferably more often. In larger value streams, it also includes integrating your system with other dependent systems. If you are deferring integration rather than continuously integrating “it’s very hard to predict how long it will take to do, and worse it’s very hard to see how far you are through the process”1. I once spoke with a project manager who, on a traditional project, had planned integration to take one day. A month into integration, he still had no idea how much longer it would take.
The effectiveness of Continuous Integration is amplified once the act of integrating code into a shared code base triggers the automated build, unit testing and static analysis of the code. All of these safeguards help determine whether the code is integrated correctly and meets the requirements that your delivery team have set. These requirements are best clarified through team practices such as pair programming and code review.
Should a failure happen during Continuous Integration, it is important that your team ‘keep the build green’ by communicating and collaborating to fix the failure as soon as possible. Fixing it straight away should be easy since the context is still fresh in their heads and is isolated from additional changes that could muddy the picture.
Continuous Testing
Once Continuous Integration is in place, the next stage is normally to automate the deployment, configuration and testing of each change. This stage is sometimes called Continuous Testing. Ideally, this will take place in a new environment, so that it can be automatically triggered whenever a code change is integrated without affecting any testers performing exploratory testing in a test environment. Dependent on your situation, this could utilise automated provisioning and configuration management tools, or even start a new instance on a platform.
Effective Continuous Testing requires that your team members have a shared understanding of the functional and operational requirements that are needed of the system. Collaborative specification techniques, such as Specification By Example (aka Behaviour Driven Development) help your team build this understanding. These techniques greatly improve quality by finding issues prior to development, create a shared language across the team and encourage collaboration. The output is a set of specifications with examples that, when automated, function as checks that the system meets its defined goals and become living documentation of the system.
Additional checks could include infrastructure compliance, performance, security etc. As with Continuous Integration, it is important that the wider team fix up any issues as soon as possible so as to ‘keep the build green’.
One anti-pattern that often occurs in teams that aren’t practising DevOps is for the developers to create the deployment scripts without involvement from operational teams. The result is a set of scripts using tools that aren’t appropriate for your operational teams. This often becomes apparent months later when you want to extend your deployments towards the production environment. It causes rework and raises the question ‘why didn’t you talk to us before?’.
Continuous Delivery
With most of the technical building blocks in place, you can now extend your pipeline through to your production environment and achieve Continuous Delivery. You can re-use your deployment scripts to deploy to different environments and run a subset of your testing as smoke tests against each environment. Hopefully you’ve collaborated with your security team throughout the journey, with your secrets managed well, so there’s no roadblocks as you move towards production.
A simple Continuous Delivery value stream may look like:
A Continuous Delivery value stream will normally have some manual gates in place that require authorisation before proceeding, for example a Test Manager confirming that exploratory testing is complete, a Release Manager confirming CAB approval is granted or an Operations Manager confirming it is safe to deploy. Your Continuous Delivery tool will need to support the manual approval, security and auditing required. Over time, you may be able to mitigate risks sufficiently to remove some, or all, of these gates. A value stream that is fully automated to production with no manual gates is often termed ‘Continuous Deployment’.
Every organisation’s path towards Continuous Delivery is different. Depending on your product or service’s profile, appetite to risk and value from automated delivery, you may decide to focus on rapid delivery with a minimal set of automated checks that evolve over time. Or you may choose to build a strong set of automated checks and build confidence in deploying to test environments before extending your delivery automation to production.
Fast feedback
A lot of the value obtained from Continuous Delivery is in preventing breakages from affecting your test and production systems. When a breakage does occur, you will want to make it visible and notify your team immediately so that it can be rectified and your value stream can return to a steady state.
Modern Continuous Delivery tools provide these alerts through channels such as Slack messages, emails, or status tray updates. They provide information radiators that make the current status of the work flowing through your software value stream visible to everyone contributing to it.
Continuous experimentation and improvement
Refining the delivery of your value stream is an ongoing process. Obtaining insights into the efficiency and effectiveness of your value stream allows you to optimise it in the appropriate places. Measures including Deployment Frequency, Mean Lead Time, Mean Time to Recovery and Change Failure Rate can be used to measure your technical performance. The DevOps Report has shown that these metrics are strongly correlated with organisational performance.
Improving these metrics will require experimentation and improvement across your delivery team. For example, to improve Mean Time to Recovery, you will need to improve your incident management handling, with incident reviews guiding you on potential improvements to your housekeeping, monitoring, logging and incident management processes and tooling.
Retrospectives will give a regular ceremony to suggest small incremental improvements to your processes and practices and evaluate the effectiveness of previously executed improvements.
Look to change manual gates, which are closed by default, to open gates with audit controls. Move from change control to change enablement. Identify risks early and seek to mitigate them through automated steps in the pipeline.
The journey to Continuous Delivery can look slow and arduous. By taking baby steps, measuring and improving continuously while building in safeguards to mitigate risks, you can incrementally and iteratively move towards an automated value stream. Communication and collaboration is needed across your delivery teams to ensure the process is widely understood and the benefits are maximised.
1. https://www.martinfowler.com/articles/continuousIntegration.html
