When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again.
While I'm a fan of monorepos, that issue doesn't completely disappear there, does it? I mean, if the monorepo contains the code for N artifacts (say, N, microservices that interact with one another), you will still have to make sure that the master version of microservice 1 plays nicely with the currently deployed version of microservice 2.
I think this kind of complexity is not the reality of most developers. They just stop all old services, update them and re-start them during a maintenance window.
That'd be news to me. At least in all big companies that I've come across, where revenue depends on services to be available 24/7 and maintenance windows maybe happen once a year, I have never heard of such a thing.
Comments
While I'm a fan of monorepos, that issue doesn't completely disappear there, does it? I mean, if the monorepo contains the code for N artifacts (say, N, microservices that interact with one another), you will still have to make sure that the master version of microservice 1 plays nicely with the currently deployed version of microservice 2.
I think this kind of complexity is not the reality of most developers. They just stop all old services, update them and re-start them during a maintenance window.
That'd be news to me. At least in all big companies that I've come across, where revenue depends on services to be available 24/7 and maintenance windows maybe happen once a year, I have never heard of such a thing.