Trunk-Based Development
bucket.co
Trunk-Based Development
1–10 of 47 posts
Re: Trunk-Based Development
#2> 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
Why aren’t you using feature flags to gate new behavior/functionality?
Re: Trunk-Based Development
#3I’m gonna be honest, this sounds horrible. If you do adopt this though, why even use Git? Why not use Perforce or something?
Re: Trunk-Based Development
#4I 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?
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).
Re: Trunk-Based Development
#5> 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 Why aren’t you using feature flags to gate new behavior/functionality?
This is literally what the article advocates.
It pushes things to the extreme where every code you write would be on the main branch and behind a feature flag
Re: Trunk-Based Development
#6I'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.
Re: Trunk-Based Development
#7> 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 Why aren’t you using feature flags to gate new behavior/functionality?
This is literally what the article advocates. It pushes things to the extreme where every code you write would be on the main branch and behind a feature flag
Feature flags have nothing to do with trunk or git-flow or feature branches. Simply, taking the entire introduction and asking, why are you not using common tooling?
Re: Trunk-Based Development
#8This 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.)
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.
Re: Trunk-Based Development
#9Earlier quoted context omitted.
This is literally what the article advocates. It pushes things to the extreme where every code you write would be on the main branch and behind a feature flag
Feature flags have nothing to do with trunk or git-flow or feature branches. Simply, taking the entire introduction and asking, why are you not using common tooling?
It’s an advertisement for a feature flagging tool. I think you may have missed that.
Re: Trunk-Based Development
#10I 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…
So, I am not doing big development with hundreds / thousands engineers for quite some time. So I started to have sympathy to the other side of the story. The problem with feature branches, especially for frontend development, is that it is never just a "feature" (otherwise, you can gate it compile-time by just compiling out that feature module completely, or in nodejs terminology, treeshaking?).
It is a combination of some new UIs, some updates to some interfaces, some new capabilities to a new middleware and some new APIs to call backend. And you don't want to gate these behind a feature flag. And merging these into main branch while make sure when multiple person working on a feature branch know what commits they did on feature branch is in main branch and why a merge from main branch would just absorb these commits are tiring.
In these cases, trunk based development is really working for cases that not every developer is a git guru and can just navigate the merge back forth from main branch to feature branch and back. Yes, for these, subversion / perforce makes more sense, but everyone who is not git guru is still on git.
That coupled with inefficiencies of your CI system only runs on main branch and needs manual adjustment to run on a feature branch every time, it is easier to do it on the trunk.
Every problem is a tools problem, and people picks least resistance to make tools do what they want. There is no right or wrong, pick your poison wisely.