Advantages of a shared architecture: the TFS/VSTS example

A few months ago I wrote a throwback article for MSDN about VSTS, its journey from “TFS in the cloud” to a full-fledged service, and its evolution.

It is great to see how things evolved, and now it is pretty much the opposite compared to five years ago – they share the same architecture, but for clear reasons VSTS is updated every three weeks compared to the quarterly TFS updates.

A perfect example of this shared architecture is the Extensions Marketplace. Released late last year, the Marketplace is the major vehicle for Extensions deployment and distribution.

It is not only cosmetic extensions and tweaks – even major changes like the SCVMM Integration extension for the new Team Build is distributed that way, which includes VMWare support for Lab Management!

Anyway – back to topic – if you browse to the _gallery page of your TFS 2015 Update 2 RC2 (and RTM when it will be), you will find this:

image.

Which means that extensions built for VSTS can be reused in your on-premise TFS with no changes! For example, let’s take the SCVMM extension I mentioned before:

image

You can download it, and you are going to be presented with the upload instructions:

image

It is as easy as they say!

image

image

It is literally it. You now need to install the extension, and this is per-collection:

image

image

Once you upload the extension, this is available in the gallery exactly like the VSTS’ counterpart:

image

image

The great advantage of this architecture choice is that once you deploy something to the cloud, it is much easier to backport it to on-premise and it saves a lot on the maintenance side of the product – once you deploy a fix, the fix is (99% of the time) for both.