opencover

The importance of canary builds.

So now that Visual Studio 2017 is officially out I thought I would use the long Easter weekend to upgrade the OpenCover project to this new version and tackle any...

Shaun Wilde
a miner looking at a canary

So now that Visual Studio 2017 is officially out I thought I would use the long Easter weekend to upgrade the OpenCover project to this new version and tackle any issues that I normally encounter when this upgrade time comes around. However before I can start this upgrade process I first need to tackle the bit rot that has recently set in.

Bit rot (or software rot) is when your code just starts failing due to lack of maintenance or a change in the build or execution environment.

Fortunately I have a weekly canary build that I previously set-up that amongst other things will alert me when this happens (as well as inform me if I get any new code quality issues), it started bleating, or should that be tweeting, a few weeks back so I knew I had some issues to rectify but not the actual severity. So in the space of a few months (I decided to stop work on OpenCover over the summer as I needed a break and time to look at other technologies) the following things happened:

  1. AppVeyor upgraded its Visual Studio 2015 image to use a release version of .NET Core. This caused a number of issues that I couldn't repeat on my local build environment so I have temporarily resolved the issue by uninstalling it for my server builds.
  2. The local and server builds don't build the same flavour of the .NET Core application so I needed to update the tests to take that into account; I intend to look into this more after completing the upgrade.
  3. Badges were failing and so the landing page was looking a bit daggy.
  4. The build was failing and was not reporting it properly, this was easy to resolve and I was surprised it had escaped unnoticed for all this time.

If it wasn't for the regular weekly build I would not have been aware of some of these issues and makes me glad that I configured that build to trigger regardless of whether I or anyone else had submitted code to the repository. Now that I have a working (and hopefully more reliable) build again, I am now ready to tackle the upgrade and more than likely I will have to update the tooling again.

Title Image: Getty, CC-BY