***UPDATE 7/7/2018*** https://docs.microsoft.com/en-us/visualstudio/releasenotes/tfs2018-update2

You can now upgrade to TFS 2018 Update 2 and continue to connect your XAML controllers and run XAML builds. When we removed support for XAML build in TFS 2018 RTW and Update 1, some of you could not upgrade due to having legacy XAML builds, and we want to unblock you. Although TFS 2018 Update 2 supports XAML builds for your legacy builds, XAML build is deprecated and there will be no further investment, so we highly recommend converting to a newer build definition format. See the Evolving TFS/Team Services build automation capabilities blog for more information about XAML build deprecation.

We first introduced basic build automation capabilities in TFS 2005 and, over the years, it has evolved substantially.  In TFS 2010, we introduced a major update which we now call “XAML build” because the build orchestration layer was based on the XAML workflow engine.  As that got adopted, we found that workflow was just not the best representation of build processes – wrong granularity for build, not natural to extend for build, provides capabilities (like durability) that really don’t apply to build, etc.  And, as we began to stretch beyond .NET/Windows into Mac, Linux, etc., it became clear that Windows Workflow was not the right foundational technology.  In TFS 2015, we shipped another major update, introducing a simpler, cross platform pipeline/task model.

Because the two models are so different, we have supported both in parallel to allow customers to continue to work (and even upgrade to new version of TFS) without interruption.  By supporting both, in parallel, people have time to try out the new version, learn it and, where appropriate, adopt/migrate to it.  We feel (and evidence based on usage shift) that the new build system is in good shape and ready for broad adoption.

The plan has been, and continues to be, to remove support for the XAML based build system from a future version of TFS and Team Services.  I want to share where we are on that journey and what lies ahead.  We know deprecating existing capabilities is painful and we never do it lightly.  Unfortunately, we do need to make breaking changes from time to time and we try hard to make it as smooth as possible.  Feedback is always welcome on how we could do it better.

As of today

TFS – TFS 2015 and TFS 2017 (and all their Updates) fully support both the XAML based build system and the newer pipeline/task based build system.  Both will continue to be supported for the many years that those products are supported.

One minor caveat is that we did not update the XAML build controller/agent installer for TFS 2017.  Instead, you can use 2015 (or 2013, or 2010) controllers/agents with TFS 2017.  Said another way, we did not improve the XAML build controller/agent in TFS 2017, so we didn’t ship a new version of it – the previous versions work fine.

VS Team Services – VS Team Services also supports both the XAML based and the pipeline/task based build systems.  However, in January of 2016, we removed the ability for newly created accounts to provision “hosted XAML controllers/agents” in their accounts.  A hosted controller/agent is one where we host all the hardware/software for you and just charge you for usage.  We still support hosted XAML controllers/agents in accounts that were previously using them and we still support private XAML controllers/agents (ones you configure on your own machines and connect to Team Services) for both pre-existing and new accounts.  Basically we prevented new customers from adopting hosted XAML builds but didn’t create any disruption for users already using them.

Deprecating XAML build support in future versions

TFS – In our next major TFS release, we will take the next big step in deprecating XAML Build support.  We will remove all support for XAML builds.  We will not ship updated installers and we will remove support for connecting XAML agents/controllers.  We will also be removing all support for creating/editing XAML build definitions from future versions of Visual Studio.  A customer that really needs to continue to use XAML builds will need to stay on TFS 2017 and use VS 2017 to edit definitions.  We will continue to support the web based experience for viewing previously completed XAML based builds so that you have access to all your historical data.

VS Team Services – On July 1^st, 2017, we will remove support for hosted XAML build controllers/agents.  Customers who need to continue using XAML builds, will need to install a private controller/agent to perform the builds.  Other than having to host your own controllers/agents, XAML builds will continue to fully work on Team Services.

By the end of 2017, we will remove all support for XAML builds in newly created Team Services accounts.  Customers already using XAML build will be unaffected, but new customers will only have the option of using the newer pipeline/task build system.  This will include customers importing from TFS to VS Team Services.

By the end of 2018, we will remove all support for XAML builds in all Team Services accounts.  By that time, all customers will need to have migrated to the newer build system version because their XAML builds can no longer be run.  We will continue to support the web based experience for viewing previously completed XAML based builds so that you have access to all your historical data.

Migrating from XAML build

People who have existing XAML build definitions and want to keep building, will need to migrate to the newer pipeline/task build system.  There is no general purpose automated way to do this.  The systems are different enough that you really just need to create new build definitions that do what you want.  For people who have done heavy customizations (like writing custom workflow tasks), this will be real work.  The good news is that the newer system has a wide array of easy to use tasks – both “in the box” and available in the marketplace.  Some of these tasks are very tuned to a specific action, others are very general (like running a Powershell or Bash script).  For people who have used out of the box templates with minor customizations, the process should be reasonably easy.

Here are some docs on creating build definitions:

• Create your first Hello world build definition
• Create build definitions for your various app types
• Migrate from XAML builds to new builds

Wrap up

Deprecating major features is always hard.  Sometimes, you have to evolve in incompatible ways and that evolution creates disruption and work.  We know that and appreciate it.  We’ve worked very hard to give people years to work through this transition and, with this, we are giving a year or two warning of what the rest of the change looks like.  I really hope this is helpful in enabling you to plan for and manage the transition.

As always, I’m happy to learn about anything we’ve missed or clarify anything.  Feedback is very much appreciated.

Thanks, Brian