Releases in Azure Pipelines
TFS 2017 | TFS 2015
Note
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.
A release is a construct that holds a versioned set of artifacts specified in a CI/CD pipeline. It includes a snapshot of all the information required to carry out all the tasks and actions in the release pipeline, such as stages, tasks, policies such as triggers and approvers, and deployment 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 can include running automated tests, deploying build artifacts, 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 diagram shows the relationship between release, release pipelines, and deployments.
Create release pipelines
Releases can be created in several ways:
By using a deployment trigger to create a release every time a new build artifact is available.
By using the Create release button from within your Pipelines > Releases to manually create a release pipeline.
By using the REST API to create a release definition.
Q&A
Q: Why my deployment did not get triggered?
A: Creating a release pipeline does not necessarily mean that it will automatically/immediately start a deployment. Below are few reasons why this might happen:
Defined deployment triggers forcing the deployment to pause.This can happen with scheduled triggers or when a delay is imposed until deployment to another stage is complete.
Defined queuing policies dictating the order of execution and when releases are queued for deployment.
Pre-deployment approvals or gates for a specific stage preventing deployment until all the defined conditions are met.