|
|
|
|
|
by aswerty
595 days ago
|
|
This mirrors my own experience in the SaaS world. Anytime things move towards multiple artifacts/pipelines in one repo; trying to understand what change existed where and when seems to always become very difficult. Of course the multirepo approach means you do this dance a lot more:
- Create a change with backwards compatibility and tombstones (e.g. logs for when backward compatibility is used)
- Update upstream systems to the new change
- Remove backwards compatibility and pray you don't have a low frequency upstream service interaction you didn't know about While the dance can be a pain - it does follow a more iterative approach with reduced blast radiuses (albeit many more of them). But, all in all, an acceptable tradeoff. Maybe if I had more familiarity in mature tooling around monorepos I might be more interested in them. But alas not a bridge I have crossed, or am pushed to do so just at the moment. |
|