1) if you have a blocking bug or code dependency between two microservices OR two monolith modules, that should of course block until it is fixed and resolved. Microservices do not magically solve that.
2) other code changes or features that are not blocked, can be unblocked by being released in a smaller release ( git rebase those commits
to a new release branch on main, and cut, test and deploy a smaller release -- basically gitflow)
3) once the blocking modules are fixed, they should be rebased onto the latest main.
The blocking "effect", even in a monolith, seems like it would be better solved by using a version control system with good rebase support.
Coordination needs to happen for larger changes, and/or the changes need to be smaller.
It just doesn’t seem like that’s scales. The application I work on has a half dozen teams. Releases includes tons and tons of commits soaked for up to weeks. We can’t solve this with cherry picks lol.
1) if you have a blocking bug or code dependency between two microservices OR two monolith modules, that should of course block until it is fixed and resolved. Microservices do not magically solve that.
2) other code changes or features that are not blocked, can be unblocked by being released in a smaller release ( git rebase those commits to a new release branch on main, and cut, test and deploy a smaller release -- basically gitflow)
3) once the blocking modules are fixed, they should be rebased onto the latest main.
The blocking "effect", even in a monolith, seems like it would be better solved by using a version control system with good rebase support.
Coordination needs to happen for larger changes, and/or the changes need to be smaller.