This post was originally posted on our Northwest Cadence blog – but I feel it’s a really important post, so I’m cross-posting it here!

Edith Harbaugh published a though-provoking post called Staging Servers Must Die with the byline “so continuous delivery may live.” She asserts something which I’d never really considered before: that separate, cascading Dev, QA, Staging and Prod environments is a hangover from Waterfall development.

Remember when Visual Studio had a setup project template? And then it was removed? Then you moved to WiX and after learning it for 3 months and still being confused, you just moved to Web Apps?

In my previous post I experimented with WebDeploy to Azure websites. My issue with the out-of-the-box Azure Web App Deploy task is that you can specify the WebDeploy zip file, but you can’t specify any environment variables other than connection strings. I showed you how to tokenize your configuration and then use some PowerShell to get values defined in the Release to replace the tokens at deploy time. However, the solution still felt like it needed some more work.

It’s finally here – the new web-based Release Management (WebRM). At least, it’s here in preview on VSTS (formerly VSO) and should hopefully come to TFS 2015 in update 2.

Recently I attended the MVP Summit in Redmond. This is an annual event where MVPs from around the world converge on Microsoft to meet with each other and various product teams. It’s a highlight of the year (and one of the best benefits of being an MVP).

I really like the idea of Docker. If you’re unfamiliar with Docker, then I highly recommend Nigel Poulton’s Docker Deep Dive course on Pluralsight. Containers have been around for quite a while in the Linux world, but Microsoft is jumping on the bandwagon with Windows Server Containers too. This means that getting to grips with containers is a good idea – I think it’s the way of the future.

I love the new build engine in VSO / TFS 2015. You can get pretty far with the out of the box tasks, but there are cases where a custom task improves the user experience. The “Microsoft” version of this is SonarQube integration – you can run the SonarQube MSBuild Runner by using a “Command Line” task and calling the exe. However, there are two tasks on the Microsoft Task Github repo that clean up the experience a little – SonarQube PreBuild and SonarQube PostTest. A big benefit of the tasks is that they actually “wrap” the exe within the task, so you don’t need to install the runner on the build machine yourself.

In part 1 I showed you how to scaffold a task using tfx-cli, how to customize the manifest and how to implement the PowerShell script for my VersionAssemblies task. In this post I’ll show you how I went about developing the Node version of the task and how I uploaded the completed task to my TFS server.

SonarQube is a fantastic tool for tracking technical debt, and it’s starting to make some inroads into the .NET world as SonarSource collaborates with Microsoft. I’ve played around with it a little to start getting my hands dirty.