So we have a microservices architecture. Quite often we release features that require changes in several repos simultaneously. What approaches are best for handling this?

Ex. Pull Request 1 from Service A dependends on Pull Request 2 from Service B. How do we make sure Pull Requests are integrated and merged into the system in that order?

We have CD pipeline and use git.

  • I don't see a problem in deploying in a specific order? Just deploy in that order. Deploying at the same time on the other hand.. – Thijs Riezebeek Mar 28 '18 at 23:09
  • 1
    Quite often we release features that require changes in several repos simultaneously -- Aren't microservices supposed to operate more or less independently? Isn't the fact that you often require changes to several repos simultaneously indicate a problem with your architecture? – Robert Harvey Mar 29 '18 at 0:02
  • @RobertHarvey There are several instances where this might happen. Sometimes we are introducing a new feature that requires additional data, so for the new service that powers this new feature, the services that handle that data have to be updated with this new data gathering and delivering. We are working on reducing dependencies between services, but coming from a monolithic architecture, it does take some time. Fortunately, we now are measuring external dependencies (and solving them) so that should help. – Arturo Diaz Apr 6 '18 at 20:07

Some theory:

The goal for CD is to deliver change to the production environment with highest velocity. To do successfully, however, feature delivery should be separated from feature activation. A given environment needs to be able to support many incompatible inactive features. Feature compatibility can then be managed at activation time.

The goal for microservices is to allow for more flexibility around component dependencies and cross-component call compatibility. In a monolith, component dependencies have to be satisfied at the language level in very limited ways by something that looks like a compiler. With microservices, component dependencies and call compatibility exists only at the data level, so multiple languages can be used and multiple data model evolution strategies can be practiced.

With that in mind:

Of course no one is perfect, but generally speaking, having cross-repo dependencies that will show up in the pipeline is the kind of pain habit that you should work your way out of rather than continue to suffer with.

Make only additive changes to upstream components, so that downstream isn't broken, and introduce new components when that isn't possible. Put the use of changes behind feature flags, so they can be deployed separately from being activated. Track the feature dependency graph, so that feature activation can be safely done for users in the right order.

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.