Stage is the step in the SAFe for DevOps Health Radar where we perform the final validation before going to production. In the staging environment, we run user acceptance tests, conduct system demos for our stakeholders, and verify that everything is truly production-ready. In this video, I walk through what the Stage step involves and why it is essential for a reliable delivery pipeline.
The Journey to Stage#
Before we reach the Stage step, we have gone through the entire upstream pipeline. It starts with bright ideas from the customer or the business. These ideas are transferred into epics with a clear hypothesis statement. We collaborate and research to identify customer needs and perform market research. We architect the minimal architecture needed to prove the hypothesis. Then we synthesize by breaking down the epic into features, which we place on a roadmap and into our backlog.
From there, we develop user stories, commit source code, reintegrate our changes, build a deployable artifact, and run static code analysis and unit tests. The deployable artifact is then deployed to a test environment where we perform integration tests and end-to-end tests. After that, we are ready for the staging environment.
What Happens in Stage#
In the staging environment, we perform the final validation to determine if we are production-ready. The primary activity is user acceptance testing (UAT). This is the chance for the business to review what we have built and confirm it meets their expectations.
A staging environment, by definition, matches the production environment. It is a one-to-one copy. While we already discussed in the test step that test environments should be as close to production as possible, in stage we truly need this match. Only with a production-like environment can we reliably run end-to-end tests and user acceptance testing.
Blue-Green Deployments#
To enable stakeholders to test continuously in a staging environment, we can use blue-green deployments. This approach uses two production-like environments. One environment is live, and the other is idle. In front of both environments sits a load balancer that can switch between them.
When we have a new version of our software, we deploy it into the idle environment. Once the deployment is complete, we switch the load balancer to point to the new environment. All users then work with the new version on the now-live environment. The other environment becomes idle and is available for the next deployment.
The big benefit of this approach is twofold. First, if there is a problem with the new version, we can investigate it on the idle environment without affecting the people using the live environment. Second, if we discover a problem after switching, we can quickly switch back to the previous version.
System Demos#
The staging environment is also where we conduct system demos. Every two weeks, we integrate with the rest of the software and show our stakeholders what we have achieved during the sprint. Stakeholders can give us feedback and decide whether the result is ready for production or needs rework.
This regular feedback loop is a core practice in SAFe and ensures that the development team stays aligned with business expectations.
The Output of Stage#
The output of the Stage step includes three things:
- A production-ready artifact. The deployable artifact has been validated and is ready for production deployment.
- Test evidence. This is especially important when regulations are in place that require documented proof of testing.
- Stakeholder feedback. Gathered through the system demo and user acceptance testing on the staging environment.
The Maturity Levels#
The SAFe DevOps Health Radar provides a maturity assessment for the Stage step:
- Sit: No staging environment exists, or a test environment is used for staging.
- Crawl: Features are deployed manually to a staging environment once every PI or every three months.
- Walk: Features are deployed to a staging environment once per month and demonstrated to product management.
- Run: Features and infrastructure are auto-deployed to a staging environment every iteration or sprint and accepted by product management.
- Fly: Stories, changes, and infrastructure are auto-deployed to a staging environment, validated, and immediately proceed to deployment.
Key Takeaways#
- Stage is the final validation gate. It ensures that everything is production-ready before the software moves to production.
- The staging environment must match production. It is a one-to-one copy of the production environment, not just a close approximation.
- User acceptance testing is the primary activity. The business validates the software meets their expectations.
- Blue-green deployments enable continuous testing. Two production-like environments with a load balancer allow seamless switching and quick rollbacks.
- System demos provide stakeholder feedback. Every sprint, stakeholders review the progress and give their approval or request rework.
- Automate as much as possible. In the best case, deployment to stage, automated testing, and promotion to production are all fully automated.