On the potential of Bash on Windows in a DevOps world

One of the announcements of todays’ //build is the availability of Bash on Windows, thanks to Ubuntu. I share the excitement as well, but focus on individual developers left something behind IMHO: it is a great step ahead for development purposes on development machines, but also from a DevOps perspective.

Let’s put it in this way – if you are developing a cross-platform application, which can run on both Windows and Linux, you now have the potential of a single set of scripts for automation.

You won’t have to maintain two different sets of scripts. You will be targeting both Windows and non-Windows machines, with the same logic, reducing maintenance costs by roughly half and standardising on procedures which would work on both.

I really see it as a game changer in the DevOps world!

SCVMM extension for the new Team Build in action

I mentioned that a few times – I am a real enthusiast when it comes to certain topics, and Lab Management is one of these.

If you installed the SCVMM extension like I did in the last post, then you will find extremely easy to use it in your build process.

You’ll need to create a SCVMM Service Endpoint to allow the tasks to interact with the server:

Once this is done, you will find the new task under the Deploy tasks:

This task has some actions, and it can interact with both a host or a cloud:

There is also a minor bug in this version: if you try to start a VM the task will wait until the end of the specified Wait Time even if the VM is started. THis is going to be fixed soon though.

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:

.

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:

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

It is as easy as they say!

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

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

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.

Why a TFS pre-release in production?

So, big question: why should I run a pre-release Team Foundation Server update in production? Isn’t it risky? And what about support in case things go wrong?

The biggest reason why you’d want to do that is because you really want to allow your users to enjoy the very latest features of the platform.

For example now we have TFS 2015 Update 2 available as a Release Candidate 1, and you might really want to deploy it because it includes the new Release Management features (for the record, I am ). You can also have reasons related to performance problems, very specific bugs, etc. but usually features are the culprit.

The quality bar is pretty high. I ran many non-RTM releases in production and I hit very few problems or blockers, with live loads and real users’ expectations.

The second best thing about running a go-live pre-release is, oddly enough, support in case things go south. If you have a production issue with a pre-release of TFS, you get some kind of special attentions and for free!

That is because you are providing some very useful feedback from production scenarios, collaborating to increase the overall quality even more.

And eventually – if you upgrade to a pre-release you are still on the official upgrade path, so you can move off it without problems when the RTM is out.

There is a trick though – you must run only go-live releases in production. It might sound obvious, but think about it for a second: it is a pre-release, but if it carries the go-live license it means the quality is high enough to be trusted in production. Different story if we look at CTPs or betas – they often aren’t go-live supported and they are meant only as an evaluation version for future upgrades.