Why Should I Leave XAML Builds?

Datetime:2016-08-23 03:58:30         Topic:         Share        Original >>
Here to See The Original Article!!!

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?

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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 ).

  6. 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.

  7. 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.

  8. 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!

  9. 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.

Put your ads here, just $200 per month.