{"id":13046,"date":"2017-05-30T12:10:33","date_gmt":"2017-05-30T17:10:33","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/bharry\/?p=13046"},"modified":"2019-02-27T23:16:35","modified_gmt":"2019-02-27T23:16:35","slug":"evolving-tfsteam-services-build-automation-capabilities","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/bharry\/evolving-tfsteam-services-build-automation-capabilities\/","title":{"rendered":"Evolving TFS\/Team Services build automation capabilities"},"content":{"rendered":"

***UPDATE 7\/7\/2018***\nhttps:\/\/docs.microsoft.com\/en-us\/visualstudio\/releasenotes\/tfs2018-update2<\/a><\/p>\n

You can now upgrade to TFS 2018 Update 2 and continue to\u00a0<\/span>connect your XAML controllers and run XAML builds<\/span><\/a>. 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\u00a0<\/span>Evolving TFS\/Team Services build automation capabilities<\/span><\/a>\u00a0blog for more information about XAML build deprecation.<\/span><\/p>\n

We first introduced basic build automation capabilities in TFS 2005 and, over the years, it has evolved substantially.\u00a0 In TFS 2010, we introduced a major update which we now call “XAML build”\u009d because the build orchestration layer was based on the XAML workflow engine.\u00a0 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.\u00a0 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.\u00a0 In TFS 2015, we shipped another major update, introducing a simpler, cross platform pipeline\/task model.<\/p>\n

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.\u00a0 By supporting both, in parallel, people have time to try out the new version, learn it and, where appropriate, adopt\/migrate to it.\u00a0 We feel (and evidence based on usage shift) that the new build system is in good shape and ready for broad adoption.<\/p>\n

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.\u00a0 I want to share where we are on that journey and what lies ahead.\u00a0 We know deprecating existing capabilities is painful and we never do it lightly.\u00a0 Unfortunately, we do need to make breaking changes from time to time and we try hard to make it as smooth as possible.\u00a0 Feedback is always welcome on how we could do it better.<\/p>\n

As of today<\/u><\/h3>\n

TFS<\/strong> – 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.\u00a0 Both will continue to be supported for the many years that those products are supported.<\/p>\n

One minor caveat is that we did not update the XAML build controller\/agent installer for TFS 2017.\u00a0 Instead, you can use 2015 (or 2013, or 2010) controllers\/agents with TFS 2017.\u00a0 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.<\/p>\n

VS Team Services<\/strong> – VS Team Services also supports both the XAML based and the pipeline\/task based build systems.\u00a0 However, in January of 2016, we removed the ability for newly created accounts to provision “hosted XAML controllers\/agents” in their accounts.\u00a0 A hosted controller\/agent is one where we host all the hardware\/software for you and just charge you for usage.\u00a0 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.\u00a0 Basically we prevented new customers from adopting hosted XAML builds but didn’t create any disruption for users already using them.<\/p>\n

Deprecating XAML build support in future versions<\/u><\/h3>\n

TFS<\/strong> – In our next major TFS release, we will take the next big step in deprecating XAML Build support.\u00a0 We will remove all support for XAML builds.\u00a0 We will not ship updated installers and we will remove support for connecting XAML agents\/controllers.\u00a0 We will also be removing all support for creating\/editing XAML build definitions from future versions of Visual Studio.\u00a0 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.\u00a0 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.<\/p>\n

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

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

By the end of 2018, we will remove all support for XAML builds in all Team Services accounts.\u00a0 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.\u00a0 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.<\/p>\n

Migrating from XAML build<\/u><\/h3>\n

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

Here are some docs on creating build definitions:<\/p>\n