Releases in Azure Pipelines
TFS 2018
Note
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 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.
Note
If your organization is using a firewall or a proxy server, make sure you allow Azure Artifacts Domain URLs and IP addresses.
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.