I like the idea that a build definition is code and can go under source control. Azure DevOps already has change control of build definitions so this outcome does not necessarily have to use Git. There is one scenario where the traditional build definition does not satisfy this though. It is when the state of the code in a branch requires different build logic than the code in another branch. The build yaml in Git is perfect for this.

Way back in 2013 I originally posted my EntityAdapter<T> to make it really easy to read and write .Net classes to Azure Table Storage. There have been a few updates since the original post, some of which were never made public. This post provides the latest version of that class and some examples of extensibility.

I’m a big fan of using GitVersion to calculate an application version based on git history. I’m also a big fan of the new csproj format because of its simplicity. GitVersion provides a build task for Azure DevOps build pipelines but unfortunately it does not yet support setting project versions for the new csproj format. This is my workaround until it is supported out of the box.

I posted previously about a package I put together to easily support rendering ILogger messages to the xUnit test output. This package now supports rendering logging scopes thanks to a pull request by Sebastian Weber.

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