Does your team use continuous integration (CI)? Are you an early adopter of the new Git capabilities in Visual Studio and Team Foundation Service? If so, you'll be glad to hear that you can define a CI build process that automatically builds and tests all code that your team pushes into your Git team project.

Create or connect to a team project

First connect to a Git team project in which you are a team member and a member of the Build Administrators group.

Do you need help getting started? See Create a new code project, which walks you from zero code to a published Git team project. You can find info on alternative ways to get started here: Create, Connect, and Publish using Visual Studio with Git.

Define your build process

Next define your CI build process.

In the Triggered branches list, specify the branches you want to build and test. You must specify the full Git path to each branch. For example, you want to monitor and build the default "master" branch:

The Hosted Build Controller should meet your needs in most cases. For more information, see Use the hosted build controller.

In most cases all you need to do on the Process tab is fill in the path to the solution you want to build.

How can I quickly get the path to the solution to build?

Open your team project in your web browser.

Browse to the solution and then copy the path to your clipboard so that you can paste it into the Solution to build box of the build definition, shown above.

Give your new CI build a spin!

With your CI build process in place, you are ready to get busy coding and integrating! Write some code, and when you are ready, commit and push it.

Your build should now be queued or running. Go take a look.

Tip: you can also get notifications about your builds from your Windows taskbar or via email. See Receive Build Notifications.

Questions

If you are an experienced user of Team Foundation Build, some of the following questions might be on your mind.

Can I create more than one test run?

In a Git team project, not yet. We're working on it.

Can I customize the build process template?

In a Git team project, we store the build process template in a special place, outside of version control.

This template cannot be customized. We will enable a path to customization in the future.

What happens if I don't specify any triggered branches?

You should always specify at least one triggered branch on the Trigger tab. If you don't, then the CI build will build and test the "master" branch every time a push is made to any branch. This is probably not what you want.

Seems like a CI Build that monitors multiple branches could trigger multiple builds, right?

Yup. For example, if you push commits to BranchA, BranchB, and BranchC, three separate builds will run against each of these branches.

So how does this affect retention policies?

The retention policy applies to every build kicked off by the build process. The default is to keep 10 builds:

So if you typically build a lot of branches at once, you may need to set the number higher.

What is the default branch for?

The branch you specify in the Default branch field is built when you manually queue a build. If you don't specify it, we build the "master" branch.

Note: For this release, due to a known bug, in the Default branch box you must specify the branch in abbreviated form. In other words, you must specify "master" instead of "refs/heads/master".

Why doesn't my work item association show up in the build results?

Although you can associate your commit with work items by specifying the work item id in the comment, the build process does not yet associate builds with these artifacts. We're working on it.

What about scheduled builds?

Stay tuned.