3 ms·
I've seen this happen where you develop a micro service and everything is working fine but the framework team makes a breaking change and doesn't tell you. Now
by quantumhobbit 9y ago
I've seen this happen where you develop a micro service and everything is working fine but the framework team makes a breaking change and doesn't tell you. Now your micro service is broken and it is somehow your fault because only your team is responsible for the micro service.
- yeukhon 9y agoYes, dependency management is never fun. I think the current approach we have in all languages fail short because we all depend on a text file declaring dependencies. We need to be able track the dependencies and versions. As part of the build process before merging code into a release branch or master branch, it's probably worth reading the flat file, parse the content, and check with a service (backed by a database). -> depends A -> B B -> C C -> nothing D -> A If A has changed, then on merging A, we should run D with new A. If C changed, then A, B, C, D are need to be tested. A flag or a tag for "non-backward compatible" should be added so on merging we can notify the developers (both producer of the library and consumer of the library) aware of breaking changes in their review queue. If breaking changes keep popping up, time for the tech leads and team managers of both sides to meet and understand how to avoid breaking changes so often. I don't know, someone working with large tech stack should comment on their experience. But we can't just use a text file and an email hoping someone would follow up or realize.
- z3t4 9y agoin my experience its always worth doing extra work to avoid circular dependencies and couplings.