[dead]
Trunk-Based Development
21–30 of 47 posts
Re: Trunk-Based Development
#22I'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.
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.
> I do absolutely hate however when someone works for 3 months on a mega PR and drops a +8000 -5000 on my head.
Trunk based workflow doesn't prevent that.
Moreover, heavy refactoring of code often ends up doing the same thing but much quicker.
Re: Trunk-Based Development
#23This 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.…
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…
The article you referenced specifically says that “trunk-based development” is a synonym for “continuous integration.” Please see the section titled “What is the difference between continuous integration and trunk-based development?”
Re: Trunk-Based Development
#24It's things like this that make me fear we may have reached peak dev.
Re: Trunk-Based Development
#25I’m gonna be honest, this sounds horrible. If you do adopt this though, why even use Git? Why not use Perforce or something?
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.
Re: Trunk-Based Development
#26[dead]
Re: Trunk-Based Development
#27Earlier quoted context omitted.
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…
The article you referenced specifically says that “trunk-based development” is a synonym for “continuous integration.” Please see the section titled “What is the difference between continuous integration and trunk-based development?”
That's a nice bit of history, but that is no longer common usage. Terminology has a life of its own, it isn't owned by those who first use it.
Re: Trunk-Based Development
#28This 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.…
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.
Re: Trunk-Based Development
#29I wonder how you code review a half implement feature.
Re: Trunk-Based Development
#30I'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.
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.