Build is an important part of Application Lifecycle Management. Every DevOps pipeline starts with a Build. Visual Studio Online and Team Foundation Server use the XAML based build system for some time now. I’ve used this system in a lot of scenarios, ranging from small applications to complex scenarios with a multitude of customized builds working together.
But now that I’ve seen the new build system and had some time to play with it I’m completely sold. In this post I want to give you a quick intro to Build vNext and show you what it’s all about.
Why a new Build system
The old build system is based on Windows Workflow Foundation. Microsoft created a set of components that you can use to create build templates. You can also create your own components (such as the Code Metrics I blogged about) and add these to your templates. A template could become very long. The following image shows you the outline of the default template that ships with TFS 2013.
These Windows Workflow Foundation builds are run by what’s called a Build Controller and a Build Agent. The Agent does the actual work, the Controller manages one or more Agents and distributes the work to them. The Controller and Agent can only run on Windows. This means that cross platform builds, for example build an Xamarin app on Linux and Mac, are not possible out of the box.
Another limitation is that a Controller is linked to one, and only one, Team Project Collection. This means that sharing a build infrastructure between different collections is impossible. This required careful planning and sometimes resulted in customers having multiple build controllers without any real need for it.
Builds are configured by a build definition that uses a specific build template. These build definitions contain all the settings for your build such as which code to build, which tests to run and what do to with the results. The build definitions are not stored in version control. This means there is no audit trail and no way to go back to a previous version.
That’s enough info on the old build system. Let’s look at how the new Build system solves all those issues.
Introducing Build vNext
While working on this post, Build vNext is now available in public preview on Visual Studio Online. If you go to your VSO account (and if you don’t have one, please create one! It’s free) and select a project you will see a new tab in your menu: Build Preview. This Build System will also be the default build system that’s shipped with Team Foundation Server 2015. Of course the XAML builds will be there for backwards compatibility but whenever possible, the new build system is recommended.
Configuring everything that has to do with your build definitions is now done from Web Access. This means you don’t have to use Visual Studio anymore for configuring builds, immediately making the build system configuration cross platform. Everyone with a browser can create a build.
Builds are no longer based on complex build templates. Instead, a build is simply a list of tasks. Tasks can be anything from running a Visual Studio build, executing a set of tests, calling a PowerShell script or even a custom task you create yourself. In the old build system, creating build tasks required a far amount of knowledge (if you look at tfsbuildextension.codeplex.com you find some extensions created by the community). Fortunately, the new build system is very extensible and much easier then the old one.
Build tasks are essentially a JSON file shipped with other required files (like a PowerShell script). The JSON file describes your tasks with things like a name and description. It defines the parameters that are required to configure the task and finally it contains the actual logic that needs to run when the task is executed. And best of all, there are plenty of examples already! With Microsofts new open-source focus, it shouldn’t surprise you that the build tasks are developed in the open at Github: https://github.com/Microsoft/vso-agent-tasks.
So, a build is a list of tasks. In addition to the tasks and their configuration, you can set numerous other properties on a build definition such as variables that you want to share between tasks, retention policies (meaning how much finished build results need to be kept around) and the triggers that should start a build. If you look at the next figure, you will immediately see a difference with the old build definition: there are checkboxes instead of radio buttons. This means you can now have a single definition with multiple triggers. Previously, you would have to clone your build definition and configure a different trigger each time to achieve this.
Build definitions now also keep track of their history. Any change you make will be saved as a new version. You can view the history of a build definition and compare different versions with each other to quickly figure out what has changed.
There are also changes in the way a build runs. Web Access will give you a live view of the output a build produces. This output is grouped in steps that you can easily navigate and is stored with the build result.
And of course there is something that has to run a build. This is done by the new build agent. A cross-platform, Node.js based runner that can be installed with a simple script on Linux, Mac and Windows. This way. Microsoft has taken the build system completely cross platform, allowing you to have a farm of different build machines that can all be used together.
How does the build system figure out which agent to use? This is done by setting Capabilities on the agent and Demands on the build. Capabilities are automatically discovered by an agent. So installing Visual Studio on a build machine will let the agent know that it can run Visual Studio Builds. This removes the need to manually tag build agents and then add those tags to your build definitions to make sure that a build ends up on the correct machine (if required you can add custom capabilities and demands). There is no concept of a Controller linked to a Team Project Collection anymore. So agents can finally be shared across collections! Does this mean there is no way to restrict agents or have some form of prioritization?
Fortunately, there is. Microsoft introduced the new idea of Pools and Queues. A Pool is defined at the level of your VSO account or TFS Application Tier. Pools can be shared across Team Project Collections. They are used to define permission boundaries. Queues are scoped to the Team Project level and belong to a Pool. This way, a build can be assigned to a queue and then run on Agent.
How can I start
Since Build vNext is in public preview on Visual Studio Online, the easiest way to get started is by using your VSO account. Here are some resources to get you started:
- Chris Patterson (the guy behind all the new build stuff) gave an excellent talk at Build that’s available on Channel9
- The preview documentation for Build vNext can be found on the vsalmdocs website.
- If you have an MSDN subscription you should activate your free Azure credits so you can easily spin up a Linux VM to run a cross platform build agent.
And that’s it for now! I encourage you to start using the new build system and if you have any questions or comments, you know where to find me!