I have finally had time to try out the new TFS build system that is coming out in TFS 2015 and is currently in preview in VSO. I have worked a lot with the xaml based system so I was very interested to see how the new vNext system compares and how I can move my very long and complicated xaml build templates over to vNext. I have been slightly blown away by just how radically different it is to the old xaml based system.
If you haven’t looked at Build vNext yet then the best thing to do is to watch this great presentation
To summarise we can say
- Build vNext is a completely new system that shares absolutely nothing with the old xaml based system. xaml based builds will continue to be supported but I don’t think we’ll see any new features being written for it
- There is now an open source cross platform build agent (written in node.js) that runs on Mac and Linux
- This cross platform agent gives us the ability to build java, xcode and many others straight out of the box
- The concept of build controllers and agents has been replaced with pools, queues and agents. Pools can be shared across collections which was always a problem with controllers. I am interested to see how this develops and how we will end up using pools in the real world
- vNext build definitions are version controlled so all changes to definitions are fully audited, i don’t think this will happen for the old xaml builds
- vNext build definitions can be edited from within the web portal
- Much improved build triggering for the new system. Builds can support multiple triggers.
- Redesigned concept for gated builds that will support GIT as well as TFVC (previously we couldn’t gate a GIT build)
If you haven’t already, the best thing to do is get yourself the a Visual Studio Online account where build vNext has just become publicly available. You can see on the right build defintions are now split into two types. The old xaml based builds and going forward the new builds which are just known now as build definitions.
To create a new build pick the Visual Studio Template and click OK. The build is created for us and we are left with a series of tabs and options to fill out.
The settings should be familiar for the most part. You have options to configure the source control location as well as define what solutions to build and what tests to run. The rest I want to explore in some later posts. There is hosted build pool you can use to run your builds directly, have a go and have a look at the output – again it is much changed from before. You get a normal looking log instead of the strange xml/xaml output that is produced by xaml builds.
I have invested a lot in the old TFS build system and have extended the old xaml templates greatly. I am used to a development workflow that relies heavily on TFS build. The new build system looks very promising and I can see how it should make managing builds much easier. A few key questions remain for me which I want to investigate over the next few weeks.
- How will we end up using pools and queues in scale production environments.
- I use custom types and custom UI in my xaml based definitions, will there be any support for these in the new build system.
- xaml made it easy to use conditional operators like if, else and foreach to control the build workflow and we also got parallel processing out of the box. How will this be achieved in the new system? Will all that logic go down into the powershell tasks?
- We’ve seen the web portal for managing these new build definitions, what will the UI for managing these build definitions look like in Visual Studio.
- There are many cool Visual Studio Extensions for build management, like the Community Build Manager. How are these going to evolve to support build vNext?