Learn to use Visual Studio, Visual Studio Online, Application Insights and Team
Foundation Server to decrease rework, increase transparency into your application and increase the rate at which
you can ship high quality software throughout the application lifecycle
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 the code that your team pushes into your Git team project.
Get set up: Get the free service, and then you can use it with any Git client tools you want, including Visual Studio. To use the Visual Studio client tools you'll need to install Visual Studio 2012, apply Visual Studio 2012 Update 3 CTP, and finally install Visual Studio Tools for Git.
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.
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:
You must use the Hosted Build Controller. If you need the build output or if you want to have the option to get diagnostic logs, select Copy build output to the server.
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.
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.
If you are an experienced user of Team Foundation Build, some of the following questions might be on your mind.
In a Git team project, not yet. We're working on it.
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.
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.
Yup. For example, if you push commits to BranchA, BranchB, and BranchC, three separate builds will run against each of these branches.
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.
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".
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.
This is awesome!
Well, except that I cannot build my Windows Phone project.
Is there any chance that you will support that in the near future? You probably need to install the WP SDK on the build servers.
belgaard: Windows Phone SDK is installed on our hosted build servers (see tfs.visualstudio.com/.../hosted-build-controller-in-vs). Don't know what issue you hit, but one thing to try: Edit your build definition, and on the Process tab, under Advanced, set MSBuild Platform to x86.
I trying use .runsettings inside my .csproject but receive 1 warning build and my testadapter no run (http://bit.ly/RMfmmD):
"The build process could not find the run settings file '$/HelloGit/HelloGit/HelloGit/jstests.runsettings' for test execution. Make sure that the file exists at the given location and that the build process can access it"
How work $ directory ? .runsettings works with git ?
my directory structure:
Am I doing something wrong?
Abraão Alves: I looked into the issue and I'm sorry to report that I confirmed with the team that won't work. As you have discovered for yourself, unlike a TFVC team project, you cannot yet reference a file in a Git team project from a build process parameter other than the solution file.
Great post, been trialling this out today. Do you know of any issues with storing binaries in the Git repository and then referencing them a part of the build? It seems that the binaries are getting corrupt or something, some examples:
1. Nuget packages are committed to repository (including *.dll), but references to the assemblies result in "bad image" errors during the build
2. Using nuget package restore results in an error saying nuget.exe is not compatible with the version of Windows you're running
3. Committing a test console exe to the git repo and executing via a pre-build event result in a similar error message for the console exe
Some more info
Great Post, thanks.
But my test failed... don't know why.
Exception Message: An error was raised by libgit2. Category = Net (Error).
One or more errors occurred. (type LibGit2SharpException)
Exception Data Dictionary:
libgit2.code = -1
libgit2.category = 11
at Microsoft.TeamFoundation.Build.Activities.Git.GitPull.GitClone.GetRepository(String repositoryUrl, String workingFolder) in d:\a5\dd\alm\tfs_core\Build\Activities\Git\GitPull.cs:line 296
Why is a onpremise build server not supported with GIT? hope that is coming soon!
You mention 'Update 3' - I presume you mean 'Update 2'?
This is really useful - bit hazy on the 'Source Settings' Monitored Branches though.
I am just trying to get a vanilla mvc 4 app to publish & build with git - and I've no idea what to enter into 'Monitored branches'. Infact - not clear how to even get something in there at all, or if I even have a branch?!
Got everything working up to that point - can I just lave it blank from there?
A complete tutorial from creating an new app (say mvc 4) - to setting up git, publishing then building and automatically deploying to a windows server (or azure - both options) - would be good.
You're 75% of the way there but there's still things that are unclear and gaps, like this.
This seems way more complex than it should be (I guess it is a new feature) - and a bit like you had to shoehorn git into existing TFS tools that were designed to work differently. It's all a bit complex / unintuitive (eg, you have to click 'changes' to commit code - and 'commit' to publish/sync code). (whats difference between sync and publish btw??).
I set it up on "develop" remote branch, but when I pushed to it, the build didn't start. How can I troubleshoot this?
I'm using this build process to deploy a Cloud Service - It seems that builds are always deployed to the Staging slot. Is there something I can modify in the build script XAML to make it deploy directly to the production slot? Setting "Path to Deployment Settings" and pointing to settings that specify the Production slot doesn't seem to have any effect.
FYI, I posted this same question in the MSDN forum, and will update that thread with any answer given here (or vice versa).
This is wonderful.
I wan't to do Continuous integration build for my XCode Project.
Let me know if it is possible.
Thanks in advance
We have created a git repository on VSO for our system with multiple solutions in it.
We want to trigger builds on checkin that will get and build only the solution where files got changed without building the entire repo. When we tried creating a build definition, it is getting latest on entire repo and builds all solutions in it.
Is it possible to build only the affected solution or do we have to break into multiple repos with one solution each?