In this post, I want to show you some of the new features and changes in the 2013 version of Team Foundation Build. In my opinion, there are some nice little things that will make your life much easier! Let’s go!
TFVC and Git
With TFS 2013, you now have the possibility to create a Team Project using Git as version control system. This will create a central GIT repository where you can push and get files from/to. Visual Studio 2013 will offer you a great GIT experience. You can find some information about the GIT story on the blog post from Harry Brian.
And of course, you can now also build the code you store in a Git team project and you can generally do everything you can do like with code stored in a TFVC team project. If you create a new “Build Definition” (Team Explorer – Build – New Build Definition), you have to option to get your sources from a TFS Git repository.
A nice thing is that you can also get sources from whatever Git repository. Meaning that you can also use other Git services on your build system. The only limitation you have there is the fact that you will not have the CI and Rolling build functionality.
One notable exception for Git builds: you cannot define a gated check-in build in a Git team project.
Copy build output to the server
Just like in Team Foundation Service, you now also have the possibility to save the build output of your builds to the server. Previously, with TFS 2012, you also had the option to store your outputs on the server, but this “server” part was actually the version control repository. That option came with some drawbacks. For example, users had to be sure that they cloaked the drops folder or the syncs would get increasingly long. In addition, each build drop generated multiple new check-ins, which affected the history and possibly triggering unwanted version control notifications.
In your build definition, go to the “Build Defaults” and select “Copy build output to the server”
If you now look to the build overview of a completed build, and click on “Open Drop Folder”, you will be redirected to the web access. There you will have a link called “Download drop as zip”.
Improved build diagnostics
You now have the ability to view the build diagnostic logs in the TFS Web Access. You can also download your logs as a zip. Being able to view the detailed diagnostics log is a handy feature that you can use for easier build debugging regardless of where you are dropping the build outputs. Beyond just viewing the log, you easily jump from one error to the next. In my opinion, that’s quite a nice addition, mainly because it gives you some more information than the build report in Visual Studio gives you. It will for example show you the sequences in the build workflow, it will also show you what the download size of your sources is, where the sources are stored,…
It even goes a little step further. If you click “show properties”, it will show you all parameters from your build. In TFS 2012 (and older), you were required to set the logging verbosity higher than “normal”, but using the new Build Process template, you don’t have this option anymore.
“Default” Build process templates
A great new feature in TFS 2013 is the usage of “Default” build process templates. Note that the term “Default” is not related to the name anymore. What I mean by that? Well, in TFS 2012 and prior, your Build Process Templates were stored in source control. On one hand, that’s good, because you can easily change or modify the templates and save them somewhere in Source Control. But on the other hand, that’s quite a XAML overload if you have a dozen Team Projects with builds using a default, non-modified, Default Build Process Template. In TFS 2013, you now have 2 real “Default” Build process templates that are not stored in source control. (well, not directly). There’s one template for TFVC and one for Git. You cannot modify this “global” templates directly. In a next chapter, I’ll talk about why you will probably not change the default templates.
You can of course modify this template. You can click the “Download” link, modify it, and add it to source control (like the “old” way). You can then select this modified source control based template by clicking on the “New” button.
Post- and pre-build scripts
When I’m at a customer and they need some “custom” build-related things, I generally discourage them to modify the build process templates. (I’m sorry!) The reason for that is most of the times, they want to do some XCopy things, start/stop an IIS, modify a file, .. You can indeed modify the Build process template by adding some activities, but in general, it’s a difficult process for people without any Workflow experience. It’s also a fast and heavily changing process meaning that your build process template will require lots of changes. What I did (up until now) was adding one additional activity to the template, where I had the ability to execute a PowerShell script including a step to pass all TFS related parameters to the script.
Well, good news, we have this by default now! In the build definition wizard, you can now select either a batch or a PowerShell script. You even have the possibility to choose when you want to execute this script. You have 4 options:
- Before MSBuild compiles your code
- After MSBuild compiles your code
- Before the test runner
- After the test runner
In this example, I added a PowerShell script called “Deploy.ps1” (which is stored in Source Control). It contains a simple write-host. If you look to the build log, you will see:
That’s great, but what if we need some information about the build itself? Like the drops path, the path where the sources are located, … Good news, those variables are available for you! They are stored as environment variables. Let’s assume that I want the name of the Build definition. Well, in my PowerShell script, I add the following:
Write-Host “The build definition name is “$Env: TF_BUILD_BUILDDEFINITIONNAME
And you will get the following result:
You can get a list of all the variables using this link.
Simplified Build process template
If you however decide that you still need to put your own secrets in your build processes, you will now be happy to see that the overall structure of the template is way easier to understand. Let me show you how it looks like now:
You can now finally get to the right piece without struggling through the never-ending-collapsing XAML. Your process will also have a much cleaner look:
So, this were some of the new TFS Build features and improvements. The things that I like most are the pre/post build scripts and the ability to run TFS build from whatever Git repository you want. What do you think?
This is awesome ..
How about integration of Continuous Deployment with Windows Azure Cloud Services? are there any upcoming features in build system to achieve that as well ?
This looks very nice. One thing I don’t like about the default build template though is that it associates a build to the work item before actually trying to do the build, so even if the build fails the work items get updated. This was a sore point for our QA team as they would assume that if they see an “Integrated In Build” version that it meant the bugfix/feature was actually in a build and ready to be tested; so I modified our build template to make this one of the very last steps to complete, and only if the build passes successfully.
The Git integration and Pre/Post build scripts are a very nice addition, as I would much prefer to work in PowerShell than Workflow (as long as it is still easy to call the TFS activities from PowerShell). I’m wondering how easy is it though to pass custom parameters that we add to our build templates to the Pre/Post build scripts?
Also, your link to the list of TF Build environmental variables accessible from PowerShell is broken.
Thanks Daniel, I quickly fixed the broken link!
Hi Alexander, thank’s very good article about process, you have also new activities in the build process if you are interested, http://almbyaghilasyakoub.wordpress.com/2013/08/13/team-build-2013-new-activities/
Thanks for sharing Aghilas! Any chance on an English version?
How do I configure environment variables?
You cannot really “configure” those environment variables. TFS Build will pass the correct value to the variable. You can of course use the script arguments to pass additional arguments to your script.
for some reason I am getting below error when run the script.
Script is:
Write-Host “Hello Poweshell script.“
$testdata =“The build definition name is “$Env: TF_BUILD_BUILDDEFINITIONNAME
$testdata >> “C:temp1log.txt”
Error:
Unexpected token ‘Env:’ in expression or statement.
At C:Builds1Training PortalSystem TestsrcBuildProcessTemplatesscriptssy
stemtest-postbuild.ps1:3 char:48
+ $testdata =”The build definition name is “$Env: <<<< TF_BUILD_BUILDDEFINITIO
NNAME
+ CategoryInfo : ParserError: (Env::String) [], ParentContainsErr
orRecordException
+ FullyQualifiedErrorId : UnexpectedToken
Remove the space after $Env:
One other thing to note is that you can pass your own custom environmental variables into your scripts as well, by modifying the “Run optional script…” activity in the default template. This is handy if you have other customized variables in your build template that you want to pass into the script, not as a parameter. It’s also worth mentioning that while you can read these environmental variables in your script, if you write to them the changes do not propagate back to the build template. For example, if you change the TF_BUILD_DROPLOCATION environmental variable, it will still copy the binaries to the original drop location.
Thanks for sharing this information Daniel!
I will have some long hard nights with this
Nice article but I have a question, if we have couple of builds running against a branch, we would like to have some global parameters that will help in organizing the builds. That’s very simple in TeamCity where we can define global parameters, and we can use that everywhere, and anytime can change in a single place but I cannot see anything like that in TFS 2012.
Is there any way to do so? so far nothing found, and I don’t want to customize the template to read those global parameters from some file on source control, unless there is no other way to do so.
Hi Naeem, what you can do is using PowerShell to get those values? You can for example store them in source control, and get them using PowerShell (you get the source control directories using the “$Env: TF_BUILD…” variable in PowerShell)..
Good luck!
Hi Alexander, thanks for your post, yea that’s one way of doing this, I am still trying to see what should be the best way to do so.
[…] As you can see, the web access is pretty lightweight and you can do almost everything to review your commits, explore your projects, viewing history, etcetera. This post is member of a three-parts blog, the first can be found here, and the third part, which I cannot better write about then Alexander Vanwynsberghe. His post can be found here. […]
Any ideas on where I can get this v12 of the default template? I’m using VSOnline and when I create a new project it creates a v11.1 default template that is lacking the script injection points
Hi Christoper, you need to use the TfvcTemplate.12.xaml on VSOnline (see screenshot). This template contains everything you need. Good luck!
Thank you for the post. One of the primary reasons we use custom template is to set specific version to our DLL. Basically, we modify AssemblyInfo.cs before building the project. Is there any standard ways now in TFS 2013 to do this task?
Simplified Build process template for who? We have been using the parallel process template Patrick Carnahan developed for TFS 2010. I also modified it to work with TFS 2012. http://blogs.msdn.com/b/jimlamb/archive/2010/09/14/parallelized-builds-with-tfs2010.aspx
It appears that this “simplified” process template has rolled up the logic from several activities from TFS 2010/2012 into other base activities for 2013 Build.
See my post here: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/ef8b912a-0beb-48ae-93cf-d75411e9d8a1/tfs-2013-parallel-build-process-template?forum=tfsbuild
I have a post-build script that appears to have run. It outputs a lot of information, where can I see it?
You should be able to view it in the build’s log. It won’t show up in the Summary view though. You will need to look at the Log or Diagnostic view of the build log, which is available through the Team Web Access’s Builds tab.
How can I run a .BAT script? I would like to copy few files and directories from the SourceDirectory to the DropLocation. I’m using asConfigured for Output location. I was trying to supply the batch file with CLI arguments and to use it with %1, %2 etc. But since I get very limited information in the LOG regarding the failures I could not resolve this.
Instead of using a .bat file, use a PowerShell .ps1 file to do the copy, and specify that .ps1 file in the Post-Build script path as shown in the post. Both the Sources and Drop Location are available in the PowerShell script as environmental variables, as Alexander showed above.
@Alexander it looks like MS changed the link to the environmental variables on you again. The new link is at http://msdn.microsoft.com/en-us/library/hh850448.aspx
Hey, Thanks but I’m still with .BAT 🙁
and I still need to convert the $(TF_BUILD_DROPLOCATION) and $(TF_BUILD_BUILDDIRECTORY) to %1 etc, while adding some custom parameters as well.
Do you have an Idea for me?
You could just have your PowerShell file call the .bat file using:
start-process “cmd.exe” “/c C:Pathfile.bat”
If you don’t want to use PowerShell at all for some reason (I don’t know why that would be), you can always modify your build template. Basically you open the DefaultTemplate.xaml in Visual Studio and it should open the Windows Workflow. Then you can drag an Invoke Process item from the Toolbox. In that control you set the process to execute as “cmd.exe” and for the arguments specify something like:
“/c C:Pathfile.bat ” + Build.SourcesDirectory + ” ” + Build.DropLocation
and then check that .xaml file back into source control.
Can we have generalised build definition(BD) catering to all project if not that then environment?
In my org I have project A, B And C. Each has DEV /Test/Production environment.So I have got( 3 Projects* 3 Environments=)9 Build definition(BD) to be created which I don’t want to .Can we have generalized BD which will serve all these 9 testcases?
BD is defined on XAML code which takes input like sln or project file which will be different for different project like A.sln,B.sln and C.sln so I understand it not feasible to have generalized BD at project level. (Untill and unless I learn more about XAML code)
So My aim is to serve 3 Test cases i.e 3 Environment for each Project .I want to have 3 BD catering to dev/prod/test environment. like BD called Build_A will take care of deployment to Prod/DEV/TEST environment automatically depending on who triggered a build.I created a XML file which stored all environment details .
My Solution to a problem:: Find who triggered a build; lets say (DEV team member); then load Dev environment from XML and execute code(which is same for DEV TEST and PROD). if QA team member triggered a build then run on TEST environment loading details from XML.
1.Can any one suggest any other way to sort out this thing?
2.How to identify who triggered a build (Using their mail id linked to TFS) in powershell?I mean how to get mail id of a person who triggers a build in powershell?
below is XML code::
ServerTST
DomainTST\CredTST
TST@123
C:\inetpub\wwwroot\TST
ServerTST2
DomainTST\Cred2
TST2@123
C:\inetpub\wwwroot\WebAPI\TST2
ServerDEV
DEVDomain\CFRED_DEV
DEV@123
C:\inetpub\wwwroot\WebAPI\DEV
</Environment
AJGUSHC2SP02VT.AJGCOTST.INT
ajgcotst\s-dspfarmadmin
SMART_UKCC_TST_Password.txt
C:\inetpub\wwwroot\WebAPI\UKCCTST
AJGUSHC2SP03VT.AJGCOTST.INT
ajgcotst\s-dspfarmadmin
SMART_UKCC_TST_Password.txt
C:\inetpub\wwwroot\WebAPI\UKCCTST
ajgushc2sp11vd.ajgcodev.int
ajgcodev\s-dspfarmadmin
SMART_UKCC_DEV_Password.txt
C:\inetpub\wwwroot\WebAPI\UKCCDEV
</Environment
So you know in TFS 2013 is its possible to get Code Coverage Info in PS Script?