Two other answers already say "avoid that situation". But that's not always a solution. Sometimes, for some reason, you cannot really avoid this if you want or need to stay DRY. So let me focus on the case where a common library for your services is required and justified. So can you at least mitigate the problem?

First thing is, you need to realize that "commit, push, merge, release, deploy" is not your major problem. When certain requirements change, the biggest effort is usually the in the "develop, test, debug" cycle. And when a shared library changes, this can mean

• change code in the lib, test it locally

• "deploy" a new version of the lib internally to the repos of all services using it

• test & debug all that services together with the new library version

• fix bug in the services and in the library, which means you may have to provide a new version of the library and repeat the former steps again

To stay effective with these steps, I would recommend the following:

• Good test automation for the library itself. New requirements for a library logic should be tested locally up to the point where you are relatively sure all serious bugs are corrected. That avoids to run through the cycle scetched above more often than necessary.

• Keep the library as backwards compatible as you can (and when you cannot, have a systematic deprecation process in place). Just "updating" to the newest version of a lib should not force developers of the services to invest effort only for formal reasons. If you have 10 service using the lib, but only 2 are affected by a certain change, there should be no obligation to change the other 8.

• Good test automation for the dependent services. A new version of the library should be automatically tested in the context of each service, which mitigates the risk to break something by updating the service to this new version. And when such a test reveals a library bug which was overlooked in the local tests, extend the local tests so it won't happen again.

• Automate the tedious steps, like the steps necessary to upgrade to the newest version of a lib. A few scripts will certainly be helpful.

Library development creates always some overhead, that is unavoidable. But that overhead be kept manageable if one automates certain tasks rigidly.

Two other answers already say "avoid that situation". But that's not always a solution. Sometimes, for some reason, you cannot really avoid this if you want or need to stay DRY. So let me focus on the case where a common library for your services is required and justified. So can you at least mitigate the problem?

First thing is, you need to realize that "commit, push, merge, release, deploy" is not your major problem. When certain requirements change, the biggest effort is usually the in the "develop, test, debug" cycle. And when a shared library changes, this can mean

• change code in the lib, test it locally

• "deploy" a new version of the lib internally to the repos of all services using it

• test & debug all that services together with the new library version

• fix bugs in the services and in the library, which means you may have to provide a new version of the library and repeat the former steps again

To stay effective with these steps, I would recommend the following:

• Good test automation for the library itself. Changes of a library should be tested locally up to the point where you are relatively sure all serious bugs are corrected. That avoids to run through the cycle scetched above more often than necessary.

• With each new version, keep the library as backwards compatible as you can (and when you cannot, have a systematic deprecation process in place). Just "updating" to the newest version of a lib should not force developers of the services to invest effort only for formal reasons. If you have 10 services using the lib, but only 2 are affected by a certain change, there should be no obligation to change the other 8.

• Provide release notes for each library version, so the teams for the individual services have a useful foundation for making the decision if they need to update to the newest version immediately, or if they can stay with the version they are currently using.

• Good test automation for the dependent services. A new version of the library should be automatically tested in the context of each service, which mitigates the risk to break something by updating the service to this new version. And when such a test reveals a library bug which was overlooked in the local tests, extend the local tests so it won't happen again.

• Automate the tedious steps, like the steps necessary to upgrade to the newest version of a lib. A few scripts will certainly be helpful.

Library development creates always some overhead, that is unavoidable. This overhead can be kept manageable if one automates certain tasks rigidly, and applies well known configuration management / change management techniques in a disciplined manner.