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?