Archived release notes for Microsoft Release Management

Last Update: 3/16/2017

Team Services | TFS 2017 | TFS 2015 | Previous versions

NOTE: Release Management has now been combined with the Build features of Team Services and Team Foundation Server (TFS) in the new Build & Release hub. For details of new features and changes, see Team Foundation Build & Release release notes.

What's new?

The following changes, categorized by release date, were added to Release Management:

November 23, 2016 Update (Team Services)

This update has the following new features:

New licensing model for Build and Release Management

Build and Release Management has moved from the current agent-based licensing model to a concurrent pipeline based licensing model. Each pipeline lets you run one build or deploy one release at a time. The maximum number of concurrent builds you can run and releases you can deploy at the same time is limited only by the number of pipelines you have.

Your Team Services account includes these free amounts:

  • One free Hosted Pipeline: With this free hosted pipeline, you get four hours (240 minutes) per month and a maximum duration of 30 minutes per build or deployment. If you just need more build time for once concurrent build or release, buy another hosted pipeline without the four hour limit to increase your maximum duration per build or deployment up to six hours. For more concurrent builds or releases, buy more hosted pipelines.
  • One free Private Pipeline: With this free private pipeline, run unlimited concurrent builds or deploy one release at a time in Team Foundation Server 2017, or run one build or deploy one release at a time in Team Services on agent software from Microsoft. Private agents are now free and unlimited. In TFS, each Visual Studio Enterprise subscriber also contributes a private pipeline that you can use. You can also buy more private pipelines.

For more information, see Concurrent build and release pipelines in Team Services and Concurrent release pipelines in TFS.

If you previously bought private agents in the Azure portal, they'll automatically roll into private pipelines. Similarly, any hosted agents that you purchased become Hosted pipelines. With the new licensing model, you can register any number of private agents with your account. In effect, the new model gives you more than the previous model, for the same price.

Build and deploy Docker apps to Azure more easily

To make continuous integration and deployment (CI/CD) of Docker apps a lot simpler, we have:

  • Updated the Docker extension with support for Azure Container Service and Azure Container Registry.
  • Begun a preview of the Hosted Linux pool so that you don't have to set up your own Docker hosts.
  • Released Visual Studio 2017 RC and included new continuous delivery tools for ASP.NET Core Preview apps. You can use these tools to configure a CI/CD process quickly in Team Services. Any ASP.NET Core project with Docker support enabled can be set up to run an automated build and deployment to Azure Container Service with every Git push.

Hosted Linux pool preview

We're offering a preview of our new hosted Linux pool to enable you to build and release on Linux machines without having to configure a private agent.

The agents in the hosted Linux pool run on an Ubuntu Linux host inside the vsts-agent-docker container. This container includes all the standard Java, Node, Docker and .NET Core tooling. When we start the container we map in the Docker socket from the host VM and the working folder from /opt/vsts/work. This enables you to create or spawn other Docker containers as part of your build or release process using either a script or the Docker extension in the Visual Studio Marketplace.

To use the Hosted Linux pool:

  • In your build definition, go to the General tab, open the Default agent queue menu, and then select Hosted Linux.
  • In your release definition, go to the Environments tab, select your Run on agent task, open the Deployment queue menu, and then select Hosted Linux.

If you don't see the option yet, just give it a little time. We're rolling this option out to accounts over the next few weeks.

Task versioning for Build and Release definitions

By popular request, we're giving you control over the major version of a task that you run in your build or release. We expect this change to result in fewer unpredictable errors that were caused by automatic updates to the agent and task version. You now specify the major version of the task on the Build tab of your definition, or on the Environments tab of your release definition.

When a minor version is released (for example, 1.2 to 1.3), you get that change automatically in your build. But if a new major version is released (for example 2.0), your build stays locked to version 1.3 until you edit the definition and manually change to the new major version. A flag in the build definition alerts you to new major versions.

If you select a version named something such as 1.* (preview), keep in mind that this version is still under development and might have known problems.

Tip: In a build definition, you have a few options to test a new major version of a task. If you change the version and have problems, you can revert the change from the History tab. Clone the build definition and test the cloned definition with the new major task version.

Inline service connections in Build and Release

With this feature, you can create service connections right in the build or release definition without having to navigate to the Services tab. This will be auto-enabled for all extensions which are defined declaratively, such as Docker, Jenkins, VMWare, and SCVMM.

Link build artifacts from another team project

Until now, release definitions could only link artifact sources from the current project. Now, you can now link build artifacts from another project as well. While linking an artifact, the project drop down will list all the projects in the account.

Build artifacts dialog

November 16, 2016 Update (Team Services, TFS 2017)

Today we're announcing TFS 2017, which includes all the Release Management features that you currently get on Team Services. We're introducing a pricing model based on concurrent pipelines for Release Management in TFS 2017.

We're also announcing general availability of Release Management in Team Services. Also, later this month, we're moving to a pricing model based on concurrent pipelines for both Team Foundation (TFBuild) and Release Management in Team Services. (Previously you paid for agents.)

Release Management users are free: Your team members no longer need subscriptions to author definitions. Team Services users (with basic access) and users with a TFS Client Access License (CAL) can author releases for no additional charge. All types of users (including stakeholders) can approve releases for free.

No charge for private agents: Private agents are now free. In Team Services, you used to have to license each private agent after the first. Now you can run deployments concurrently for no additional charge.

Concurrent pipelines: For each release process that you want to run concurrently, you need a concurrent pipeline. Some concurrent pipelines are included. If you need more, you can add more in a few ways.

Concurrent pipelines for your releases in Team Foundation Server

Concurrent pipelines for your builds and releases in Visual Studio Team Services

October 12, 2016 Update (Team Services)

This update has the following new features:

Multiple schedules in releases

Want to schedule your releases to be created more than one time in a day? You can now configure multiple scheduled triggers in a release definition.

Azure Resource Group improvements

Currently, when using the Azure Resource Group task, there is no way to validate if the ARM template is syntactically correct and would be accepted by the Azure Resource Manager without actually deploying the resources. This enhancement allows a new deployment mode called Validation Only where users can find problems with the template authoring before creating actual Azure resources.

Another enhancement to the Azure Resource Group task is to allow either incremental or complete deployments. Currently, the task deploys the ARM templates using the Incremental mode. This mode handles deployments as incremental updates to the resource group. It does not modify resources that exist in the resource group but are not specified in the template. Complete mode deletes resources that are not in your template. By default, Incremental mode is used.

Azure Resource Group improvements

See Azure Resource Group Deployment Task.

Azure CLI task

The new Azure CLI task supports running Azure CLI commands on cross-platform agents such as Windows, Linux and Mac. The task supports both Classic and ARM subscriptions. It also supports two modes of providing the script: as a linked artifact or as an inline script.

Azure CLI task

See Deploy: Azure CLI.

Simplified Azure endpoint creation

In an earlier sprint, we made it easier to create a new Azure Resource Manager service endpoint from Team Services. That experience only worked in accounts that are backed by Azure Active Directory. In this deployment, we are bringing the same simplified experience for all the other accounts not backed by an AAD. So, if you have a Microsoft account and an Azure subscription that you would like to deploy to from Team Services, you can create an Azure Resource Manager endpoint without needing to run tedious PowerShell scripts or follow the steps in a blog.

See Azure Resource Manager service endpoint.

September 21, 2016 Update (Team Services)

Deployment Status widget

A build can be deployed and tested in different release environments across multiple release definitions. In such a scenario, the Deployment Status widget shows you a consolidated status of the deployment and test pass rate across multiple environments for a recent set of builds from a build definition.

September 2, 2016 Update (Team Services)

This update has the following new features:

Jenkins with untrusted SSL certificates

Jenkins connections can now be configured to accept untrusted SSL certificates of Jenkins servers. This is useful when Team Services service hooks, or build and release processes, integrate with Jenkins. For example, if a Jenkins server is configured to use SSL with a self-signed certificate or a certificate that cannot be verified by a Certificate Authority (CA), this setting lets administrators deliberately trust the certificate.

Specifying an untrusted certificate for a Jenkins connection

For more information about Jenkins integration capabilities, see Team Services Integration with Jenkins Jobs, Pipelines, and Artifacts.

Deployment manual intervention

You can now pause execution during deployment to an environment. Including a Manual Intervention task in an environment enables you to temporarily halt a deployment, perform manual steps, and then resume further automated steps. You can also reject the deployment and prevent further steps from executing after a manual intervention.

For more details, see Manual intervention.

Service endpoint improvements

An option to validate the connection has been added to all service endpoint dialogs so that users can test that the parameters they entered are correct. The link uses a REST call to the external service using the information entered, and returns success when the REST call passes.

Service endpoints have also been enhanced by the introduction of icons. Service endpoint authors can specify the icon to be displayed for each endpoint they create.

SQL database deployment task scripts

The Azure SQL Database Deployment task has been enhanced to run SQL scripts against an Azure SQL Database. The scripts can be provided as a file, or inline within the task.

Using a script with an Azure SQL Database Deployment task

July 28, 2016 Update (Team Services)

This update has the following new features:

Task groups

A task group lets you to encapsulate a sequence of tasks already defined in a build or a release definition into a single reusable task that can be added to a build or release definition just like any other task. You can choose to extract the parameters from the encapsulated tasks as configuration variables, and abstract the rest of the task information. The new task group is automatically added to the task catalogue, ready to add to other release and build definitions.

Task groups to encapsulate multiple tasks

For more details, see Task groups.

Create agent queues

You can now create agent queues from within a team project by selecting a pool that is not referenced by any other queue in the team project, or create a queue with a new pool.

For more details, see Configure agent pools and queues.

Easier Azure deployment

Two new features make it easier to deploy applications to Azure:

  • Simplified Service Principal Authentication configuration. If the Team Services or TFS instance you are using is backed by Azure Active Directory authentication, a simplified version of the service endpoint dialog allows you to select an existing Azure subscription. This automatically creates a new Azure service principal that is assigned the Contributor role and so has access to all resources within the subscription. For more details, see Azure Resource Manager service endpoint.

    Configuring a Service Principal Authentication based Azure service endpoint

  • Deployment to national Azure clouds. Use the new Environment setting in an Azure Classic service endpoint to target a specific Azure cloud, including pre-defined national clouds such as Azure China cloud, Azure US Government cloud, and Azure German cloud. For more details, see Azure Classic service endpoint.

    Configuring an Azure Classic service endpoint to target a specific Azure cloud

Soft delete of releases

When you delete a release, or it is automatically deleted by a retention policy, the release is removed from the overview and details lists. However, it is retained with the release definition for a period (typically 14 days) before it is permanently deleted. During this period, it is shown in the Deleted tab of the overview and details lists. You can restore any of these releases by opening the shortcut menu and choosing Undelete.

Retain releases and builds for each environment

The release retention policy for a release definition determines how long a release and the build linked to it are retained. By default, a release is retained for 60 days - releases that have not been deployed or modified during that time will automatically be deleted. However, you may want to retain more releases that have been deployed to specific environments, such as your production environment, or retain them longer than those that were just deployed to other environments such as test, staging, and QA. You can also retain the build linked to a release for the same period as the release to ensure that the artifacts are available if you need to redeploy that release.

Filter releases by source code branch

Use the new Branch drop-down list to filter the list of releases by the branch from which the artifacts were generated.

Linked artifact improvements

Two new features make it easier to work with artifacts and artifact sources:

  • You can link multiple artifact sources to a release definition. Each of the artifacts is downloaded into a folder on the agent called the source alias. You can now edit the source alias of a linked artifact. For example, when you change the name of the build definition, you can edit the source alias to reflect the name of the build definition.

    For more details, see Artifact source alias.

  • A number of variables of the format Build.* (such as Build.BuildId and Build.BuildNumber) are exposed for use in task parameters. When multiple sources are associated with a release, these variables are now populated with values from the artifact source you specify as the primary source. For more details, see Artifact variables.

Rollback and redeploy earlier releases

If a deployment to an environment fails, you may want to redeploy an older release that already succeeded in that environment. Now, when you start to deploy an older release, you see a list of commits and work items that will be rolled back. You just need to make sure that the automation scripts for the deployment can handle the rollback scenario.

June 24, 2016 Update (Team Services)

This update has the following new features:

Clone, export, and import release definitions

By popular demand, we have incorporated the ability to clone, export, and import release definitions within the Release hub in Team Services, without requiring installation of an extension. If you are using Team Foundation Server 2015 Update 2 or higher, you can download and install this extension from Visual Studio Marketplace to get the same functionality.

Clone and export commands on release summary page

Test results displayed in the release summary

In the release summary page, we have enabled a contribution point for an external service to show environment-specific information. In Team Services, this functionality is used to display a summary of test results when tests are run as part of a release environment.

Test results - if any - displayed in a release summary

Pass OAuth tokens to scripts

If you need to run a custom PowerShell script that invokes the REST APIs on Team Services, perhaps to create a work item or query a build for information, you need to pass the OAuth token in the script. A new option when you configure an environment allows scripts run as tasks in the environment to access the current OAuth token.

Setting the option to allow access to the OAuth token

For more details, see Agent phase properties

This is a simple example showing how to get a build definition:

$url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=2.0"
Write-Host "URL: $url"
$definition = Invoke-RestMethod -Uri $url -Headers @{
       Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Host "Definition = $($definition | ConvertTo-Json -Depth 1000)"

Task-level timeouts

In addition to specifying the timeout for an entire deployment, you can now specify the timeout for every task individually; in both release and build definitions. This allows you to exert more fine-grained control over the release and deployment process. The value is specified in the Control Options parameters for each task as a number of minutes. The default is zero (infinite timeout).

Setting the timeout for a task in a release definition

For more details, see Out-of-the-box tasks

Trigger on partially successful deployments

Build and release tasks have an option to Continue on error in the Control Options parameters for each task. In a build definition, this results in a Build partially succeeded result if a task with this option set should fail. The same behavior is now available in release definitions. If a task fails, the overall release result will show as "Release partially succeeded".

Release summary shows partially successful releases in orange color

By default, a partially successful release will not automatically trigger a release to a subsequent environment, even if this behavior is specified in the environment deployment options. However, a new option can be set in each release environment that instructs Release Management to trigger a release to a subsequent environment when the previous release is partially successful.

Setting the option to trigger from a partially successful release

For more details, see Environment deployment triggers

Consume artifacts stored in GitHub directly

Sometimes you may want to consume artifacts stored in a version control system directly, without passing them through a build process, as described in this topic. You can now do the same if your code in stored in a GitHub repository.

Linking code in a GutHub repository to a release definition

For more details, see TFVC, Git, and GitHub sources

Jenkins plug-in for Release Management

Users of Jenkins CI can now create releases more easily by using the VS Team Services Continuous Deployment Plugin, available from the Jenkins website. This plugin triggers a release in TFS or Team Services when a build completes successfully. Use it to add post-build steps right into Jenkins CI projects to create a new release. This, along with the ability for Release Management to understand and download Jenkins artifacts, provides great end-to-end integration between these two tools.

For more details, see Jenkins sources

Add attachments to release summaries

You can upload additional files, images, logs, or other diagnostics aids when running tasks in a release. The files are uploaded during the deployment and are then included in the release summary and "Download all log files" actions. To upload a new file, use the following agent command in your script:

Write-host "##vso[task.uploadfile]<filename>"

Deploy SQL DACPACs

The IIS Web App deployment using WinRM extension available from Visual Studio Marketplace now supports deployment of database DACPACs. Use this capability to deploy IIS web apps and databases from Team Services and TFS.

Web app deployment using ARM

A new version of the Azure Web App Deployment task is available, called AzureRM Web App Deployment. It uses MSDeploy and an Azure Resource Manager service endpoint connection. Use this task to deploy Azure Web Jobs and Azure API apps, in addition to ASP.NET 4, Node, and Python based web apps. The task also supports common publishing options such as the ability to retain app data, take an app off-line, and remove additional files at the destination. More features, such as configuration transformations, may appear in forthcoming versions.

Using the AzureRM Web App Deployment task in a release definition

May 23, 2016 Update (Team Services)

This update has the following new features:

Docker integration

Take advantage of the Team Services cloud based build capabilities to build your Docker images, and upload them to Docker Hub as part of your continuous integration flow. Then deploy those images to a number of Docker hosts as part of Release Management. The Docker extension in VisualStudio Marketplace adds all the service endpoint types and tasks necessary for you to work with Docker from Team Services.

TeamCity integration

If you are a TeamCity user, you can now consume TeamCity builds as artifacts in Release Management. Install the TeamCity artifacts extension from VisualStudio Marketplace to setup a TeamCity service endpoint. Then configure your release definitions to deploy artifacts produced by TeamCity builds. See TeamCity artifact sources.

Service hooks integration

Send release notifications when new releases are created, deployments are started or completed, or when approvals are pending or completed. Integrate with third party tools such as Slack to receive such notifications.

Release Management client SDK

In the last update, we published the Release Management REST APIs. In this update, we are publishing a C# client SDK to help you easily integrate your applications with Release Management. The SDK is available as a NuGet package. Example usage for this SDK can be found here.

Apr 26, 2016 Update (Team Services)

This update provides several major improvements to Release Management:

Simplified wizard to create a release definition

Try the simplified wizard for creating a release definition. You can enter most of the inputs in this wizard to set up a definition with a single environment. We have also simplified the process of adding more environments to a definition, and cloning an environment.

Simplified wizard to create a release definition

View the history of a release

View all the activity on a release in one place; including deployments, approvals, configuration edits, and more.

NOTE: This feature is being rolled out over time to all regions; therefore, it may not yet be available in your region.

TFVC and TF Git as artifact sources

Do you develop apps (such as PHP) that can deployed directly, without having to be built first? Do you manage your config files in source control repositories, and would like to consume them directly in Release Management without needing to publish build artifacts with the same files?

Release Management supports linking Team Foundation Version Control (TFVC) and Team Foundation Git repositories as artifact sources in a release definition. At present there is no support for auto-triggering new releases when a commit is made into these repositories.

TFVC and TF Git as artifact sources

Promote releases to an environment at a specific time

Want all of your production deployments to happen at midnight? You can configure a condition on an environment that selects a successful deployment (or just the latest one) from another environment, and deploys it at the specified time.

View the history of a release

REST APIs for Release Management

You can use the REST APIs for the Release Management service to create release definitions and releases, and manage many aspects of deploying a release. Most of these APIs also work with the on-premises releases of Release Management in TFS 2015 Update 2 (the differences between TFS and Team Services versions are indicated in the documentation). You'll find some basic examples that use the APIs in this blog post.

Import, export, and clone release definitions

Looking for a way to clone release definitions? Or copy release definitions from one team project to another? These features will be available out-of-the-box soon, but until then you can use an extension available from Visual Studio Marketplace.

Additional variables available during job execution

When there are multiple artifact sources linked to a release definition, you can access information about all the artifact sources when executing deployment jobs. The information is available from variables of the format:

RELEASE_ARTIFACTS_[alias]_[variable-name]

When used in a script, replace the underscore with a period:

RELEASE.ARTIFACTS.[alias].[variable-name]

Replace [alias] with the name of the alias for the artifact source included in the release definition. You can find the alias name in the Artifacts tab of a release definition.

Replace [variable-name] with one of the following:

  • DEFINITIONID
  • BUILDNUMBER
  • BUILDID
  • REPOSITORY_NAME
  • SOURCEBRANCH
  • SOURCEBRANCHNAME
  • SOURCEVERSION
  • BUILDURI
  • REQUESTEDFORID
  • REPOSITORY_PROVIDER
  • REQUESTEDFOR
  • TYPE

Apr 8, 2016 Update (Team Services)

Consume TFS build artifacts in Team Services Release Management

A new extension makes it easy to deploy on-premises TFS builds with Team Services Release Management, even if the TFS machine is not reachable directly from Team Services. The extension adds a TFS service endpoint connection, and you use a new type of artifact named Team Build (external) through which you deploy builds from the TFS machine.

You must install a non-hosted agent on a machine that is able to connect to your TFS machine and configure this agent in Team Services. The extension does not yet work for deploying XAML builds.

For more information, see this blog post.

Email release summary

Send the details of a release, including all the sections (such as deployment status, work items, commits, and build details) to email recipients.

Release definition summary - dashboard widget

Pin a release definition to the dashboard - an easy way to make a summary of releases for that definition visible to all your team.

Deploy based on conditions in multiple environments

Until now, you could do parallel deployments (fork deployments), but you could not start a deployment to an environment based on the status of multiple environments (join deployments). Now you can, as this video demonstrates.

For more details, see Parallel forked and joined deployments

Mar 15, 2016 Update (Team Services)

Inline scripting with the PowerShell task

You can now author an inline PowerShell script within a release definition by using the PowerShell task. This is ideal for those simple scenarios where you do not want to check in and publish the script as part of a build artifact.

Inline Powershell script

Release management utilities extension

Token replacement in configuration files and support for rolling back a deployment and leaving an environment in a clean state are two of the most requested features in Release Management. It will take us some time to get these features into the product in a more integrated manner, but in the meantime we have provided a convenient extension you can install from Visual Studio Marketplace to satisfy these requirements. The extension adds a number of tasks to your task catalog:

  • The Tokenization task helps in replacing special tokens in any configuration file with the required environment-specific values at release time.

    Inline Powershell script

  • The Rollback task that checks whether any of the previous tasks in the environment have failed, and provides that information to your custom PowerShell script. Based on information about which task has failed, your custom script can run appropriate cleanup logic.

Mar 3, 2016 Update (Team Foundation Server)

All the features of Release Management described in this guidance are now available within Team Foundation Server 2015 Update 2 Release Candidate 2.

Feb 24, 2016 Update (Team Services)

This update provides several major improvements to Release Management:

Test results in releases

The new Tests tab in a release gives you a complete picture of the tests that were run in each environment of the release, and helps you analyze their trends.

Tests tab in releases

Integration with VMware

With the new VMware extension published to Visual Studio Marketplace, you can connect to a VMware vCenter server from Team Services or Team Foundation Server and create, delete, or apply snapshots to virtual machines managed in vCenter.

This allows you to create build and release definitions in which you deploy to virtual machines managed in VMware after dynamically provisioning them, or after restoring them from a clean snapshot.

Integration with System Center Virtual Machine Manager (SCVMM)

With the new SCVMM extension published to Visual Studio Marketplace, you can connect to the SCVMM servers managed in the SCVMM administration console. You can then use the extension to create virtual machines from a template; create, delete, and apply checkpoints; or run PowerShell scripts with SCVMM cmdlets.

This allows you to replicate one of the key features from Team Foundation Server Lab Management. You can now create build and release definitions in which you deploy to virtual machines managed in SCVMM after restoring them to a clean checkpoint. Additional actions to create and delete virtual machines may be available in future revisions of this extension.

Deployment to Tomcat server

You can deploy your Java web applications to a Tomcat server using the new Apache Tomcat extension available from Visual Studio Marketplace.

Deployments shown in build summary

Continuing our theme of great integration between Build and Release Management, you can now see a new section in your build summary that shows a list of environments into which that build has been deployed through Release Management. You can also create a new release from this section.

Specify the target environments to deploy to when creating a release

After you create a new release, it may be deployed automatically to the configured environments based on the deployment conditions you defined for each of the environments. However, there are situations where you might not want to deploy a release automatically to certain environments, and instead want to override these conditions.

The Automated deployments section of the Create new release dialog now provides the capability to "turn off" automatic deployment to environments when creating a new release.

Specifying the rule for an automated deployment

A note on security: this feature does not offer full flexibility for editing the deployment flow graph across environments to all those with permission to create a new release. That flexibility is still only available to release definition authors.

Scheduled trigger for creating new releases

Until now, you could only specify a continuous deployment trigger that automatically created a new release immediately. With this update, you can also specify a schedule for the creation of new releases. The latest version of successfully built artifacts are used when creating the release at the scheduled time.

After the release is created, the way that it is automatically deployed to environments is determined by the deployment conditions configured on those environments. You configure a scheduled trigger for creating new releases on the Triggers tab of a release definition.

Scheduled trigger

Retention policies for releases

You can now control how long releases are retained by setting a retention policy for each release definition. The default retention policy for all release definitions is 60 days and so releases that have not been deployed or modified during that time will automatically be deleted.

This policy comes into effect only for new releases that you create after this version update has been deployed. Releases created prior to this change will be retained for 365 days.

Configuring retention policies

At present retention policies for Release Management are independent of the retention policies for builds.

Feb 12, 2016 Update (Team Foundation Server)

All the features of Release Management described in this guidance are now available within Team Foundation Server 2015 Update 2 Release Candidate 1.

Feb 11, 2016 Update (Team Services)

This update provides several major improvements to Release Management:

More control over the order of deployments to environments in a release

You now have the flexibility to implement triggered deployment orchestration on each environment in a release definition. No longer are you constrained to a linear deployment pipeline. For example, these scenarios can be easily implemented:

  • After a build is completed, you can deploy and run automated tests in parallel on multiple environments or configurations.
  • After a release is successfully deployed to a development environment, you can deploy and test it on multiple QA environments in parallel.
  • You can specify that a deployment to production must always be triggered manually.
  • You can skip environments and manually promote the release to a selected environment.

Configuring environment conditions

For more details, see Environment deployment triggers

More control over queuing of deployments into the same environment

To give you better control over how multiple pending releases are deployed into a given environment, we have introduced queuing policies for environments. Your CI pipeline may produce builds faster than they can be deployed to environments in a release management process, or multiple releases may be queued up on a production environment awaiting approval after they have passed QA. Queuing policies allow you to deploy in parallel, deploy in sequence, or just deploy the latest one. See Queuing policies

Configuring queuing policies

Know before you deploy

Every time you start to manually deploy a release to an environment, you see a summary of what is being deployed into that environment. This is based on computing the difference between the current release and the last release that was deployed into that environment.

More control over time of deployment into an environment

You may want to approve a release now, but have it deployed to the target environment at a specific time in the future. We have added the capability to schedule a deployment; for example, deployment to a production environment at a specified time such as midnight.

Specifying a deferred deployment

More control over approvals

We added approval options that enable you to configure multiple approvers for an environment, and control whether these approvers can approve in parallel or in a specified order. See Approvals and approvers.

Configuring approval policies

Add your own release summary sections

You can now publish new sections into the release summary by using a specific syntax. For example, having the following line in your task will produce a new section called Attachments containing the contents of the file you specify:

Write-Verbose ##vso[Task.UploadSummary] Attachments.md

December 1, 2015 Update (Team Services)

  • More tasks. Until now, only a subset of tasks that were available in Build were available in Release Management. With this update, the set of tasks that you can use in Build and Release Management are exactly the same.

  • Simplified file copy and remote PowerShell tasks. Copy files to Windows machines or run remote PowerShell scripts easily by directly specifying a list of machines as inputs.

  • Provision Azure virtual machines and run remote scripts on them. Use the Azure Resource Group Deployment task to dynamically provision virtual machines, and run remote PowerShell scripts using the PowerShell on Target Machines task. Tie the output of the first task to the input list of machines in the second task.

November 18, 2015 Update (Team Services)

  • Public preview. Release management service is open to everyone as part of the public preview program.

November 03, 2015 Update (Team Services)

  • Work items and commits in a release. You can now see the new work items and commits that went into a release when compared with the previous release. This will help you understand the contents of a release. There is more work needed in this space, but this is a start.

  • Release definition history. You can now see what's changed in a release definition. Track the changes in a release definition using the History tab.

  • Configurable email settings. Choose whether the environment owner should be notified of all deployments, or only failed deployments.

October 19, 2015 Update (Team Services)

  • Hosted agents support. You can now use hosted agent pool for running deployment tasks in your releases. To start using the hosted agent, select each environment in a release definition in turn, open the shortcut menu from the ellipses (...), and select Agent options. In the CONFIGURE dialog for each environment, select Hosted as the default queue.

    Selecting the Hosted queue when configuring an environment

  • Branch information in releases. View information about the code branch in the Releases status list. This gives a better understanding of what your releases contain.

    Branch information is shown in release status

September 21, 2015 Update (Team Services)

  • Live logs. Live view in your browser of deployment logs streamed from the automation agent.

  • Release name configuration. Specify the name and sequential numbering format for releases by entering a format mask.

  • Deploy from Build hub. Create a release and deploy it right from the Build hub. Simply right click on a completed build, and select the Release menu.

  • Integration with TFS on-premises builds. Now you can start using Release Management service in Team Services, even when you have been using an on-premises TFS server for your builds. See On-premises TFS sources for more details.

  • IIS and SQL Database deployment tasks. Deploy IIS web applications and DACPACs with ease using these tasks.

September 4, 2015 Update (Team Services)

  • Consume Build artifacts more easily. You can now easily consume multiple artifacts published within a Team Build from RM. Linking a build definition to a release definition has also been simplified.

    However, this change is a breaking change that requires you to edit and save your release definitions again. In particular, the paths to which artifacts are downloaded by the agent have changed. With this update, all artifacts provided by a source (build definition) are downloaded to the $(System.DefaultWorkingDirectory)\{build definition name} folder by the agent. Use the artifact file picker whenever possible to specify the paths to files as you set the parameters of tasks.

    If you already have release definitions created prior to this update, open each release definition in turn and:

    • Remove the artifacts that were added to the definition
    • Re-link the artifact sources (add them back) to the definition
    • Re-establish the trigger to that artifact source
    • Edit the properties of the tasks to ensure that the input paths are correctly specified
    • Save the release definition
  • Select artifacts more easily. A file picker has been introduced for selecting files from the artifact folder structure when setting the parameters for tasks. This is one of the features most requested by early users.

  • Agent queues. The Release Management agent pools now use queues. Build and Release Management use the same pools and queues with this update.

  • Compare and view configuration variables. Users can now view all of the configuration variables across environments in a release definition or in a release using the Variables page.

  • Re-assign approvals. Instead of approving or rejecting an approval request, approvers can now re-assign the approval to another user or group.

  • Notification emails. Release Management now sends email messages to approvers when an approval is pending, and to environment owners when the deployment to an environment has completed.

  • Azure Service Principals. When adding an Azure service endpoint, you can now specify a service principal based authentication. This will be required if you use 2-Factor Authentication with Azure Active Directory.