This is content marketing for a feature flagging tool called “Bucket.” I’m a big fan of trunk-based development, although I prefer its original name: continuous integration. (Sadly, that name has been coopted by tool vendors.)<p>A better alternative to feature flags is keystone interfaces. It’s very simple: build your new feature without wiring it up to the UI (or API). Test it using automated tests that bypass the UI. When it’s ready, wire it up, manually confirm that the automated tests didn’t miss anything, and release.
I am strongly opposed to feature flags and conditionals in the code, unless absolutely necessary. If you don't remove deprecated features/branches, your code will end up unmaintainable. If you do remove them, the removal is (in my experience) worse than dealing with merge conflicts. Version control is designed for the exact problem of having multiple implementations exist and merging them as needed. Why roll your own obtuse version control by having all branches in the same file simultaneously when you can just use git to have them exist in parallel universes?<p>There's value in putting a newly completed feature behind a feature flag so you can turn it off instantly in prod. There is much less value in putting dozens of not-yet-functional features behind feature flags that shouldn't be turned on for the next several weeks/months (or maybe never).
> On top of that, once you finally get a feature merged and deployed, it can often happen that there’s a bug causing users to have a poor experience. Since your new feature lives directly in the code, deactivating it requires rolling back the code you merged, building it, waiting for the tests to run, and redeploying the application<p>Why aren’t you using feature flags to gate new behavior/functionality?
Everything old is new again:<p>> Flickr is somewhat unique in that it uses a code repository with no branches; everything is checked into head, and head is pushed to production several times a day. This works well for bug fixes that we want to go out immediately, but presents a problem when we’re working on a new feature that takes several months to complete. How do we solve that problem? With flags and flippers!<p><a href="https://code.flickr.net/2009/12/02/flipping-out/" rel="nofollow">https://code.flickr.net/2009/12/02/flipping-out/</a>
> Trunk-based development is the seemingly radical idea of a team working together on the same code base at the same time.<p>Seemingly radical, hm. I've never worked any other way in 20+ years.
Every time this comes up it feels like two groups of people meet where one group either thought the other didn't exist or was much smaller than it really is. It's bizarre.
Here is an article of how my team had accomplished this with GitHub actions I posted earlier: <a href="https://blog.gregweber.info/blog/github-actions-trunk-based-development/" rel="nofollow">https://blog.gregweber.info/blog/github-actions-trunk-based-...</a>
I'd be interested to hear from anyone with substantial experience of trunk-based development who prefers a merge workflow, and can articulate why. Comments on TBD posts are usually either TBD enthusiasts, or people who have never used TBD and think it sounds stupid.
It is really sad that almost no modern code review tools support trunk-based development. Nearly all tools assume some kind of branching/pull request.<p>One tool that was great for _both_ use cases was Jetbrains Upsource, where you could just string a bunch of related commits together in one review. Better yet, it could recognize based on the commit message (like workitem or CR number) that a commit belongs to the same code review and add it.<p>We actually still use it, even though Jetbrains canned it, because we have found no good alternative. Some of the tools that do code review mandate to also host the code within it, which is not an option because we already host the code in a system we’re happy with.
After thinking about this for some time and weighing in with my 30 years of developer experience: don't do this. You will suffer.<p>Branches are there for a reason, and they are light-weight enough that you can use them even in a solo project. Everything will be easier if you flow with the tool instead of trying to fight it like this.
This looks horrible IMHO.<p>I agree changes to main should be kept small. But not too small. They should be coherent 'chunks' of functionality, even if they are not yet a fully working feature.<p>Committing to a dedicated separate branch, quite apart from protecting against fat-finger commits etc, keeps everything together, allows for easy code review of a complete, coherent change, etc.