Our first steps of embracing DevOps when building Visual Studio Team Services Extensions

  • Article

Visual Studio Team Services extensions allow us to provide gap-filling solutions on the Visual Studio Marketplace, enhance the product, user productivity and experience.

The number of extensions, updates, and associated moving parts have been steadily clocking up. As a consequence we have been been considering the promise of DevOps to embrace a set of processes, methods, culture and collaboration. This post summaries our plans to automate, continuously learn and evolve our extension teams, using Visual Studio Team Services and other interesting technologies.

Research teamimage

It is definitely a team effort, however, Wouter de Kort and Mattias Sköld are both on the critical path for this exploration. Wouter is working on tooling for building extensions for Visual Studio Team Services and Team Foundation Server. These will, we hope, simplify and solidify the hand-crafted processes that Mattias is using to assemble our first pipeline.

Our plan

Our objective is to:

  1. Prove the concepts and value, using three of our extensions. Likely candidates are: Sample Data, Test Case Explorer, and Folder Management.
  2. Contribute to tooling for building extensions that are based on Josh Garverick’s VSTS Extension Project Template.
  3. Upgrade the pipelines to use the tooling for building extensions and create a reference blueprint.
  4. Share our learning’s in crisp guidance and exploratory articles.
  5. Migrate all extension teams to use the reference blueprint.
  6. Monitor, learn and evolve.
  7. goto 6;

At this stage, we are busy with step 1.

The first “COWABUNGA”moment

After quite a few experiments, failed builds and releases, and a few shaken Canaries, we have had a “COWABUNGA” moment. All the release environments turned green and Sample Data lit up on the Visual Studio Marketplace, without any manual intervention, other than approving deployments.image

Canaries? – A domestic bird, historically used as a sentinel to detect toxic gases in coal mines. In the context of Visual Studio Team Services, they act as an early warning for process and tooling issues, i.e. blocked queues, slow-running services, and other anomalies.

Cowabunga? – An informal exclamation to express satisfaction. Remember the Teenage Mutant Ninja Turtles?

SNAGHTMLfa5a64

If we drill into the release we see three environments. The Team environment is used for development, Beta environment for demonstrations and user acceptance testing, and lastly Public environment. Extensions are private while deployed in the first two environments. When deploying to the Public environment, the extensions are switched to Public and Preview.

SNAGHTML100cfa7

Let’s take a few steps back and look at some of the magic happening as part of the build and release events.

  • Each release environment runs the npm install task, enabling us to build and deploy node.js applications.
    SNAGHTMLc7053
  • The command line task runs the tfx (Team Foundation command line interface), to override the manifests and publish the extension.

extension publish  --token $(PublishExtToken) --overrides-file $(ManifestOverrideFile)  --share-with $(SharedAccounts)

  • Wondering why and how does the version number of the extension is the same as the associated build number? If yes, the “secret sauce” lies within the build that triggers the release. It runs a command line build step, which runs a PowerShell script that does a few replacements:
    SNAGHTMLf0343

-command "(Get-Content vss-extension.json).replace('0.0.1', ('%BUILD_BUILDNUMBER%').replace('SampleData ',''))  | Set-Content vss-extension.json"

  • The result is an updated version in the extension manifest file, that matches the build number.
    SNAGHTML12f90e

… next we need to ensure the Test Case Explorer release turns green and migrate the command line and script magic to the extension that Wouter is contributing to.

Last, but not least, did you know …

  • You can a GitHub repo with Visual Studio Team Services? Our Folder Management extension lives in a GitHub repo, with a Continuous Integration (CI) trigger on Visual Studio Team Services to engage the build and soon the release processes.
  • You can supress a continuous integration build, by adding ***NO_CI*** to your checkin comments? Unless you want to stress-test the build and monitoring systems, supressing a CI build for documentation or interim type changes is probably a good idea.

We would love to hear from you

Are you planning or doing something similar?

We would love to hear from you. Here are some ways to connect with us: