Contributing to the VSTS Developer Tools Build Tasks extension

About a year ago I helped one of my clients transition from Team Foundation Server (TFS) 2010 to Visual Studio Team Services (VSTS). In some of their XAML builds they heavily relied on the ability to check in generated content during their builds, something that broke due to the fact that tf.exe could no longer authenticate to VSTS during from a private agent. This prompted me to write my TFVC Tasks extension. The extension was written against the old PowerShell handler and could only be tested by executing a build on the agent, so deployment to my VSTS account was part of my local development workflow. I soon realized that this was something I needed to automate and that led to the birth of my second extension, the VSTS Extension Tasks. A small wrapper around TFX, the cross platform command line tools used to build and publish extensions.

The VSTS extension tasks quickly grew from a simple “Publish” task to a set of tasks to Package, Publish, Install, Share tasks as well as a task to retrieve the latest version that was previously published to the marketplace. And while I was writing these tasks, the marketplace team started to tighten the validations that run whenever a task is published, prompting new features, such as overriding the extension id (to allow side-by-side publishing of the same task), overriding visibility (to have private test builds) and overriding the version of both the extension and the packaged build tasks (to ensure the agent always has the latest version).

Welcome VSTS Developer Tools Build Tasks

These tasks had been in the marketplace for a few weeks when I got word that Microsoft was building their own set of extension tasks in VSTS Developer Tools Build Tasks. The team consisted of a few folks from Microsoft and a number of Ranger/MVP’s, including Wouter de Kort and Mattias Sköld. These new tasks were built in TypeScript, were going to be cross platform and had one big feature my own tasks lacked, the ability to override values in a previously packaged vsix. While I, as a lone developer, didn’t really need this feature, it turned out to be very valuable for larger teams and teams doing binary promotion of their tasks from one publisher to another and from private to public without having to rebuild the task from source.

My experience with TypeScript was non-existent, so the transition from the closed source PowerShell handler to the TypeScript/Node handler was a humbling experience. In PowerShell I was able to rely on the trusted old .NET Base Class Library and my experience from previous PowerShell scripts to administer among other things, TFS servers. With TypeScript I had to fall back om my knowledge of JavaScript, which had slowly dissipated over the years. NPM, Node, Typings, TSC, TSLint, Promises, a whole new world opened up to me. And with it the vast jungle also known as the JavaScript Module Madness. Though it turns out that a lot of JavaScript is like riding a bike. And with the TypeScript training wheels on at least I got faster than ever feedback. The Install, Share and Query Version tasks were ported over in no-time as well as some features such as Override Task Version and the Extension tag option.

Extension housekeeping

Back in July this new extension was finally published to the marketplace and served as the basis for the MSDN article on building a release pipeline for Extensions. In the meantime TFS 2015 update 2 had been released, with its own marketplace and while waiting for the Microsoft extension to pass through all the required reviews, I quickly added on-prem support to my trusty old PowerShell-based tasks. Support for Paid extensions was short to follow. While I published these features through pull-requests to the TypeScript tasks, they were iterating at a much slower pace, partially because the main Microsoft developer could no longer support the project.

When the ALM Rangers bumped into Will Smythe, not really unexpectedly, during the MVP summit, we asked whether it’d be possible to take over the maintenance of these extensions. Will granted commit rights and we transitioned the release pipeline for these tasks over to the ALM Ranger Team Services instance. That was last November. Since we published 3 new releases, adding a number of features requested in the Marker Place reviews: wildcard support for the path to the vsix files, on-prem support for the publish task and a number of small bugfixes. And recently I upgraded the project to the latest version of TypeScript, @types and the vsts-task-lib.

What’s next?

Next on the backlog is to do a little refactoring, get one common codebase for the overrides, whether packaging or publishing from manifest or vsix as well as making the code easier to test. I’m also looking into an option to generate the build task ID’s during the override phase, that way I’m hoping to provide open-source contributors the ability to locally test their extensions without having to juggle with publisher, extension-id and task-ids. Your feedback is more than welcome.

If you are using the VSTS Extension Tools, you should switch to the Microsoft Extension. If you’re already using the VSTS Developer Tools – Build and Release Tasks, I’m looking forward to your 5* review or your feedback on GitHub.

Author - Jesse Houwing is a Agile trainer and ALM consultant for Xpirit Netherlands BV. He’s been an ALM Ranger since 2012 and a Microsoft Most Valued Professional since 2015 and a Scrum.org Professional Scrum Trainer. Since the release of TFS 2015 and the Visual Studio Marketplace Jesse has built 5 public VSTS extensions and contributed to a number of others. All of his tasks are available as open-source on github. He blogs at https://blog.jessehouwing.nl/ and you can follow him on twitter: @jessehouwing.