The next version of Team Foundation Server has been announced quiet some time ago. In the RC version of Team Foundation Server as well as Visual Studio Online, there is a preview of the new build system available. It’s now time to have a look at it.
First things first: The old XAML based builds (the workflow foundation based ones) are still good to go, if you already have made a lot of customizations and investments for them. The new build system is “green field development” and therefore this is a big breaking change. There is no easy way to simply migrate. If you already used the PowerShell extensions to customize the standard build, there should be a straight forward migration for your scripts since PowerShell is the first-class citizen to customize build logic.
As I already told you, the new build system is a new development so there are plenty of changes, but let’s get to the main points.
Agent Pools and Queues
There is no physical build controller anymore and there is also no more need to have build infrastructure per Team Project Collection anymore. Thiseases the the infrastructure definition a lot. Now you have so called “agent pools” per TFS deployment respectively VSO instance.
On the collection level, you have a build queue which is based on an agent pool.
Additionally, the authorization to administer agent pools can be defined through security groups:
Agent
If you install the agents, you will notice that there is no more TFS Installation and TFS Administrator Console required to do so. We now have a standalone agent which is available for Windows as well as for Linux and OS X as a Node.js implementation. The windows version can directly be downloaded from VSO or TFS Configuration, the Node.js based on can be found on GitHub (https://github.com/Microsoft/vso-agent).
The agents are xcopy deployed and auto updated from the server. The agent installation is pretty straight forward, since there is a simple PowerShell script guiding you through the process.
The agent can be run as a windows service (recommended) or run as an interactive process. If you are using VSO, there is also a hosted build queue with agents already setup for you (since the public preview).
Build Definition
The new build definition looks very different than the old one. It is now very light weight and mainly consists of ordered build tasks. New tasks can be added and moved by dragging and dropping the elements on the screen. Each task has settings which can be defined in the editor on the right.
Currently, the extensibility point is providing PowerShell scripts in form of a PowerShell task. Custom build tasks are currently not supported in the preview but will be in the future.
There is a tutorial for extending the build by PowerShell script on the following location (performing assembly versioning): https://msdn.microsoft.com/Library/vs/alm/Build/scripts/index
If you are interested in seeing some insights of the new build tasks, all the current tasks are available as open source project in GitHub (https://github.com/Microsoft/vso-agent-tasks). The build tasks are implemented in PowerShell (for Windows) or JavaScript (for cross-platform).
Git Repository Integration
You are no longer tied to source code versioning on TFS or VSO. The new build system offers integration for GitHub and other external Git repositories.
Build Variables
Build variables are easy to manage. You can specify new variables and also promote them to be set while queuing a new build. There is also a new functionality to store secure variables like password for deployments etc. The secure variables are securely stored on the server and masked during build time.
Triggers
The new build definition is no more coupled to a single trigger type. I now can specify CI builds as well scheduled build for the same build definition. Additionally, we can have multiple branches and multiple scheduled times on the same definition.
Build Agent Process Authorization
If you every worried, that the build agent is running in a process which has pretty much access rights to your TFS? The new agent only has permissions to listen to its configured agent pool an the TFS / VSO system. When a new build is triggered, a new access token is generated (limited time-frame) which provides access to either project collection scope or project scope.
Build Definition History
The new build definition is versioned and the history is listed in the build definition view. The cool thing about the history is, that you also can “diff” the definition with its prior version.
Build Execution
The first thing to notice when you queue a new build is that the branch is no more coupled to the definition. You can queue a new build to any branch.
The second thing you notice is that the build console provides you real-time console feedback during the build.
Conclusion
The new build system provides a lot of new (and also needed and requested) features which eases the way of building your software in a modern ALM environment. The ease of extensibility as well as the simplified agent models a good reasons to update your build automation to the new build system as soon as possible. In the meantime, we strongly advice to only invest in PowerShell script based extension of XAML-based build workflows since the PowerShell scripts can easily be adopted to new build variables used by the Build vNext system.