how to specify the dependency in the deployment?

Question

This is a design question. I am not sure this is the right place. We have multiple microservices deployed using a blue/green pattern in Azure DevOps pipelines.

What I am trying to achieve is I want to deploy (trigger pipeline) services based on the service version.

As an example, let's say we have three services A, B and C which have an internal dependency graph, and different versions, i.e. A@1.2

If I want to deploy, say service A@1.2 and for that to work we want service B@2.1 and service C@1.1.

So when I decide I want to deploy service A@1.2 automatically I want to trigger the pipeline for service B@2.1 and service C@1.1.

So, we want to deploy exact version of those services on a set of events, such as upgrading the underlying k8s cluster, or similar changes.

I tried to trigger pipeline from one pipeline to other(pipeline trigger), but I am not able to pass the exact same version what the dependency service needs to be deployed

Answer 1

If I understand correctly this question is based on the problem I initially outlined here - https://worklifenotes.com/2020/03/04/microservices-combinatorial-explosion-of-versions/

So we've been working on this for the past 2 years. Key things in the approach that we find performing well so far are the following:

1. All components should be built independently. Triggering one pipeline from another pipeline is an anti-pattern - which usually results in a messy process.
2. You need an integration layer on top of individual builds to mix and match components together and record the resulting metadata. In many cases taking always latest is ok. In the simplest case, you can make it work with a commit to a dedicated git repository to capture working set of inter-version links. In some cases (regulated environments) more is needed - say you are required to pin some component at a certain version or have more automation or better audit in place. This is where specialized tools like the one we are building (Reliza Hub) or alternatives (i.e. DeployHub) may be used for the purpose.
3. Regarding the deployment - at deploy time your instance would query source of truth which holds version permutations (again, in the simplest case - this would be a dedicated git repository - see GitOps, or in more complex case - a specialized tool would be in the mix). Essentially, here you are establishing an authoritative source of what version goes to which environment based on some rules.