|
|
|
|
|
|
by royjacobs
2605 days ago
|
|
|
Integrating with other products is something that goes beyond the scope of SCM repository layout, though. If you change your API then clearly someone on the other side also needs to adjust, but that's not simply sending a pull request. That's also making sure you deploy your products in the right order, ensure backwards compatibility and so on. Re integration testing: That's why things like contract testing are becoming more popular. You make sure that you do as much testing as you can without relying on an entire ecosystem of depdendencies being available, so once you DO release something you can be fairly confident that it's already working as expected. |
|
|
Classic example in favor of monorepos is shared internal library. You should be able to change its API in one step, because that's the way to not having to care about compatibility at all. Compatibility concerns only happen if there's a time difference and with atomic company-wide update, this just doesn't need to happen.
In my example, backend and frontend can be deployed together. And we can discuss whether they should -- I would say there is little benefit of maintaining such single-purpose, wide interface just for getting the ability deploy frontend changes only, but this would depend on care the team put into configuration of cluster orchestration.
Contract testing is good, but not as good as testing against the real thing. Very much depend on the circumstances though.