The main idea is to enable developers to deploy each microservice separately without any downtime. The working theory is that if we are able to deploy small services separately, it will increase our confidence (bugs can only affect a small part of the environment), TTM (no giant releases every other week) and flexibility (easier to create new services than adding them to a monolith).

This means that we at least need:

• Separate build pipelines for each service
• An easy way to figure out which code is in each release and environment
• Easy to roll back to a previous version

We ended up using Azure DevOps for build/release management, Azure Container Registry to store our released Docker images, Kubernetes as our container orchestrator and Azure Api Management Service as the public facade.

Separate build pipelines for each service

Since we have ended up using a monorepo, it is not possible to automatically detect which service was changed on each commit. We have opted for a manual trigger for each service. If a service has been updated, the developer can trigger a new release of that specific service in the DevOps dashboard. Each service uses the same pipeline (defined in Infrastructure/pipelines/azure-pipelines.service.yml), and injects service-specific values using build variables.

Kubernetes is smart enough to only apply changes if something has changed, we are only using one release pipeline. We have set up all services as artifacts for the release, and an automatic trigger to deploy new builds to the preprod-environment. This means that a triggered build will automatically deploy that service to preprod. This does not happen for the Kubernetes-configuration itself, which has its own build pipeline called provisioning. That was necessary to make the configuration available to the release pipeline.

Which code is running where?

For now we have solved this by labeling the deployments in Kubernetes with the docker image-tag currently running. The image tag of the docker-image is the build number from Azure DevOps, which is the date + a revision number if multiple builds happen the same day. To make it easier to browse the source at that specific point, each build tags the source commit after completion with the service and buildnumber. Each time a release is created, a github release is also created linking back to the triggering release.

Rolling back

This is not fully fleshed out either. Worst case, we can trigger a build using older images from Azure Container Registry. Investigate if using helm rollback and multiple deployments is an option.