We are in the process of slowly splitting out a monolithic application to smaller services and one of the debates we are having is how to manage dependencies. The challenge we have is that service A has a dependency on B. A pulls its dependencies from the release Nexus repo. The problem is B is built and the dependency for A goes into the release-candidates nexus until the build is approved for production. This means new features on B are not immediately available to A. We are discussing if the current approach is the best approach or should B be promoted to the release nexus repo at an earlier stage e.g. after the automated tests have passed with the risk defects being found in B by exploratory testing impacting A.
How to manage dependencies for microservices?
continuous integration;microservices;dependencies;continuous delivery
It's hard to give an exact answer without further knowledge of the architecture of the system. However, I'd suggest building and releasing the artifact that more or less contains the interface of service B first.The interface should not have any logic in it that needs testing. It also shouldn't have any dependencies to other artifacts of your system yet to be released. So, it should be easy to change the interface and to release a new version of it.After the interface has been released, the next version of the client can be developed and built against the already released version of the service interface. There's no need to have the service implementation released yet. Actually, even the service itself could be developed only after releasing the interface. Since there are no direct dependencies between the services themselves, promoting services A and B can be done in any order or at the same time, after exploratory testing or so.This is dependency inversion principle applied to packaging and configuration level. The service A does not directly depend on the implementation of service B. They both depend on the interface of the service B.