These days I’m typically using Git for source control. Some of my consulting engagements take me back into the world of Team Foundation Version Control (TFVC). I have used several techniques over the years for getting build versioning working in an automated build against TFVC. These days the easiest solution is a little powershell.

I’ve been using Octopus Deploy for many years across many companies and projects. I am either connecting to it from a build agent via VSTS or on-premise TFS. From a security point of view we want to have the VSTS/TFS build agent having the least permissions required for it to work with Octopus Deploy. This post lists the permissions required to make this work.

Using the same concept of putting Octopus Deploy behind a reverse proxy, I want to wrap SonarQube behind an IIS reverse proxy so I can use Let’s Encrypt certificates to host it.

I posted a couple of months ago about some ideas I had for integrating Let’s Encrypt certificates with the hosting of Octopus Deploy. The idea was to use many PowerShell scripts with a scheduled release to request a new certificate and install it against the Octopus Server.

I never got to complete this and have since come up with a much easier solution, the reverse proxy. The way a reverse proxy works is by exposing one website as a wrapper around another (internal) website. This is a feature that IIS supports and works well with Octopus Deploy.

I posted recently about module loading in modern JavaScript development to assist in breaking up complex scripts into individual files/modules. How do we get the benefit of external modules and also get the benefits of dependency injection for unit testing our scripts?

One of the things I really like about AngularJS as a long term SOLID practitioner in the C# world is the inbuilt support for dependency injection. This post looks at how to join module based JavaScript applications with dependency injection when AngularJS is not in the picture. The code is in TypeScript however the concept is the same regardless of script flavour.

I posted the other day about trying to integrate Let’s Encrypt with Octopus Deploy. Nathan Stohlmann had a great idea of using machine policy health checks as a way of triggering certificate renewal of Octopus Deploy. Here is the powershell to do just that.

I’ve been keen to configure an Octopus Deploy server with Let’s Encrypt certificates. The ultimate goal would be for this to be fully automated so that the the server can maintain it’s own certificates.

TL;DR - This post provides a collection of custom Octopus Deploy steps that can assist with DNS based domain validation to process Let’s Encrypt certificates.

I use GitVersionTask extensively in my projects so that I can get really good automation over my software versioning. I found a performance issue against one repository last year when using GitVersionTask 3.6.0 and greater. The biggest impact this had was on the build agent which provides both validation of the developer commits but also a build for the tester to promote to a test environment for validation. My team was hitting a large bottleneck because of the slow builds.

This performance issue by no means devalues GitVersionTask and we will continue to use it regardless of performance. It also seems like we are an outlier in how GitVersionTask is performing against a specific repository. I have the utmost respect for the people behind GitVersionTask who are frankly a lot smarter than I. This post describes a workaround put in place to address the bottleneck in our build process while the performance issues are addressed.

I have been slowly working on rebuilding a web application from ASP.Net MVC into a SPA application over the last six months. The timescale of this work has been a blessing and a curse. It is a blessing because there has been an amazing churn in the client frameworks, build pipelines and current best practices so I get to learn a lot of new things. This is directly linked to the curse however as it makes it very difficult to rewrite an existing system and keep up with that rate of change.

I want to share what I have learnt about module loaders as part of this journey. It is new to me so please shout out any inaccuracies in the comments.

One of the benefits of work items in VSTS/TFS is the ability to put metadata into your project system. Associating work items with automated builds is a good example of this. The XAML build system in VSTS/TFS has a handy feature of linking the build number against associated work items as a part of the build process. Unfortunately, there is no out of the box implementation to achieve this in build vNext.

The XAML build workflow stores build numbers in the Microsoft.VSTS.Build.IntegrationBuild field to link a work item to the build. The IntegrationBuild field is only visible by default in the Bug work item template however the field still exists for PBI and Task work items. You can modify the PBI and Task work item templates however to make this field visible.

We can add the functionality for linking work items to builds by executing some PowerShell during a build that will populate the IntegrationBuild field. As this will be a custom script we can also add some additional functionality.