Setting up Azure Pipelines for a dotnet core microservice
I’m knee-deep in the (long) process of splitting a painfully-dated monolith into a couple of microservices. Whilst I’ve mostly been refactoring/re-writing out a lot of coupling from the existing code, I had set up one basic microservice earlier this year, and finally had the need to set up the second one. The aim is to slowly move entities over to each microservice until none are left in the original codebase.
I don’t know about anyone else, but whenever I have a task that I haven’t done for a while, my first port of call is to look back at what I previously produced. In this case, I was able to re-use the build pipeline YAML file from the first microservice, but release pipelines is purely managed using the Azure UI.
Hello, multi-stage pipelines #
Some searching soon revealed that isn’t a feature that is coming to the release pipelines. What Microsoft have done instead is introduce multi-stage YAML pipelines. Instead of having separate build and release pipelines, you have one single pipeline that can contain multiple stages, such as build, deploy to test, and deploy to production stages. And it’s all in an easily-transferable/copyable YAML file!
Is it scope creep if you add it in before you’ve started? #
To add an additional wrinkle, I wanted to move the microservices from a Windows App Service to a Linux one, as that would be cheaper in the long run. And, to make it even more interesting, given the microservices use the code-first approach of Entity Framework, I wanted the database migration stage of the deployment to use a different database user than the website uses, as I’d rather not have to grant the website user permission to create, alter and delete tables. Ideally, I’d like this to use the managed identity that Azure can assign to a web app, rather than needing to provide a password in the connection string.
The posts #
So, let’s get started! I’m going to break this down into a series of posts, as I can envisage future me needing individual parts of it at some point.
Part I - Creating a build pipeline for pull requests.
Part II - Creating a build & deploy pipeline.
Part III - Adding a deployment stage to a multi-stage pipeline.
Part IV - Allowing the build pipeline to run Entity Framework database migrations.
Part V - Adding a production deployment stage to a multi-stage pipeline.