A release definition is one of the fundamental concepts in Release Management for Team Services and TFS. It defines the end-to-end release process for an application to be deployed across various environments.
You start using Release Management by authoring a release definition for your application. To author a release definition, you must specify the artifacts that make up the application and the release process.
An artifact is a deployable component of your application. It is typically produced through a Continuous Integration or a build process. Release Management can deploy artifacts that are produced by a wide range of artifact sources such as Team Build, Jenkins, or Team City.
You define the release process using environments, and restrict deployments into or out of an environment using approvals. You define the automation in each environment using phases and tasks. You use variables to generalize your automation and triggers to control when the deployments should be kicked off automatically.
An example of a release process that can be modeled through a release definition in shown below:
In this example, a release of a website is created by collecting specific versions of two builds (artifacts), each from a different build definition. The release is first deployed to a Dev environment and then forked in parallel to two QA environments in parallel. If the deployment succeeds in both the QA environments, the release is deployed to Prod ring 1 and then to Prod ring 2. Each production ring represents multiple instances of the same website deployed at various locations around the globe.
An example of how deployment automation can be modeled within an environment is shown below:
In this example, a phase is used to deploy the web and database tiers to websites across the globe in parallel within production ring 1. Once all of those deployments are successful, a second phase is used to switch traffic from the previous version to the newer version.
TFS 2015: Phases, and fork and join deployments, are not available in TFS 2015.
The names of releases for a release definition are, by default, sequentially numbered. The first release is named Release-1, the next release is Release-2, and so on. You can change this naming scheme by editing the release name format mask. In the General tab of a release definition, edit the Release name format property.
When specifying the format mask, you can use the following pre-defined variables.
|Rev:rr||An auto-incremented number with at least the specified number of digits.|
|Date / Date:MMddyy||The current date, with the default format MMddyy. Any combinations of M/MM/MMM/MMMM, d/dd/ddd/dddd, y/yy/yyyy/yyyy, h/hh/H/HH, m/mm, s/ss are supported.|
|System.TeamProject||The name of the team project to which this build belongs.|
|Release.ReleaseId||The ID of the release, which is unique across all releases in the project.|
|Release.DefinitionName||The name of the release definition to which the current release belongs.|
|Build.BuildNumber||The number of the build contained in the release. If a release has multiple builds, this is the number of the primary build.|
|Build.DefinitionName||The definition name of the build contained in the release. If a release has multiple builds, this is the definition name of the primary build.|
|Artifact.ArtifactType||The type of the artifact source linked with the release. For example, this can be Team Build or Jenkins.|
|Build.SourceBranch||The branch of the primary artifact source. For Git, this is of the form master if the branch is refs/heads/master. For Team Foundation Version Control, this is of the form branch if the root server path for the workspace is $/teamproject/branch. This variable is not set for Jenkins or other artifact sources.|
|Custom variable||The value of a global configuration property defined in the release definition.|
For example, the release name format
Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName) will create releases with names such as Release 002 for build 20170213.2 MySampleAppBuild.
You can customize how long releases of this definition must be retained. For more information, see release retention.
Every time you save a release definition, Release Management keeps a copy of the changes. This allows you to compare the changes at a later point, especially when you are debugging a deployment failure.