You can use the Continuous Delivery statements to assess your software delivery performance. This technique is interesting as it doesn’t need specific technical practices. Instead, it focuses on what capabilities the technical practices should bring to your team.
There are only 4 statements in the set:
- Software is always deployable
- You prioritize work to keep software deployable
- You have fast, automated feedback for every change
- On-demand automated deployments for any version and environment
Always deployable
To keep software deployable at all times, you need to detect functional bugs early in your deployment pipeline. You must also continuously maintain the system’s quality attributes, like security and performance.
When working on new features, use feature toggles or keystoning techniques so deployments can continue without unfinished features being available to users or API consumers. You also need database refactoring strategies to decouple database and application deployments.
‘Keystoning’ is a technique inspired by the wedge-shaped architectural stone at the top of an arch. It’s the last stone put in place, allowing the arch to bear weight.
In software, keystoning involves putting a feature in place without exposing it to users. When the feature’s ready, you add the keystone (like the user interface update) to make the feature visible to users.
Feature toggles are an even better way to control feature visibility. Unlike keystoning, you can change feature toggles independent of deployments. You can use feature toggles to enable a feature for everyone or a group of users or disable it if you detect a critical issue.
Prioritize blockers
When an issue stops software from being deployable, you should prioritize it over feature development. New features are of little use if you can’t deploy them. Plus, you can only fix critical problems you discover in Production when you can deploy the software.
Blockers may include:
- Bugs that would prevent a deployment
- An unexpected dependency between components
- A problem with your deployment pipeline
Fast, automated feedback
When the software changes, fast, automated feedback should be available to the whole team. Fast feedback lets you respond quickly to any issues preventing deployments. When you discover a problem, part of the fix should be introducing a test to detect it at an earlier stage of your deployment pipeline.
If you can detect problems early, you can quickly fix them to unblock the deployment pipeline. Without early detection, you must manage the impact across lots of other work, causing a retrospective batch of interdependent changes.
On-demand deployments
You must be able to easily deploy any software version to any environment. This is often called a push-button deployment, or on-demand deployment.
You can deploy on-demand if your deployments are fast, automated, repeatable, and reliable. Many high-performing organizations deploy infrastructure with the same level of automation as their application deployments.
Summary
You can assess your Continuous Delivery adoption using 4 statements. Each statement is either true or not. Your answers will give you a strong idea of where to focus improvement efforts.
- Software is always deployable
- You prioritize work to keep software deployable
- You have fast, automated feedback for every change
- You can perform push-button deployments for any software version and environment
If you want a more concrete way to measure DevOps and Continuous Delivery, you can use the DORA metrics.
Further reading
Help us continuously improve
Please let us know if you have any feedback about this page.
