This post is part of a series of articles on the new TFS Build vNext System.
Lets take a more detailed look and the new build definitions and see what there is there. I’ve just downloaded the latest version of Visual Studio 2015 RC and I was a little surprised to see almost all UI for managing and editing builds (both xaml and vNext) has moved to the web portal. This is a big minus point for me, as a build ‘power user’ continuously switching from VS to the browser to monitor and manage my builds is very inefficient. I raised this uservoice request about it. Just imagine the number of clicks needed in the browser to switch team projects.
Tasked Based System
In the first tab we get our first look at the new task based system, the replacement for the xaml workflow and custom activities. Each step in the build is a task and we can simply add tasks from a task repository and reorder them to create our build workflow.
Click ‘Add build step’ to see the list of (open source) out of the box tasks. Directly we can see a whole load of out of the box tasks, from running unit tests, running a powershell script, doing a deployment, drop folder settings and cross platform build tasks. We simply pick and mix tasks from our ever increasing store of tasks to create builds that do whatever we want them to do.
Consider the scenario where we want to build and unit test our source, deploy the code and then run some integration tests against the new deployed environment. Previously with xaml builds adding that second unit test run was very involved, i wrote an article on how to do it. With vNext builds it’s a simple two click process to add a second test run to the end of the build, a great improvement.
It definitely seems Microsoft’s intention to get us to do most of our custom build tasks using powershell scripts. Want to run a sql command, wrap it up in a powershell script and add a powershell script task to the build.
Want the build to send an email, wrap it up in a powershell script and add a powershell script task to the build. Take a look at this article to see an example.
There is a lot more to discover about the task based extensibility system but more on tasks in a later post.
For TFVC builds I’ve noticed that I can’t create a workspace that spans multiple team projects. This was possible with xaml builds and had its uses. It seems a shame to remove this ability for vNext builds. I raised this uservoice to ask about it.
For GIT builds we now have custom support for GitHub
Adding user variables to the build definition is now a simple task. Previously with xaml builds there was a slightly complicated procedure required to add variable and it felt like black magic sometimes. There is also the ability to encrypt sensitive variable values which is an improvement on the xaml system which often saw us storing passwords in plain text in the build definitions. More on variables in this post.
Triggers are much improved in vNext. We can now define multiple triggers on one build. Previously, if you wanted rolling builds that also ran overnight, you would have had two builds definitions, both exactly the same, except one had a rolling trigger applied and one had a scheduled trigger applied.
We also have the ability to specify a filter for rolling builds independent of the build repository settings which is another improvement over xaml builds.
The general section has some nice new features. We can define something called ‘Build job authorization scope’ which limits the access of a build to the specific team project instead of giving it access to the full project collection. In old style xaml builds, if a user has access to only a specific team project, he could easily write a unit test that made changes against any project in the collection as the build service account would general have full access to the entire collection.
Retention policies for vNext builds have been completely reworked. We can now specify a ‘days to keep’ settings on builds and TFS will automatically delete all builds older than this setting unless they have been explicitly marked to retain forever. This is a nice idea but it shouldn’t be at the expense of all style retention policies where we could specify the number of builds to retain. I would like to see both systems supported. Being able to always keep the last successful and last failed build is a very useful feature. I raised this uservoice to ask about it.
Build definitions aren’t version controlled in the sense that other files in source control are, but changes to build definitions are fully audited via the history tab. The definitions are represented in json and versions can be diffed and changes rolled back. Note: limiting the build UI to the web portal means when diffing builds we are limited to the web based file differ ;(