I recently broke a fairly large Windows Service application which ran a lot of jobs (using Quartz.net) down into individual Azure Functions. Most of the jobs (now functions) participate in a logic flow of data from one end of the system to the other. While there were many benefits for breaking up this sytem into more of a micro-services architecture, it did leave one big problem. How do you run multiple functions on the local machine?

I’ve been using VSTS Release Management more and more recently. One of the issues I had (which took me far too long to solve) is how to restrict the automated trigger of a release into a Production environment based on the version (build quality). This actually turned out to be trivial to implement.

I’m quite a fan of the JSON configuration support that is available in ASP.Net core. Even better is that using it is not restricted to just ASP.Net and I use it on all my projects. One of the big benefits of this new configuration system is being able to represent configuration as a hierarchy of information rather than a flat list of key value pairs.

I use a lot of dependency injection and it is very common that components in a system require some kind of configuration. My preference is to define an interface for that configuration and then represent that configuration in a JSON settings file.

This post looks at a little Autofac module that can help with loading configuration data into a set of classes and register each of them in an Autofac container.

Exception reporting and alerting has always been important for software delivery. I’ve seen companies use many solutions for this over the years, from using email as an error logging system (that story does not end well….twice) to the Windows Event Log that people usually do not monitor. On the other end of the spectrum are more mature systems like Raygun.com and Sentry.io.

Aligning with the idea of “don’t build something that someone else can do better and cheaper”, I’ve been using Raygun and Sentry for years. Over this time I’ve been looking at easier ways of integrating with these systems while also reducing coupling in the application code. This post looks at how to integrate with Sentry via ILogger.

It is very common to have logging in your code. Unfortunately there is not a great way for asynchronous test frameworks to capture that output when running unit tests. The xUnit test package is my favourite test framework and I would like to see the logging from my classes being tested ending up in the xUnit test results.

I have published the Divergic.Logging.Xunit package on NuGet to support this. The package returns an ILogger or ILogger<T> that wraps around the ITestOutputHelper supplied by xUnit. xUnit uses this helper to write log messages to the test output of each test execution. This means that any log messages from classes being tested will end up in the xUnit test result output.

Sentry.io is a wonderful platform for capturing, alerting and reporting on application exceptions. One of its features is to track releases of your software. This is handy so that you can not only associate an application exception with the version of the software it occurred in, but you can also indicate which version of the software fixes the issue. This post demonstrates how to create a Sentry release when using VSTS Release Management (or Builds).

Azure Functions is a great platform for running small quick workloads. I have been migrating some code over to Azure Functions where the code was written with dependency injection and usages of ILogger<T> in the lower level dependencies. This post will go through how to support these two requirements in Azure Functions.

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.