Operations 16 min read

New Features in Team Foundation Server 2015 Release Management

The article outlines several enhancements to Release Management in Team Foundation Server 2015, including cloning, exporting and importing release definitions, test result display in release summaries, OAuth token passing to scripts, partial success handling, GitHub project usage, Azure Web App deployment, task groups, soft delete, retention policies, linked project improvements, manual intervention, SQL deployment scripts, dashboard widgets, scheduled and conditional deployments, REST API, service hook integration, and support for Azure China cloud.

DevOps
DevOps
DevOps
New Features in Team Foundation Server 2015 Release Management

Since the introduction of web‑based Release Management in Team Foundation Server 2015, several functional enhancements have been added.

Clone, Export, and Import Release Definitions

We have integrated cloning, exporting, and importing of release definitions directly in the Release hub without requiring an extension.

For details, see the "Clone, Export, and Import Release Definitions" documentation.

Test Results Shown in "Release Summary"

In the Release Summary page, contribution points are enabled for external services to display environment‑specific information.

In Team Services, this feature shows a summary of test results that ran as part of a release environment.

For details, see "Understanding the Release Summary View".

Passing OAuth Token to Scripts

Custom PowerShell scripts that call the REST API on Team Services can now receive the current OAuth token when run as a task in an environment.

A new option in environment configuration enables scripts to access the token.

See "General Options for Environments" for more information.

Below is a simple example showing how to obtain the generated definition:

Partial‑Success Triggers on Deployments

Both build and release tasks have a "Continue on error" option under the "Control Options" parameter.

In a build definition this can produce a "Build partially succeeded" result when a task marked to continue fails.

The same behavior is now available in release definitions; a failed task causes the overall release result to be "Release partially succeeded".

By default, partially successful releases do not automatically trigger deployment to subsequent environments, even if the environment deployment option is set.

A new option can be set per environment to trigger the next environment when the previous release is partially successful.

Using Projects Directly Stored in GitHub

You can now use a project stored in a version‑control system (e.g., GitHub) directly without passing it through the build process.

If your code resides in a GitHub repository, the same operation is supported.

AzureRM Web App Deployment

A new Azure Web App deployment task called "AzureRM Web App Deployment" uses MSDeploy and Azure Resource Manager service endpoints.

It can deploy ASP.NET 4, Node, Python web apps, as well as Azure Web Jobs and Azure API Apps.

The task also supports common options such as retaining app data, taking the app offline, and deleting extra files at the target.

Additional features like configuration transformation may appear in future releases.

Task Groups

Task groups let you package a series of tasks defined in a build or release definition into a single reusable task that can be added to other definitions.

Parameters can be extracted as configuration variables, and the remaining task information is retained.

New task groups are automatically added to the task catalog and ready for use.

Soft Delete of Releases

When a release is deleted or its retention policy removes it, it disappears from the overview and details lists.

However, it is retained in the definition for a period (typically 14 days) before permanent deletion.

During this window the release appears under the "Deleted" tab.

You can restore it via the context menu by selecting "Undo Delete".

Retention of Releases and Builds per Environment

The release retention policy determines how long linked releases and builds are kept.

By default releases are retained for 60 days and automatically deleted if not deployed or modified.

You may want to keep releases longer for certain environments (e.g., production) while allowing shorter retention for others (e.g., test, staging, QA).

If you need to redeploy a release, you can retain the associated build for the same period.

Linked Project Improvements

Two new features make handling projects and sources easier:

You can link multiple project sources to a single release definition; each source is downloaded to a folder on the agent named after its source alias. The alias can now be edited, for example when a build definition is renamed. See "Project Source Alias" for details.

Many Build.* variables (e.g., Build.BuildId, Build.BuildNumber) are now exposed for task parameters. When multiple sources are linked, the values from the primary source are used. See "Project Variables" for details.

Deployment – Manual Intervention Tasks

Deployments can now be paused.

Manual intervention tasks let you temporarily stop a deployment, perform manual steps, and then resume automated steps.

After manual intervention you can also reject the deployment and block further steps.

SQL Database Deployment Task Scripts

The Azure SQL Database deployment task has been enhanced to run SQL scripts against Azure SQL databases. Scripts can be supplied as files or inline within the task.

Release Definition Summary – Dashboard Widget

Pin a release definition to a dashboard to provide a simple view of release summaries visible to the whole team.

Promote a Release to an Environment at a Specific Time

You can configure a condition that selects an environment which has successfully deployed (or only the latest deployment) and schedule the promotion to that environment at a particular time, such as midnight for production.

Conditional Deployments Based on Multiple Environments

Previously you could run parallel (fork) deployments but could not start a deployment to an environment based on the status of multiple environments (join). This capability is now supported.

Release Management REST API

You can use the Release Management REST API to create release definitions, create releases, and manage various aspects of deployment.

Service Hook Integration

Send release notifications when a new release is created, when deployment starts or completes, or when approvals are pending or completed. Integrate with third‑party tools such as Slack to receive these notifications.

Deploy to Azure China Cloud

A new environment setting allows you to target specific Azure clouds, including the Azure China cloud, Azure US Government cloud, and Azure German cloud, using classic service endpoints.

See "Azure Classic Service Endpoints" for more information.

Follow the WeChat public account devopshub for more DevOps integration information.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

ci/cdDeploymentDevOpsAzureTFS
DevOps
Written by

DevOps

Share premium content and events on trends, applications, and practices in development efficiency, AI and related technologies. The IDCF International DevOps Coach Federation trains end‑to‑end development‑efficiency talent, linking high‑performance organizations and individuals to achieve excellence.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.