Release on Demand is the final step in the SAFe for DevOps continuous delivery pipeline, and it is the step that ties everything together. In this video, I walk through how Release on Demand works, why separating deployment from release is so powerful, and how the whole pipeline enables organizations to build the right thing right.
The Continuous Delivery Pipeline#
Before we get to Release on Demand, let me set the stage. The continuous delivery pipeline consists of four major phases: Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand.
It all starts with bright ideas from the business or the customer. We extract the hypothesis behind each idea and capture it in an epic hypothesis statement. In Continuous Exploration, we collaborate and research to identify the real customer need, architect the minimal amount needed to prove the hypothesis, and then break down the epic into features for the backlog.
In Continuous Integration, features are broken into user stories, developed, committed to version control, built, tested with static analysis and unit testing, and the resulting deployable artifact is tested end-to-end and deployed to a staging environment for final validation.
In Continuous Deployment, we continuously deploy our changes into production with the feature toggle off. We verify that everything works, and we build up monitoring and alerting to respond to anything that happens.
What Makes Release on Demand Special#
Here is where it gets interesting. At this point, we have continuously deployed new functionality into production, but with the feature toggle off. No customer sees it yet. Now it is up to the business to decide when the time is right to release the new functionality.
Releasing new functionality is a business decision. The business decides when to release, to which users, and how many users.
This is the fundamental principle: deployment and release are separate activities. Deployment is bringing compiled code into production with the feature toggle off. Release is switching the feature toggle on. This separation is what makes Release on Demand possible.
The Four Activities of Release on Demand#
Release on Demand consists of four activities:
Release: When the business says the time is right, we switch on the feature toggle. This can happen within seconds. The new functionality becomes available to a subset of users or to all users.
Stabilize: After release, we closely monitor the system and respond to any alerts. We operate and stabilize the production environment to ensure we meet our SLAs.
Measure: We go back to the hypothesis that we identified in the exploration phase. We also identified leading indicators that tell us whether the hypothesis is true or false. Now we measure the actual business value and all the data that shows whether our hypothesis holds up.
Learn: With the measurement data, we decide whether to invest more or less in this epic. Should we continue? Should we stop? Should we implement more features, or should we halt? This information flows back into Continuous Exploration, where we might create new hypotheses or new features based on what we have learned.
How Fast Can This Cycle Be?#
I get asked this question often: what is the lead time for the whole cycle? The answer depends on the size of the idea.
Let me walk through a concrete example. Imagine we have a website, and customers give feedback that the workflow is too long. They want a faster workflow. We create a hypothesis, identify the customer need, architect the minimal amount needed, break it into features and user stories, develop the code, commit it, build it, test it, deploy it to staging, and continuously deploy it to production with the feature toggle off.
Until this point, no new functionality has been delivered to any customer. We have just gone through the pipeline. This whole cycle from exploration through deployment can be done in a maximum of a day if you are very fast, but usually it takes one sprint (two weeks) or two sprints (about four weeks).
Now the functionality is already in production. When the business says “go,” we switch on the feature toggle. This takes seconds. So the lead time for small ideas can be as short as an hour. For bigger ideas, perhaps a day. For larger ones, a two-week sprint cycle. And for ideas consisting of multiple features, you can deploy incrementally and enable features one by one with feature toggles.
The Business Value of Release on Demand#
The output of Release on Demand is clear: you have released functionality and delivered business value to your customers. What you want to ensure during this process is that your production environment remains stable, reliable, available, supportable, and secure. You need to meet your SLOs and SLAs.
During Release on Demand, you gather both qualitative and quantitative feedback from customers and from your monitoring system. This feedback tells you whether the hypothesis behind the idea is valid. It enables you to make informed decisions about investing more or less in epics and features.
By deploying small amounts of new functionality with the feature toggle off, the risk stays small. And the business gets the opportunity to decide when to maximize the impact of new functionality and maximize value for users.
Key Takeaways#
- Separate deployment from release. Deployment puts code into production with the feature toggle off. Release switches the toggle on. This separation gives the business control over timing.
- Releasing is a business decision. The business decides when, to whom, and how broadly new functionality is released.
- Feature toggles are the enabler. They allow canary releases, dark launches, and incremental rollouts while keeping risk low.
- Measure your hypotheses. Use leading indicators to validate or invalidate the original hypothesis based on real customer data, not assumptions.
- The whole pipeline is a learning loop. From hypothesis to release to measurement to learning, everything feeds back into exploration, enabling you to build the right thing right.
- Lead time depends on scope. Small changes can flow through in an hour. Larger features take a sprint. The pipeline supports both.