Concurrent build and release pipelines in Visual Studio Team Services

A Team Services concurrent pipeline gives you the ability to run a single build or a single release at a time in your account. There are two types of concurrent pipelines in Visual Studio Team Services.

Private pipelines

If you want to run builds and releases on your own machines (private agents), then you need private pipelines. We provide one free private pipeline in each Team Services account. In addition, every active Visual Studio Enterprise subscriber in your account contributes a free private pipeline. You can buy additional private pipelines from the Visual Studio Marketplace. After you've done this, you can deploy your own private agents and use them with these private pipelines. You can register any number of private agents with your account for no additional charge.

Hosted pipelines

If you want to run builds and releases on machines managed by Microsoft (hosted agents), then you need hosted pipelines. We provide 240 minutes of free total compute time per month from a hosted agent to run a build or a release. Each build or release job within this free allocation cannot run for more than 30 minutes. To run more builds or releases concurrently, you can buy additional hosted pipelines from the Visual Studio Marketplace. With the first purchase of a hosted pipeline, the 240 minute limit on total build and release time as well as the 30 minute limit on a single job are waived. Each additional purchase of a hosted pipeline adds another hosted agent for running your builds and releases.

How a concurrent pipeline is consumed

For example, consider a Team Services account that has only one concurrent pipeline. This allows users in that account to run only one build or release at a time. When additional builds and releases are triggered, they are queued and will wait for the previous one to complete.

A release requires a concurrent pipeline only when it is being actively deployed to an environment. Waiting for an approval or a manual intervention does not consume a concurrent pipeline.

Release 11 waits for approvals. Fabrikam CI Build 101 starts because a release waiting for approvals does not consume a concurrent pipeline.

Release 11 is approved. It resumes only after Fabrikam CI Build 101 is completed.

Concurrent processing within a single build or release

Concurrent processing within a single build or release does not require additional concurrent pipelines. So long as you have enough agents, you can

In a build process, run multiple build configurations at the same time.

In a release process, deploy to multiple environments at the same time.

For example, suppose your Team Services account has three concurrent pipelines. You can have more than three agents running at the same time to perform parallel operations within builds and releases. For instance, notice below at 9 a.m. that five agents are actively running jobs from three concurrent pipelines.

Determine how many concurrent pipelines you need

You can begin by seeing if your teams can get by with the concurrent pipelines you've got by default. As the number of queued builds and releases exceeds the number of concurrent pipelines you have, your build and release queues will grow longer. When you find the queue delays are too long, you can purchase additional concurrent pipelines as needed from Visual Studio Marketplace.

Simple estimate

A simple rule of thumb: Estimate that you'll need one concurrent pipeline for every 10 users in your account.

Detailed estimate

In the following scenarios you might need multiple concurrent pipelines:

If you have multiple teams, and if each of them require a CI build, then you'll likely need a concurrent pipeline for each team.

If your CI build trigger applies to multiple branches, then you'll likely need a concurrent pipeline for each branch.

If you develop multiple applications using one account or server, then you'll likely need additional concurrent pipelines: one to deploy each application at the same time.

View available pipelines

View the maximum number of concurrent pipelines that are available in your account.

Select Pipelines queue... to display all the builds and releases that are actively consuming an available pipeline or that are queued waiting for a pipeline to be available.

Known issues and planned improvements

Blocked pipelines under certain conditions

Builds and releases from all projects are queued and allocated to pipelines in the order they are created. Because of this, it may so happen that a build or a release may wait for a pipeline because of earlier builds waiting for agents. For example:

You purchase three pipelines in your account. You have configured two agent pools: A and B, and each contain two agents.

You queue three builds targeted for pool A. Two of these builds will start running immediately since you have two agents in pool A. The third has an available pipeline, however it does not have an agent available.

You then queue a fourth build targeted for pool B. Since builds are assigned pipelines in the order in which they are created, this build waits for the three builds above to complete, even though there are agents available in pool B.

We're working to improve this model. For now, the workaround is to add more agents to your pool. For example, you could add an agent to pool A mentioned above.

Sharing of concurrent pipelines among private and hosted agents

If you have sufficient private agents, you can use the concurrent pipelines - both private and hosted - to run builds and releases on private agents. For example:

You purchase a single private pipeline and a single hosted pipeline.

You deploy two private agents in a pool.

One build and one release are running in your private agent pool.

A build is queued in the hosted pool. That build will not start until one of the builds in your private pool is completed.

The same is not true with hosted pipelines and hosted agents. For example:

You purchase a single private pipeline and a single hosted pipeline.

You see a single hosted agent in Hosted pool and a single hosted agent in Hosted VS2017 pool.

You can only run one build or release at a time across all of the hosted pools.

We're working on using only private pipelines for jobs that run on private agents.

Sharing of pipelines across projects in a collection

Pipelines are purchased at the account level, and they are shared amongst all projects in an account. We don't yet offer a way to partition or dedicate certain pipelines to a specific project or agent pool. For example:

You purchase two pipelines in your account.

You queue two builds in the first project, and both the pipelines are consumed.

You queue a build in the second project. That build will not start until one of the builds in your first project is completed.

In the future, we plan to support finer control on allocation of pipelines.

Q&A

Who can use the Build and Release Management features?

Team Services users with basic access can author as many builds and releases as they want.

To approve releases, basic access is not necessary. Any user with stakeholder access can approve or reject releases.

Are there any limits on the number of builds and release definitions that I can create?

No. You can create hundreds or even thousands of definitions for no charge. You can register any number of private agents for no charge.

I use XAML build controllers with my account. How am I charged for those?

You can register one XAML build controller for each private pipeline in your account. Your account gets at least one free private pipeline, so you can register one XAML build controller for no additional charge. For each additional XAML build controller, you'll need an additional private pipeline.

As a Visual Studio Enterprise subscriber, do I get additional pipelines for TFS and Team Services?