If you have been using Team Foundation Server for any amount of time (say, 2 years or more) then it’s likely you have a decent investment tied up in your XAML-based builds. It’s likely that you have spent a lot of time tweaking the XAML ever-so-carefully to get your automated builds to do your bidding. It’s also possible that you have utilized multiple custom build tasks for scenarios specific to your organization that are not supported out of the box.
Along with this, you and/or your team has gained a good amount of knowledge in learning how to tie the various pieces of a XAML-based build together. So, with all that said, you might be wondering why your company should make the move to the new(‘ish) VSTS-style builds. Here are a few reasons off the top of my head?
- No more XAML!
This is one of my favorite reasons :-) While I like XAML for defining user interfaces (e.g. WPF) I am not a huge fan of utilizing XAML for setting up build orchestrations. The tooling in Visual Studio for XAML-based builds has always been slow and clunky at best. There’s not simple view of what steps the build is going through and there’s no easy way to re-order those steps.With the new builds, setting up your builds is as easy as adding only the steps you need in the order you need them and configuring the step parameters. In practice, this turns out to be much quicker and simpler than XAML builds and doesn’t require as much of a learning curve as what is required for XAML-based builds.
- Build Definition History
While you have a history of build executions for XAML-based builds the new builds also offer history of your build definitions! Not only can you see a list of all your commits (against the build definition) you can also run a “diff” against two commits (within your web browser) to see exactly what changed between commits. This is really helpful when you want to find out what changed in your build definition and who changed it.
While I love this feature, I would like to see some additional capabilities added. For example, the ability to roll back to a specific commit or the ability to selectively accept/decline changes within the diff tool. In any case, I’m happy to have access to the history.
- Secret Variables
The new builds offer the ability to set variables just like you had with XAML builds (although they’re much easier to implement in the new builds). However, you now have the ability to designate the contents of a variable as “secret”. By clicking the padlock icon next to a variable the contents of the variable are hidden and become available only to the build agents at the time a build is executed. Once hidden, you cannot “unhide” the contents by clicking the padlock icon again. If you do, the contents of the variable will be cleared.
- Marketplace
While you can make use of custom build tasks with XAML build there is no centralized or integrated solution for browsing available tasks, installing them or managing them. With the new builds you can make use of the quickly-growing Visual Studio Team Services Marketplace. Here, you can search and browse the many extensions currently available in the Marketplace. You want to use continuous delivery with the Google Play store? There’s an extension for that. Want to deploy VMs to VMware vCenter Server? There’s an extension for that as well. Want to… well, you get the idea :-)Having a Marketplace easily accessible enables you to quickly and simply expand the capabilities of your builds (and releases) with next to no effort!
As an aside, if you’re interested in learning more about how to create your own custom build tasks, Microsoft has open sourced all of the build tasks provided with TFS/VSTS on GitHub here. These are great examples of how you can extend the capabilities of the new build engine.
- Non-TFS/VSTS Source Control Support
If you’ve ever dreamed of using VSTS/TFS to orchestrate your builds but you wanted to maintain your source code in an external system such as GitHub or SVN then you are now in luck! With the new builds you now have a choice for source code repositories:
As you can see in the above image, you can chose among Git (in VSTS/TFS), GitHub, External Git and Subversion. If you’re making use of a TFVC-based project, you will also have Team Foundation Version Control as an option.
This has been useful for my organization and some of the open source projects we manage. For example, we keep the source code in GitHub but use VSTS to provide automated builds and deployments (via Octopus Deploy).
- Draft Builds
When you are making changes to an existing build definition, it’d be great if you could save your changes and test out your changes without impacting the actual (“live”) build definition. The new builds now provide a “Save as a draft” option that lets you do exactly this!
Once you save a definition as a draft you can queue the build and test it out like any other build… all without impacting anyone else. Once you are happy with your changes, you simply publish the draft to make it live.
- Build Templates
When creating new builds, if you find that you are always adding the same initial set of build tasks, then build templates are for you. Build templates allow you to start a new build definition with a predefined set of tasks already included and configured. Once you’ve saved a build as a build template, you can access it on the new build dialog.
Note that the “Custom” option is available only if one or more custom build templates exist.
While this is a great feature, it’s use is limited to the team project the template was defined in. In other words, you cannot make use of custom build templates from outside the team project you’re working in. I am hopeful that Microsoft will extend this feature to be available across an entire VSTS/TFS account. At that point, this will become one of those features you don’t know how you ever did without.
- Self-Updating Build Agents
As with XAML builds, the new builds also make use of build agents. Along the same lines, the agents can be either “hosted” (i.e. you use the hosted build agents provided as part of the overall VSTS offering) or on-premises. With XAML builds, when a new version of the build agent is made available, you have to download the agent (typically as part of an overall TFS update) and manually install it on each and every build server you have.In the case of the new build agents, once you have them installed, they will self update. When Microsoft provides a new version of the build agent, the agent will (eventually) detect this, download the update and update itself. If you’re making use of VSTS, this happens fairly quickly after the update is made available. If you’re making use of TFS (on-premises) then the update is typically included as an overall TFS update (e.g. quarterly update).
We currently run a total of 17 build agents (16 on Windows and 1 on a Mac mini). Each and every one of these agents have updated multiple times (they’re tied to VSTS) without any manual intervention. It’s simply awesome!
- XAML Builds are Deprecated!
Perhaps the most convincing reason for updating to the newer builds is that the XAML builds have been deprecated (and another link). While XAML builds will continue to work for some time, it’s unlikely they will ever be improved upon. Being deprecated, it’s reasonable to expect that all new build features will be implemented in the newer style of builds while the XAML builds are left to function as they do today.
While you can find many other reasons for moving away from XAML builds the ones that I’ve listed above are pretty much my favorite :-) If you have other reasons for moving away from XAML builds (to the newer style of build) let us know below.
The problem is that vNext build is not at pair with XAML build. One example: custom data type for build parameters.
Agreed! Custom data types would be great to have and I hope we get them at some point.
As Daniel pointed out parity is not yet there…also…
1) Although based on Workflow and XAML, there was never a *Requirement* to use the designer. In fact, the use of XAML markup could be minimized by using custom coded activities…..the “problem” was that people only looked at the D&D portion without understanding the complete technology stack, not that the technology stack was inherently the problem.
2) Complex flows were possible in the old build system that are no longer possible. Some can be replication [an additional cost] in a variety of third party tools, but there are still many holes. In at least one case (where the client was politically required to move to vNext) we actually set up a custom task that could run Workflows!
3) Secrets are nice, but they are not “secure” in many cases. This is because the value is “revealed” before it is passed into a task. So add a task, pass a secret variable, display value….
4) Lack of a Controller. This prevents a single build from being distributed across multiple agents
I do like vNext build…but I really wish there was much better parity before there was even the consideration of deprecation of a system that has been used (And works well for many) for over a decade.
David,
I agree that there is still not parity. I am definitely being somewhat biased in that I am presenting only the “good” things about the new “vNext” builds :-)
To add to a couple of your points above, I rarely ever used the XAML designer when working with XAML builds. It was simply too slow and generated complex diagrams that were no fun to navigate. However, working directly within the XAML code itself (which wasn’t always so easy to get at from within Visual Studio since it preferred to open the XAML in the designer) wasn’t too bad so long as you knew what to look for. Knowing what to look for took a good deal of experience and wasn’t obvious for anyone new to XAML builds.
I agree that “secrets” are not secure. If you want a little extra security on top of the secrets, you need to ensure that only those people that truly need the ability to install new build activities can do so. And those people need to ensure you don’t install something that enables you to run ad-hoc PowerShell scripts :-) At best, this feature is keeping the honest people honest.
In the end, however, the XAML builds are still deprecated so the writing is on the wall. Hopefully, Microsoft will bring some more parity to the competing (build) platforms as time goes by and before the existing XAML build capabilities get too stale.
I’m reading your blog with an open mind but frustrated by MSFT at the same time. I agree with #1, #2 used to exist prior to XAML (You’d check your Build response files into source control ) #3 is useful. #5 is both good and bad to me. The value to me of TFS when it came out was that everything was integrated… no more cobbling of systems together. We seem to be going back in that direction as an industry. #6 I did this by branching and merging build process templates and cloning build definitions so that the real one used one and the prototype one used another. #7 Isn’t this what a build process template was? #8 ever green for my build system… how scary to me and yet how loved by many. #9 sounds mature and stable to me. I like! But I get your point.
I guess one of the big points you missed is the agents are multiplatform. That’s probably why they are really doing it. So much of the MSFT developer ecosystem that I’ve loved is being flushed down the toilet to chase the shiny new vision. I have my biases and I’m struggling to decide if they are justified or if they should be abandoned. This TFS tool stack has worked so well for me for the past 12 years and I loved it just the way it was.