Part VII - Speeding up the test run in an Azure CI/CD pipeline

This article is part of a series for setting up the single pipeline}

Having sped up installing NuGet packages, it was time to investigate why running the tests took so long. Watching the logs in real-time, the tasks sits there apparently doing nothing at first.

It turns out it was searching the entire folder structure for the test files, which makes sense when you look at how we’ve specified the test files:

'**/*.Tests/*.csproj'

If you instead specify the DLL to run, it will be significantly quicker:

'$(System.DefaultWorkingDirectory)\<test project folder>\bin\$(BuildConfiguration)\**\*.Tests.dll'

This has the downside that the Azure code coverage doesn’t work. However, on reflection I’ve decided that I don’t particularly care about having code coverage as a metric for this project. I’m using NCrunch as a live testing tool, and it provides visual markers for code coverage on a line-by-line as you code, which I think is good enough for me.

Conclusion #

So, there we go, we have created both a pipeline for our pull request builds, and a multi-stage pipeline to build and deploy a microservice whilst applying Entity Framework migrations.

The bonus (for me) was being able to have separate a pipeline for pull requests; it’s long annoyed me that the list of recent runs of the build pipeline had two runs for each commit; one for the pull request, and one for the merge into the main branch. By using it only for pull request builds, the list of recent runs looks much nicer (as long as the build didn’t fail, of course).

The one downside (and I accept that it’s a very minor one) is that the stopwatch for the build & deploy step doesn’t stop when it is waiting for approval to be given to deploy to production, which does make sense. I just don’t like looking at a build time measured in days!

On top of that, we managed to create a deployable package for an Azure Linux Web App, and set up the pipeline service connection as a database user that can run Entity Framework migrations, allowing our website database user (which I use the Managed Identity user of the web app) to only have read and write privileges on the database, which feels nicely locked down.

All in all, I’d call this a success.