Build and Release Tasks

Last Update: 4/26/2017

TFS 2015 | TFS 2017 | Team Services

A task is the building block for defining automation in a build definition, or in an environment of a release definition. A task is simply a packaged script or procedure that has been abstracted with a set of inputs. We provide some built-in tasks to enable fundamental build and deployment scenarios.

In addition, Visual Studio Marketplace offers a number of extensions; each of which, when installed to your account or collection, extends the task catalog with one or more tasks. Furthermore, you can write your own custom extensions to add tasks to your account in Team Services or your collection in TFS.

When you add a task to your build or release definition, it may also add a set of demands to the definition. The demands define the prerequisites that must be installed on the agent for the task to run. When you run the build or deployment, an agent that meets these demands will be chosen.

When you queue a build or a deployment, all the tasks are run in sequence, one after the other, on an agent. To run the same set of tasks in parallel on multiple agents, or to run some tasks without using an agent, see phases.

Task versions

Each task has a Version selector that enables you to specify the major version of the task used in your build or deployment. This can help to prevent issues when new versions of a task are released. Tasks are typically backwards compatible, but in some scenarios you may encounter unpredictable errors when a task is automatically updated.

When a new minor version is released (for example, 1.2 to 1.3), your build or release will automatically use the new version. However, if a new major version is released (for example 2.0), your build or release will continue to use the major version you specified until you edit the definition and manually change to the new major version. The build or release log will include an alert that a new major version is available.

Notes:

  • If you select a preview version (such as 1.* Preview), be aware that this version is still under development and might have known issues.

  • If you change the version and have problems with your builds, you can revert the definition change from the History tab. The ability to restore to an older version of a release definition is not currently available. You must manually revert the changes to the release definition, then save the definition.

  • Consider cloning the definition and testing the cloned definition with the new major task version.

Task control options

Each task offers you some Control Options.

Enabled

Clear this check box to disable a task. This is useful when you want to temporarily take task out of the process for testing or for specific deployments.

TIP

You can also right-click the task to toggle this setting.

Timeout

The timeout for this task in minutes. The default is zero (infinite timeout). Setting a value other than zero overrides the setting for the parent task phase.

Team Services options

Continue on error (partially successful)

Select this option if you want subsequent tasks in the same phase to possibly run even if this task fails. The build or deployment will be no better than partially successful. Whether subsequent tasks run depends on the Run this task setting.

Run this task

Select the condition for running this task:

  • Only when all previous tasks have succeeded

  • Even if a previous task has failed, unless the build was canceled

  • Even if a previous task has failed, even if the build was canceled

  • Only when a previous task has failed

NOTE

If you're running tasks in cases when the build is canceled, then make sure you specify sufficient time for these tasks to run the definition options.

TFS 2015 and TFS 2017 options

Continue on error (partially successful)

Select this option if you want subsequent tasks in the same phase to run even if this task fails. The build or deployment will be no better than partially successful.

Always run

Select this check box if you want the task to run even if the build or deployment is failing.

Build tool installers (Team Services)

Team Services preview feature

To use this capability you must be working on Team Services and enable the Task tool installers preview feature for your account.

Tool installers enable your build process to install and control your dependencies. Specifically, you can:

  • Install a tool or runtime on the fly (even on hosted agents) just in time for your CI build.

  • Validate your app or library against multiple versions of a dependency such as Node.js.

For example, you can set up your build process to run and validate your app for multiple versions of Node.js.

Example: Test and validate your app on multiple versions of Node.js

TIP

Want a visual walkthrough? See our April 19 news release.

Create a new build definition (start with an empty process) to try this out.

Tasks tab

Add these tasks:

icon Tool: Node Installer

  • Version Spec:

    $(NodeVersionSpec)
    

icon Utility: Command Line

  • Tool (if you're running on a Windows agent)

    where
    
  • Tool (if you're running on an OSX or Linux agent)

    which
    
  • Arguments

    node
    

Variables tab

On the Variables tab define this variable:

Name Value Settable at queue time
NodeVersionSpec 6.x, 7.x Selected

Options tab

On the Options tab:

  1. Enable Multi-configuration.

  2. Specify Multipliers:

    NodeVersionSpec
    
  3. (Optional) Select Parallel if you have multiple build agents and want to run your builds in parallel.

Save & queue

Click Save & queue. Observe how two builds are run. The Node Tool Installer downloads each of the Node.js versions if they are not already on the agent. The Command Line task logs the location of the Node.js version on disk.

Tool installer tasks

For a list of our tool installer tasks, see Tool installer tasks.

Help and support