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?
Should each microservice have its own pipeline?
Because microservices are independently deployed, each will have its own pipeline resulting in hundreds instead of dozens. Version control – While storing our source code objects will still be done, branching and merging will become less critical. A microservice is a small bounded context piece of code.
Can we integrate DevOps concept with Microservices architecture?
DevOps is integral to the microservices architecture because it enables developers and IT operations to work closely together to deliver higher quality software much faster. DevOps benefits developers by giving them insight into the production environment in which their software will run, improving software quality.
How can I improve my Azure pipeline performance?
Use the notion of a multiplier, where you can scale out your builds over multiple build agents. For more info see, Organizing Azure Pipeline into Jobs. Consider moving integration, UI, and smoke tests to a release pipeline. This improves the build speed, and hence the speed of the build feedback loop.
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.
Menu
736
