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....

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.

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.

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 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.)

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 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.

> In practice, many teams will use a pull request-based workflow because the tests could be too complicated to run locally or need to facilitate code reviews. For trunk-based development to fulfill its promise, it’s imperative that pull requests are kept small and that the team is committed to reviewing them quickly.