Trunk-Based Development

Not that it makes a ton of difference, but technically trunk-based development refers more to the branching model, while continuous integration is a larger concept combining specific tooling, methods, branching, etc. You can do continuous integration with other branching models[1].

Unless a team tries hard to stick to strict CI, they usually end up with long-lived feature branches, long integration cycles, and clumsy, irregular deployments to irregular environments. So many teams still don't "get" CI, and end up wasting a shitload of time.

[1] https://www.martinfowler.com/articles/continuousIntegration....

Never mind the content marketing of the "article". Use whatever tool you want to. If all you have is `if env==dev|staging`, that's enough, no need for "Bucket" or whatever. In general terms though:

If you build your feature without wiring it up to the UI it means that you never integrate until the last moment. That way, you can't actually test a user interaction in an actually integrated fashion.

This is really bad, because you will find all the integration problems at the very last moment. Basically when you're about to give it to your customers.

Feature flagging combats that. It allows you to test the entire solution from the point of an actual customer, without exposing it to an actual customer.

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.

> Version control is designed for the exact problem of having multiple implementations exist and merging them as needed.

This is a common misconception! The primary purpose of version control is to answer discovery requests when the lawyers come knocking. :)

(I'm only half joking here. I do think VCS merges are generally not a good idea, for technical reasons like criss-cross merges being an issue.)

> Why roll your own obtuse version control

This is exactly it. Feature flags sounds really good until one realizes that they have all the requirements of a version control. So much that it was even a running joke at Uber that one starts building feature flag and ends up with a version control.

The cruft of feature flag also makes it really hard to understand while reading a code, there’s a combinatorial explosion.

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

As someone who uses this model with git, the main reason is because git is ubiquitous but I cannot get used to git's incredibly user unfriendly API. I've tried the feature branch approach and it doesn't click for me. Merge conflicts, lost changes, and git reset everywhere.

So in other words, I'm using this model because if I could use perforce I probably would, but git is everywhere.

Also, every time I bring up git's user unfriendliness, I'm always told it's not that hard and I'm holding it wrong. I'm sure I am now too, I just don't care.

I have worked with trunk based development aka everyone just pushing change lists to perforce. I much prefer people making pull requests because I can make sure people fix things in code review before it gets merged to master.

I do absolutely hate however when someone works for 3 months on a mega PR and drops a +8000 -5000 on my head.

Ultimately both systems can work and both can suck.

TBD has merge requests. It lacks all the weird branches like hotfixes and goes back to a simpler set of branches. But MRs are still there. The author of the post is confused or is trolling on purpose of selling his tool. That is very dishonest.