Hacker News Reader

Comment by yoz-y | Hacker News Reader

How would this kind of system handle: “your change works but the way you implemented it breaks X Y and future Z, now there are 10 commits on top of it and we have to roll back.” Seems like it would create a code base with a lot of hacks or need constant refactoring.

View on HN

If something breaks with the change, how can you say "your change works"? Either it works and everything works, or it doesn't work, and something/everything else broke. And since it never worked in the first place, it wouldn't be merged to the "ship" branch and therefore never get any commits on top.

In theory yes. In practice, your test suites are not all-encompassing perfect oracles.

Hopefully you are a proper software shop and you do more than just run test suites to see if something is working :)

And if you discover that "hey, changing X broke Y but we didn't catch it before", then obviously you rollback the change and start working towards how you can prevent it in the future.

Of course there will always be fuckups, but this strategy wouldn't make it harder/easier to rollback those changes.

Right, but it removes the opportunity for a second dev to see subtle but catchable issues that are the most likely to get missed in isolated testing by dev/first level QA. Race conditions, improper use of lifecycle hooks, scaling issues, etc.

And good luck getting a SOX auditor to give this process an OK!

Reply on news.ycombinator.com