testing – Efficiently updating a common repository used by multiple other repositories

Suppose we have a project consisting of many microservices, all of which use a common library. The common library has been put into a separate git repository, and each microservice is also in its own individual git repository.

When the time comes to make a change to the common library, how should that be done? Because all of the microservices use it, it seems like it would be necessary to clone all the microservice repositories that were not cloned locally already, update each of them to point to the new version of the common library, publish locally the new version of the common library, and then run all of their tests. And then, in principle, this has to be done on the CI system as well, because otherwise there could be a subtle difference in the local environment that makes the change happen to build OK on the local environment, but not in CI!

If we don’t do this, but simply do the lazy thing and update only the common library and the particular microservice we are working on at the moment, we run the risk that we accidentally break something in another microservice and that this only becomes apparent later when the dependency on the common library gets bumped in the latter microservice. If the common library were an open source project and the microservices depending on it were third party code, we could just say “tough luck – you fix it on your side, or raise a PR to fix it on our side. It’s not our responsibility to babysit your repositories.” But since they are our repositories, they are our responsibility – so we shouldn’t really break them gratuitously with a poorly-thought-out change to the common library.

However, the approach of testing all common library changes everywhere that I have outlined is laborious – and doesn’t scale particularly well, either. (Imagine if Google had their billions of lines of in-house code, not in a mono-repo but in this kind of setup – how would they be able to make safe changes to shared libraries in a scalable way?)

What sorts of approaches can be used to better manage such updates and make the QA more efficient?