Releases in Release Management

VSTS | TFS 2018 | TFS 2017 | TFS 2015

A release is the package or container that holds a versioned set of artifacts specified in a release definition. It includes a snapshot of all the information required to carry out all the tasks and actions in the release definition, such as the environments, the task steps 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 released definition, and information about each one is stored and displayed in Release Management for the specified retention period.

A deployment is the action of running the tasks for one environment, which results in the application artifacts being deployed, tests being run, and whatever other actions are specified for that environment. Initiating a release starts each deployment based on the settings and policies defined in the original release definition. There can be multiple deployments of each release even for one environment. When a deployment of a release fails for an environment, you can redeploy the same release to that environment.

The following schematic shows the relationship between release definitions, releases, and deployments.

Relationship between release definitions, releases, and deployments

Releases (and, in some cases, draft releases) can be created from a release definition 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 the Releases tab or the Builds tab.

  • 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 an environment, 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 environment.

  • 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 environment other than the last environment in a release pipeline. For example, it may specify that the release is deployed only as far as the QA environment and not to the production environment.

  • There may be queuing policies defined for an environment, which specify which of multiple deployments will occur, or the order in which releases are deployed.

  • There may be pre-deployment approvers defined for an environment, and the deployment will not occur until all necessary approvals have been granted.

  • Approvers may defer the release to an environment until a specified date and time using a scheduled trigger.

See also

Help and support