Hacker News Reader

Comment by IgorPartola | Hacker News Reader

So there are projects where I don't branch: ones where I am the only committer, and there are no features. For example, my puppet manifests for all the servers I manage. It either works, or I roll it back.

However, feature branches are just multi-stage commits. Sure you can invest hours of your life setting up CI, then writing code, not testing it locally before pushing it to master, getting an obscure error from the test/deploy process, fixing it again, pushing again, getting another error, etc. But you probably want to, you know, ship the product.

Having said that, if your workflow actually resulted in you writing better code faster and you ended up shipping earlier and making more money, I'd love to read about it.

View on HN

"Sure you can invest hours of your life setting up CI, then writing code, not testing it locally[...]"

Maybe I've misunderstood, but why aren't you testing it locally? With trunk based development you make your changes, run a local build and push if it passes. Everyone (including any CI servers) runs the same build process.

The trick is that you have to be able to push to master without breaking it, which is scary to many developers and usually requires a shift in thinking. How do I do large refactorings? (you don't - do many small refactorings instead). How do I add a half-finished feature? (break the feature into many smaller features, use feature toggles, etc.)

Of course. And this relies on your CI system having 100% unit and system test coverage, including testing external API's, CSS bugs, browser compatibility, etc. Are you certain that your system does that? More importantly, are you certain that investing the time into testing that your checkout button is not covered up by some random element due to a missing ";" character in your CSS file or a missing 0 in the width percentage value will eventually pay off? It should be scary to push to master if you hold master to be deployable at all times. Unit/system testing or not, you will never have guaranteed test coverage, and even if you try to get to it, you will spend infinitely more time doing that, than doing a reasonable amount of unit/system automated testing + good human QA.

That's really a function of your QA process, not anything specific to branching strategies. If you can automate everything such that continuous delivery (or even deployment) is possible - great. If not, deliver at whatever pace your QA allows (and strive to increase that pace). Trunk based development does not imply a diminished QA process.

Yes, there is always going to be a feedback delay between you making a change and the full impact of that change being known (even if your feature is bug free, will the customer want to use it?), but we should be bringing that feedback forward by moving changes through the pipeline as early as possible. Feature branching delays feedback, which is why I reject it.

Both Google and Facebook use trunk-based development. If Google can get away with a single trunk and 15,000 or so committers, chances are your organization can too.

The reason for trunk-based development over feature branches is that the time required to integrate a patch usually increases proportional to the square of the time since last integration. With trunk-based development, most commits reflect about 1-2 days worth of work, and they go in with minimal conflicts. Branches (and patches that sit idle for a month or two) often take forever to integrate, because as you are trying to update your code to the new master, the master is itself changing. At some point, the process doesn't converge, and you can spend forever trying to update a branch.

Reply on news.ycombinator.com