3 ms·
Even if it builds successfully, I've never worked anywhere where automated tests prevented 100% of problems and I doubt I ever will. For most systems of suffici
by tuckerman 1y ago
Even if it builds successfully, I've never worked anywhere where automated tests prevented 100% of problems and I doubt I ever will. For most systems of sufficient complexity you are testing in prod, even if you did a lot of testing before prod as well.
- roguecoder 1y agoThat's even more true for microservices, though, since I have yet to see a microservice architecture that automatically runs end to end tests before deploying. The post I was replying to said "your build will still break": that's what I was taking issue with. In this day and age there is no reason our trunk build should ever be broken.
- mjr00 1y ago> I have yet to see a microservice architecture that automatically runs end to end tests before deploying. One of the big tenets of independent services is that your APIs are contracts that don't change behaviour. As long as each individual service doesn't introduce breaking changes, the system as a whole should work as expected. If it doesn't this is indicative of either 1) a specific service lacking test coverage, or 2) doing something wrong i.e. directly reading from a microservices' database without going through an API.
- triceratops 1y ago> One of the big tenets of independent services is that your APIs are contracts that don't change behaviour How is that any different from an API in a monolith not changing behavior?
- tuckerman 1y agoYes, I suspect some of the back and forth is the fuzziness of the term "broken build", whether that means the code literally doesn't compile or it does but the code does the wrong thing. I agree that you can prevent merges that cause compilation errors in nearly all cases!