We use jenkins for testing the individual microservices, and the application integration as a whole.

The approach is similar to parametric builds in jenkins. The problem is the management of the parameters.

For example:

msA v1.0 & maB v1.0 are individually green, and pass all integration tests. Green build for app.

msB is updated to v1.1. Passes individual tests but fails integration with msA v1.0. Red build for app.

msA is updated to 1.1. Passes individually. Still fails integration with msB v1.1. Red build for app.

However. msA v1.1 is still compatible with msB v1.0, so we could have a green app build with a newer version of msA.

Automating this process is what is becoming cumbersome. We have many more services in dev at any one time.

This sounds like a constraint satisfaction problem. If you want to go all hardcore on this (and willing to pay the complexity price), then you can devise a system that can, on every new build of every new service, try to find the optimal combination of service versions that "work together nicely". Here are some data points that you'd need to implement this:

- What other services each service depends on

- What previously released versions of services worked with what versions of dependecies

- Ability to automatically test new versions of each service against its dependencies

Then you plug all that in to a solver that runs on every build, and voila, you have your Microservice Dependency Constraint Satisfaction Manager Machine™. If you do go this route, it would make for a great open-source project.