You can choose the start and end stages in a pipeline, as well as skip intervening pipeline stages in a sequence. Stage skipping is subject to skip restrictions configured by the pipeline owner. Additionally, pipeline access control can be configured down to the stage and gate level.
Following are specific examples of how you can use this feature.
Running or Re-Running a Stage Independently
In traditional release styles, when a deployment to a release stage fails, release management or operations often must fix the issue (such as with the code or environment) and start again from the failed stage to avoid running earlier stages unnecessarily. For example, stage 2 requires hours of testing, but stage 3 fails because a required server went offline. This functionality lets them determine if the error at stage 3 requires an entire pipeline rerun. Other examples are as follows:
You can rerun a stage independently to redeploy a stage to update to a newer application or microservice release candidate that came out since the last stage run (successfully or not).
Release management or operations running a release stage can to rerun a failed stage to recover from stage errors (such as a bad process step, failed server, or unavailable resource) that do not affect the final output, so that they can fix the problem and move forward without potentially rerunning expensive stages that do not require a rerun.
A release stage owner participating in a release with traditional characteristics can rerun the stage that they own with a different application or microservice version, because they received an update from the application or microservice team that needs testing in the release stage owner’s environments.
Selecting a Subset of Pipeline Stages to Run
This functionality lets you start a pipeline and run stages only to a certain point or from a certain point without it being considered failed or left running and requiring an abort. For example:
Beginning to middle—Consider a release pipeline that starts with continuous output of release candidates from the development team. In the first two weeks of a release, they continuously deploy different development outputs and test them in the first few stages of the pipeline, but they want it to stop and be considered a success after the test stage. Once the results are satisfactory, they change the target state to "production" and rerun all stages.
Middle to end—You can recover from a stage failure by fixing the problem and then rerun the fixed stage to continue to production from the failure point. You can also start after the stage that you fixed manually (such as when a failed manual step to update the documentation was fixed).
Running Multiple Pipeline Stages at Once
This feature allows stages to run at the same time. With traditional releases, separate teams working on a release will work on their stages at the same time (and often in parallel), but their work still must be tracked and aggregated into the final release status. For example, if stage 4 is production, the operations department can start a time-consuming database backup before stage 3 (UAT) even begins. Other examples are as follows:
The integration stage is being run to deploy and test the latest work from the developers, who might not test it. At the same time, the test stage is already running functional testing on the previous release candidates.
The testing stage runs performance tests at the same time that the UAT stage is running user acceptance tests.The release manager examines the outcome of both before approving to move further down the pipeline.