How to best use Azure Devops release pipelines with microservices?

6
votes

I'm migrating a microservices ci/cd pipeline from a teamcity+octopus setup to Azure Devops.

We currently have:

  • Multiple repos for each service and web site.
  • A teamcity ci build which triggers an octopus deployment for each build.
  • An overnight scheduled set of integration tests run to test the whole platform and if they succeed then all the dev services are promoted to our nightly environment.
  • A manually triggered promotion of all services from nightly->prod.

I'm trying to do something similar in azure devops but that concept of promoting many services/components together seems difficult and a bit ugly using the gates and some custom search for open bugs to prevent the deployment.

Is anyone able to suggest what is best practice for what I'm trying to achieve? Should I have a single release pipeline that pulls in all artifacts from all the repos?

1
azure-devopsazure-pipelines

1 Answers

8
votes

Detailed blog post explaining the why's here

tldr…

  • Having a repo per micro service/releaseable unit/web front end makes sense.
  • Each repo/micro service/releaseable unit/web front end has a CI build that compiles, runs extensive unit tests and creates your build artifacts. If any of those unit tests fail, the build fails.
  • You can have a release pipeline for each CI Build as these pipelines can be used to deploy just an individual micro service if you want.
  • For this scenario, you can then have a release pipeline that uses the build artifacts from each CI build. It will use the latest successful CI Build for all the repos. This release pipeline will have 2 (or more if you need them) stages. A nightly/testing stage and a production stage. The nightly/testing stage grabs all the latest successful artifacts and deploys all the services. At the end of the deployment, runs your integration tests. And if those passes, it goes to the next stage (prod) where you have a manual approver who will approve the release to production.
  • So here’s where things get interesting. If you wanted to follow the same type of workflow as Rob is currently using, you can have this all-encompassing release be triggered on a schedule. In his workflow, it looks like this trigger is scheduled once a night. That does limit your release to at most 1 per 24 hours (or as many times as you schedule your trigger and yes, you can trigger more manually too). This seems a bit restrictive. Now, my pipeline has a bottleneck based on my scheduled trigger. If you wanted to, you can have the release be triggered on changes to the build artifacts! So anytime there is a successful build for any of the CI Builds for each individual repo, this will trigger the release pipeline. Which will deploy to nightly/testing. Run integration tests, and if everything looks good, gets passed to the production stage.