Config Per Environment vs Tokenization in Release Management

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.

Docker DevOps

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).

Continuous Deployment with Docker and Build vNext

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.

Developing a Custom Build vNext Task: Part 1

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.


© 2021. All rights reserved.