Releases in Azure Pipelines
In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.
Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015
This topic covers classic release pipelines. If you author your pipelines using YAML, see runs.
A release is the package or container that holds a versioned set of artifacts specified in a release pipeline in your DevOps CI/CD processes. It includes a snapshot of all the information required to carry out all the tasks and actions in the release pipeline, such as the stages, the tasks for each one, the values of task parameters and variables, and the release policies such as triggers, approvers, and release queuing options. There can be multiple releases from one release pipeline, and information about each one is stored and displayed in Azure Pipelines for the specified retention period.
A deployment is the action of running the tasks for one stage, which results in the application artifacts being deployed, tests being run, and whatever other actions are specified for that stage. Initiating a release starts each deployment based on the settings and policies defined in the original release pipeline. There can be multiple deployments of each release even for one stage. When a deployment of a release fails for a stage, you can redeploy the same release to that stage. To redeploy a release, simply navigate to the release you want to deploy and select deploy.
The following schematic shows the relationship between release pipelines, releases, and deployments.
Releases can be created from a release pipeline in several ways:
By a continuous deployment trigger that creates a release when a new version of the source build artifacts is available.
By using the Release command in the UI to create a release manually from the Releases or the Builds summary.
By sending a command over the network to the REST interface.
However, the action of creating a release does not mean it will automatically or immediately start a deployment. For example:
There may be deployment triggers defined for a stage, which force the deployment to wait; this could be for a manual deployment, until a scheduled day and time, or for successful deployment to another stage.
A deployment started manually from the [Deploy] command in the UI, or from a network command sent to the REST interface, may specify a final target stage other than the last stage in a release pipeline. For example, it may specify that the release is deployed only as far as the QA stage and not to the production stage.
There may be queuing policies defined for a stage, which specify which of multiple deployments will occur, or the order in which releases are deployed.
There may be pre-deployment approvers or gates defined for a stage, and the deployment will not occur until all necessary approvals have been granted.
Approvers may defer the release to a stage until a specified date and time.