Release pipelines and Artifact sources

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

With Azure Pipelines, you can deploy your artifacts from a wide range of artifact sources and integrate your workflow with different types of artifact repositories. Releases can be linked to multiple artifact sources, where one is designated as the primary source.

Artifact sources

Azure Pipelines supports a wide range of repositories, source control tools, and continuous integration systems.

When creating a release, you can specify the version of your artifact source. By default, releases use the latest version of the source artifact. You can also choose to use the latest build from a specific branch by specifying the tags, a specific version, or allow the user to specify the version at the time of release creation.

If you link more than one artifact, you can specify which one is the primary source (default). The primary artifact source is used to set a number of predefined variables. It can also be used in naming releases.

• The following options are supported by all the repository types: Specify at the time of release creation, Specific version, and Latest.

• Latest from a specific branch with tags and Latest from the build pipeline default branch with tags options are supported by the following repository types: TfsGit, GitHub, Bitbucket, and GitHubEnterprise.

• Latest from the build pipeline default branch with tags is not supported by XAML build definitions.

The following sections describe how to work with the different types of artifact sources.

• Azure Pipelines
• Version control
• Jenkins
• Azure Container Registry, Docker, and Kubernetes
• Azure Artifacts
• TFS server
• TeamCity

Artifact sources - Azure Pipelines

You can link a release pipeline to any Azure Pipelines build. You can also link multiple build pipelines and specify their default values and set up deployment triggers on multiple build sources. When any of the builds completes, it will trigger the creation of a release.

The following features are available when using Azure Pipelines as an artifact source:

Artifact sources - version control

There are some scenarios in which you may want to consume artifacts from different source controls directly without passing them through a build pipeline. For example:

• Developing a PHP or a JavaScript application that doesn't require an explicit build pipeline.

• You manage configurations for various stages in different version control repositories, and you want to consume these configuration files directly from version control as part of the deployment pipeline.

• You manage your infrastructure and configuration as code and you want to manage these files in a version control repository.

Because you can configure multiple artifact sources in a single release pipeline, you can link both a build pipeline that produces the binaries of your application as well as a version control repository that stores the configuration files into the same pipeline, and use the two sets of artifacts together while deploying.

Azure Pipelines supports Team Foundation Version Control (TFVC) repositories, Git repositories, and GitHub repositories.

You can link a release pipeline to any of the Git or TFVC repositories in any project in your collection (you'll need read access to these repositories). No additional setup is required when deploying version control artifacts within the same collection.

When you link a GitHub repository and select a branch, you can edit the default properties of the artifact types after the artifact has been saved. This is particularly useful in scenarios where the branch for the stable version of the artifact changes, and continuous delivery releases should use this branch to obtain newer versions of the artifact. You can also specify details of the checkout, such as whether checkout submodules and LFS-tracked files, and the shallow fetch depth.

When you link a TFVC branch, you can specify the changeset to be deployed when creating a release.

The following features are available when using TFVC, Git, and GitHub as an artifact source:

Artifact sources - Jenkins

To consume Jenkins artifacts, you must create a service connection to authenticate with your Jenkins server. See manage service connections and Jenkins service connection for more information. The Jenkins project must be configured with a post build action to publish your artifacts.

The following features are available when using Jenkins as an artifact source:

Artifacts generated by Jenkins builds are typically propagated to storage repositories for archiving and sharing. Azure blob storage is one of the supported repositories, allowing you to consume Jenkins projects that publish to Azure storage as artifact sources in a release pipeline. Azure Pipelines download the artifacts automatically from Azure to the agent running the pipeline. In this scenario, connectivity between the agent and the Jenkins server is not required. Microsoft-hosted agents can be used without exposing the server to internet.

Artifact sources - containers

When deploying containerized apps, the container image is first pushed to a container registry. You can then deploy your container image to Azure Web App for Containers or a Docker/Kubernetes cluster. You must create a service connection to authenticate with Azure. See manage service connections for more details.

The following features are available when using Azure Container as an artifact source:

Artifact sources - Azure Artifacts

Below are some of the scenarios where you can use Azure Artifacts as an artifact source:

1. Your application binary is published to Azure Artifacts and you want to consume the package in a release pipeline.
2. You need additional packages stored in Azure Artifacts as part of your deployment workflow.

Using Azure Artifacts in your release pipeline, you must select the Feed, Package, and the Default version for your package. You can choose to pick up the latest version of the package, use a specific version, or select the version at the time of release creation. During deployment, the package gets downloaded/extracted to the agent running your pipeline.

The following features are available when using Azure Artifacts as an artifact source:

Handling Maven snapshots

When using Maven snapshots, multiple versions can be downloaded at once (example myApplication-2.1.0.BUILD-20190920.220048-3.jar, myApplication-2.1.0.BUILD-20190820.221046-2.jar, myApplication-2.1.0.BUILD-20190820.220331-1.jar). You might need to remove the old version and only keep the latest Artifact before deployment. Run the following PowerShell command in an elevated command prompt to remove all copies except the one with the highest lexicographical value:

Get-Item "myApplication*.jar" | Sort-Object -Descending Name | Select-Object -SkipIndex 0 | Remove-Item

Artifact sources - TFS server

You can use Azure Pipelines to deploy artifacts from TFS servers without having to make your server discoverable on the Internet by setting up an on-premises automation agent. Artifacts are downloaded to the on-premises agent and then deployed to the specified target servers without leaving your enterprise network. This is ideal for customers to leverage their investments of their on-premises infrastructure while taking advantage of Azure Pipelines releases.

To use TFS servers as an artifact source, you must install the TFS artifacts for Azure Pipelines extension from the Visual Studio Marketplace, and then create a service connection to authenticate with Azure Pipelines. Once authenticated, you can then link a TFS build pipeline to your release pipeline and choose External TFS Build from the Type dropdown menu.

The following features are available when using TFS servers as an artifact source:

Azure Pipelines may not be able to contact an on-premises TFS server in case it's within your enterprise network. In that case you can integrate Azure Pipelines with TFS by setting up an on-premises agent that can access the TFS server. You will not be able to see the name of your TFS projects or build pipelines when linking to a build, but you can include those variables in the URL text fields. In addition, when you create a release, Azure Pipelines may not be able to query the TFS server for the build numbers. Instead, enter the Build ID (not the build number) of the desired build in the appropriate field, or select the Latest build.

Artifact sources - TeamCity

To use TeamCity as an Artifact source, you must first install the TeamCity artifacts for Azure Pipelines extension from Visual Studio Marketplace.

Once completed, create a service connection to authenticate with your TeamCity server. You can then link your build artifact to a release pipeline. The TeamCity build configuration must be set up with an action to publish artifacts.

The following features are available when using TeamCity as an artifact source:

Azure Pipelines may not be able to contact your TeamCity server if, for example, it is within your enterprise network. In this case you can integrate Azure Pipelines with TeamCity by setting up an on-premises agent that can access the TeamCity server. You will not be able to see the name of your TeamCity projects when linking to a build, but you can type this into the URL text field.

Artifact source alias

To ensure the uniqueness of every artifact download, each artifact source linked to a release pipeline is automatically provided with a specific download location known as the source alias. This location can be accessed by using the variable: $(System.DefaultWorkingDirectory)\[source alias]

Using a source aliases ensures that renaming a linked artifact source doesn't require editing the task properties because the download location defined in the agent does not change.

By default, the source alias is the name of the artifact source prefixed with an underscore. Depending on the type of the artifact source, this will be the name of the build pipeline, job name, project name, or the repository name. You can edit the source alias from the artifacts tab of your release pipeline.

Artifact download

When a deployment is completed to a stage, the versioned artifacts from each of the sources are downloaded to the pipeline agent so that tasks running within that stage can access those artifacts. The downloaded artifacts do not get deleted when a release is completed. However, when you initiate the next release, the downloaded artifacts are deleted and replaced with the new set of artifacts.

A new unique folder in the agent is created for every release pipeline when a release is initiated, and the artifacts are downloaded to the following folder:$(System.DefaultWorkingDirectory).

Azure Pipelines does not perform any optimization to avoid downloading the unchanged artifacts if the same release is deployed again. In addition, because the previously downloaded contents are always deleted when you initiate a new release, Azure Pipelines cannot perform incremental downloads to the agent.

Related articles

• Classic release and artifacts variables
• Classic release pipelines
• Publish and download pipeline Artifacts
• Add stages, dependencies, & conditions