Release Readiness

We're used to accepting that code is in a reasonably stable state when it passes through all of the stages in our continuous integration pipeline. But is that enough to give us confidence in its release readiness?

When we consider shortening our release cycles by implementing practices like continuous delivery, a common starting point is to look into setting up a pipeline by introducing a tool like Jenkins, GitLab CI or GitHub actions, and then automating all of the processes and tasks needed to make a release candidate. That all sounds well and good and pretty standard, but what actually gives us confidence in the pipeline? Where in the pipeline do we find the indicators and the data to know whether our code is ready to be released according to our quality and feature-complete standards?

More than Continuous Delivery#

Release readiness is about taking a step back from continuous delivery and asking - what are we continuously delivering? What is our definition of quality and how can we ensure every release meets that definition?

Think about it like this:

Release Readiness is about developing criteria for commits so that they're in a releasable state (including features, quality and security).

Continuous Delivery is about automating our path toward the releasable state.

But, how do we achieve continuous release readiness? How do we define our releasable state?

You are your own domain expert#

First of all, it's important to remember that no one knows what you're trying to build better than you do. Generic continuous delivery and DevOps practices will automate your pipelines, but what are you actually automating with them and does it satisfy your definition of deployable code? For example, a pipeline for the aerospace industry will be very different from a pipeline used to create a web application.

So, before you start writing a pipeline with every conceivable testing tool integrated in it, ask yourself - what do I need to know about my software to have confidence in releasing it? What data do I need to gather for each release candidate to have that confidence?

Develop a Release Ready checklist#

By starting with the concept of Release Readiness you can write pipelines that will meet your definition of quality and the best way to do this is to draw up a checklist. This might include things like declaring how you manage the build artifacts, what sort of testing you want to do, and how your OSS compliance is achieved.

Once you have your release readiness checklist finalized you can begin developing a delivery pipeline with the end goal in sight - to cover the predefined release readiness checklist, and thus, reach a releasable state.

Defining software quality in your organization#

Release readiness means you're building quality into your software before you write any code at all. Without release readiness, you'll find yourself developing ad hoc dashboards to pull metrics from tools and data in different parts of your pipeline in an attempt to attach quality instead of building it in.

Solutions like these tend to be badly maintained and non-repeatable and setting them up eats into valuable developer time that could be spent on product development. Release readiness is all about centralizing this data in an elegant, maintainable, visible way.

Align the team#

A shared definition of what constitutes releasable code aligns everyone in the development lifecycle which helps to refine the culture across your teams. By defining your release readiness in advance everyone can work towards the same definition of what it means to have a release candidate.

When you're practicing continuous delivery anyone on the team should be able to look at a release candidate and know if it's in a deployable state. If you're doing it right you'll find unanimous agreement, not just in the outcome but in the process and tools used to get there.

Post Production and Data Driven Decision making#

Release readiness doesn't have to end with a release. We can go further, and use our dashboard to monitor activity beyond the release. By pulling KPIs into your release ready dashboard from post production you can continue to refine your definition of what it means to be release-ready in the pipeline.