Microsoft Visual Studio Team Foundation Server 2018 and earlier versions have the following differences in naming:
Pipelines for build and release are called definitions
Runs are called builds
Service connections are called service endpoints
Stages are called environments
Jobs are called phases
A stage is a logical boundary in an Azure DevOps pipeline. Stages can be used to group actions in your software development process (for example, build the app, run tests, deploy to preproduction). Each stage contains one or more jobs.
When you define multiple stages in a pipeline, by default, they run one after the other. Stages can also depend on each other. You can use the dependsOn keyword to define dependencies. Stages also can run based on the result of a previous stage with conditions.
Organize the deployment jobs in your release pipeline into stages.
Stages are the major divisions in your release pipeline: run functional tests, deploy to preproduction, and deploy to production are good examples of release stages.
A stage in a release pipeline consists of jobs and tasks.
This version of TFS doesn't support YAML pipelines.
To add a stage to your release pipeline, select the release pipeline in Releases page, select the action to Edit it, and then select the Pipeline tab.
While the most important part of defining a stage is the
automation tasks, you can also configure several properties and options
for a stage in a release pipeline. You can:
Edit the name of the stage here if necessary.
Designate one user or a
group to be the stage owner. Stage owners get
notified whenever a deployment to that
stage fails. Being a stage owner doesn't automatically come with any permissions.
This version of TFS doesn't support YAML pipelines.
You control the dependencies by setting the triggers on each stage of the release pipeline:
Stages run with a trigger or by being manually started.
With an After release trigger, a stage starts as soon as the release starts, in parallel with other stages that have After release trigger.
With an After stage trigger, a stage will start after all the dependent stages complete. Using this, you can model fan-out and fan-in behavior for stages.
Define conditions
You can specify the conditions under which each stage runs with expressions. By default, a stage runs if it doesn't depend on any other stage, or if all of the stages that it depends on have completed and succeeded. You can customize this behavior by forcing a stage to run even if a previous stage fails or by specifying a custom condition.
If you customize the default condition of the preceding steps for a stage, you remove the conditions for completion and success. So, if you use a custom condition, it's common to use and(succeeded(),custom_condition) to check whether the preceding stage ran successfully. Otherwise, the stage runs regardless of the outcome of the preceding stage.
Note
Conditions for failed ('JOBNAME/STAGENAME') and succeeded ('JOBNAME/STAGENAME') as shown in the following example work only for YAML pipelines.
This version of TFS doesn't support YAML pipelines.
When you specify After release or After stage triggers, you can also specify the branch filters for the artifacts consumed in the release. Releases will only deploy to a stage when the branch filters are satisfied.
This version of TFS doesn't support YAML pipelines.
In some cases, you may be able to generate builds faster than
they can be deployed. Alternatively, you may configure multiple
agents and, for example, be creating releases from the same release pipeline
for deployment of different artifacts. In such cases, it's useful to
be able to control how multiple releases are queued into a
stage. Queuing policies give you that control.
The options you can choose for a queuing policy are:
Number of parallel deployments:
Use this option if you dynamically provision new resources in your stage and it's physically capable of handling the deployment of multiple releases in parallel, but you want to limit the number of parallel deployments.
If you specify a maximum number of deployments, two more options appear:
Deploy all in sequence:
Use this option if you want to deploy all the releases sequentially into the same shared physical resources.
By deploying the builds in turn, one after the other, you ensure that two deployment jobs don't target the same physical resources concurrently, even if there are multiple build and release agents available. You also ensure that predeployment approval requests for the stage are sent out in sequence.
Deploy latest and cancel the others:
Use this option if you're producing builds faster than releases, and you only want to deploy the latest build.
To understand how these options work, consider a scenario
where releases R1, R2, ..., R5 of a
single release pipeline get created in quick succession.
Assume that
the first stage in this pipeline is named QA
and has both predeployment and post-deployment approvers
defined.
If you don't specify a limit for the number of parallel deployments,
all five approval requests are sent out as soon as
the releases are created. If the approvers approve all of the
releases, they'll all be deployed to the QA stage in parallel.
(if the QA stage didn't have any predeployment
approvers defined, all the five releases will automatically
be deployed in parallel to this stage).
If you specify a limit and Deploy all in sequence,
and the limit has already been reached, the predeployment approval for
release R1 will be sent out first. After this
approval is completed, the deployment of release R1 to the
QA stage begins. Next, a request for
post-deployment approval is sent out for release R1. It's
only after this post-deployment approval is completed that
execution of release R2 begins and its predeployment
approval is sent out. The process continues like this for
all of the releases in turn.
If you specify a limit and Deploy latest and cancel the others,
and the limit has already been reached, releases R2, R3, and R4 will be
skipped, and the predeployment approval for R5 in
the QA stage will be sent out immediately
after the post-deployment approval for release R1 is completed.
