|
|
|
|
|
|
by chipdart
590 days ago
|
|
|
> As soon as you split 1 repo into 2 repos you need to start building tooling to support your 2 repos. No, not really. If you're talking about projects for modules and components, all you need is a versioning strategy and release consumable packages of your projects. If you're talking about services, all you need to do is support versioned APIs and preserve your contracts. No tooling required. For projects you can even make do with git submodules. For services, all you need to do is update clients of your downstream dependencies. What problems are you facing, exactly? |
|
|
If you aren't using a monorepo, you need some versioning process, as well as procedural systems in place to ensure that everyone's dependencies, stay reasonably up to date. Otherwise, you end up deferring pain in really unwanted ways, and require sudden, unwanted upgrades through api incompatibility due to external pressure.
This also has the downside of allowing api-owning teams to make changes willy-nilly and break backwards compatibility because they can just do it behind SemVer, and then clients of the api need to own the process of migrating to the new version.
A monorepo fixes both of these: you cannot get out of sync, so it is the api-owning team's responsibility to upgrade clients, since they can't break the API otherwise. Similarly, you get a versioning process for free, and clients can never be using out of date or out of support versions of a dependency.
Services work approximately the same either way, since you can't assume synchronous upgrades across service/rpc boundaries anyway.