[iamtew]

> Whenever a change in any service is merged to master, the CI rebuilds _all_ the services and pushes new Docker images to our Docker registry.

Why are you rebuilding _all_ the services, wouldn't it make sense to just rebuild the ones that have changes? You're now rebuilding perfectly working services without any new changes just because some other service changed, or am I misunderstanding something here?

[dhinus]

Because we want to make sure that in the Docker registry we have _all_ services tagged with the latest commit.

For example you might have a Git history like this:

* 89abcde Fix bug in service_b

* 1234567 Initial commit including service_a and service_b

When 89abcde is pushed, the CI rebuilds both service_a and service_b so we can simply "deploy 89abcde" and you always have only one hash for all services, that is also nicely the same hash of the corresponding Git commit.

The trick to avoid rebuilding perfectly working services is to use Docker layer caching so that when you build service_a (that hasn't changed) Docker skips all steps and simply adds the new tag to the _existing_ Docker image. The second build for service_a should take about 1 second.

In our Docker registry we end up with:

service_a:1234567

service_a:89abcde

service_b:1234567

service_b:89abcde

But the two service_a Docker images are _the same image_, with two different tags.

[segmondy]

Why? Microservices are suppose to be truly independent.

[dhinus]

For ease of deployment and to solve the problem of "what version of service_b is compatible with version x of service_a"?

IMHO this makes sense if the microservices are developed by the same team. If we're talking about services developed and managed by different teams... maybe it's not a good idea.

[clintonb11]

My guess is that it is because of the mono-repo. Since it would take some work to figure out what changed and what to build, they just did it the easy way and re-build everything :-)