Release is one of the final steps in the SAFe for DevOps Health Radar. At this point, the new functionality is already deployed to production and verified. Now it is time to make the new functionality available to a small group of users or to all users. In this video, I walk through what the Release step involves and why it is a crucial business decision.
The Journey to Release#
Before we reach the Release step, we have gone through the entire continuous delivery pipeline. It starts with bright ideas from the customer or the business. We extract the hypothesis behind these ideas and put them into epics. We collaborate and research to identify the real customer or market need. We architect the minimal amount of architecture needed to prove the hypothesis. Then we break down the epic into features, prioritize them, and put them on a backlog.
From there, we develop user stories, commit source code, reintegrate our changes, and build a deployable artifact. This artifact is tested end-to-end, deployed to a staging environment for final verification, and then deployed to production. We verify in production, set up monitoring, and respond to any problems. Now we are ready to release.
Why Release Is a Business Decision#
Releasing new functionality is a crucial business decision. Releasing too early can have a huge impact, and releasing too late can also have a negative impact. This is why the decision of when to release belongs to the business, not to the development team.
This is exactly why we separate deployment from release. Deployment is bringing the compiled code into production with the feature toggle turned off. Release is switching the feature toggle on. By separating these two concerns, we give the business the ability to decide when the right time is to release new functionality.
Feature Toggles and Dark Launches#
A feature toggle is, at its core, nothing more than an if-statement. If the feature flag is on, the new functionality is active. If the feature flag is off, the old behavior continues. This simple mechanism enables us to continuously deploy into production without releasing the functionality to users.
This pattern is called a dark launch. We deploy new functionality into production without making it visible to users. This allows us to set up all monitoring and alerting, and observe how the new code behaves in production before anyone uses it. I covered feature toggles in more detail in my video about the Deploy step and the concept of architecting for releasability in my video about the Architect step.
Architecting for Releasability#
When we architect for releasability, we look at our solution as one big system and break it into smaller parts. These can be microservices, components, or any other decomposition that makes sense. For each of these components, we define a separate deployment and release strategy.
For example, one component might have heavy development going on and releases new functionality to end-users every two weeks. Another component with less development activity might release on demand, only when there is something meaningful to release. A third component might follow a monthly release cadence. The overall solution might be released every quarter.
This is how we architect for releasability. It requires separating deployment from release and using feature toggles and dark launches.
Canary Releases#
By separating deployment from release and by using feature toggles and dark launches, we are able to do canary releases. With a canary release, we make a new feature available to only a subset of users. They can test out the new functionality in production and give us feedback. We can then slowly increase the number of users who have access to the new functionality.
This approach lets us detect problems very early, and those problems only affect a small number of users. The term “canary release” comes from the canary birds that miners used in the old days. They would take a canary bird into the mine, and if the bird died, they knew it was time to get out.
Canary releases are commonly used. You may also have heard them referred to as alpha testing, beta testing, or a friends-and-family release.
The Maturity Levels#
The SAFe DevOps Health Radar provides a maturity assessment for the Release step:
- Sit: Releases are tightly coupled to deployments and customers are extremely dissatisfied with the frequency of releases.
- Crawl: Releases are tightly coupled to deployments, but customers are somewhat dissatisfied with the frequency of releases.
- Walk: Release and deployment are coupled but both occur continuously or on-demand.
- Run: Release is decoupled from deployment. Deployed features are released to the end-user population based on business readiness.
- Fly: Deployed features can be released to individual segments of the user population. Feature toggles are refactored when no longer used.
Key Takeaways#
- Releasing is a business decision. Only the business knows when the time is right to release a certain functionality to end-users.
- Separate deployment from release. Deployment brings code into production with the feature toggle off. Release switches the feature toggle on.
- Use feature toggles. A feature toggle is simply an if-statement that controls whether a feature is active for users.
- Leverage dark launches. Deploy to production without releasing to users. This lets you monitor and validate the new code in production before anyone sees it.
- Architect for releasability. Break your solution into smaller components, each with its own deployment and release strategy.
- Use canary releases. Make features available to a small subset of users first, gather feedback, and gradually roll out to everyone.