1

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.

  • Is B another service? Do you have separate artifacts for the service interfaces? – COME FROM Feb 15 '17 at 8:08
  • yes essentially a versioned SDK is the interface and we can not pick up a new version of the SDK until it goes into production – Sutty1000 Feb 15 '17 at 8:32
  • Why are you splitting out the application? That could help determine things. If you're already splitting it up, maybe you could reexamine the code. – johnny Feb 15 '17 at 15:11
3

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.

1

You can keep a monolithic app-level branch strategy, release and delivery approach, with all microservices side-by-side but acting as a whole. This would pretty much eliminate the dependency management, backward compatibility requirements and potentially exploding number of integration tests driven by version combinations.

Unless having independent release/delivery stories for each microservice was one of the reasons for which you're splitting the monolith, of course. Personally I consider ability to do that more of a disadvantage, see also https://softwareengineering.stackexchange.com/a/341938/187812

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.