One of the questions that frequently arises when working with releases is, which stages do I need in my release pipeline? According to the documentation, stages should denote the major divisions of a release pipeline. When starting out with releases, this often boils down to having one stage per environment in a release pipeline. Appropriate stages include test, acceptance, and production.

When working with releases for a long time, we might incorporate more automation in the pipelines and want to add extra checking stags to them. An example might be a stage called load test that is executed in parallel to the test stage. Another example might be the introduction of a stage for automated UI tests.

No matter which stages are added, the approach to propagating a release to production should always stay the same. When a release propagates from stage to stage and gets closer to production, this should show that there is confidence in this release, that it is working correctly, and that it can be promoted to production.