Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trunk-Based Development

trunkbaseddevelopment.com

Post reply on HN
Print view View original

21–30 of 210 posts

Re: Trunk-Based Development

#21

Post by geocar »

perlgeek wrote: post #13
geocar wrote: post #7

Earlier quoted context omitted.

CD is not impossible with feature branches. My live system looks up the branch name in the URL or in a (signed) cookie and checks out the appropriate branch then and there . This is possible because my development system is integrated into my live system.

If push to two feature branches, A and B, which one lands in production? both? if so, how? or the last one you pushed? Or the one that finished its build later?

My specific implementation uses the git commit id. Only the tool for signing cookies actually knows about branches.

Re: Trunk-Based Development

#22

Post by vemv »

> Trunk Based Development is a key enabler of Continuous Integration, and by extension Continuous Delivery.

Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now.

Trunk-based development seems to rely heavily on feature flags, which are a huge source of complexity and inconsistency. Even when useful, they're liabilities; not assets.

git-flow (and variations) is simple, enables consistent codebase state, makes no assumptions about your codebase/infrastructure, and allows you to know the exact state of production/staging.

Finally, as it happens so often with open source projects and initiatives, first thing I should see is a big "Why". Why do I want this? Why are the alternatives inferior?

Re: Trunk-Based Development

#23

Post by nhumrich »

joneholland wrote: post #11
nhumrich wrote: post #9

Earlier quoted context omitted.

Who are your two poster children? Because in my mind it's Amazon and Google, who both use git

In the article it was google (perforce) and Facebook (mercurial with hacks). Both are massive mono repos. At Amazon they were mostly perforce when I was there. Granted that was a few years back.

I would say the bigger the repo becomes (in terms of # of collaborators) the more important trunk based becomes regardless of SCM choice. Mainly because merging many branches for many teams becomes very tedious and hairy. By the time you resolve all the merge conflicts, someone else will commit a merge and you'll have to resolve conflicts all over again.

Re: Trunk-Based Development

#24

Post by hashkb »

nhumrich wrote: post #18
hashkb wrote: post #14

Earlier quoted context omitted.

Yes, this is what I think of as CD. Hiding work that isn't ready (or work that may never make it in front of users) behind a flag on prod sounds like extra work for no gain, to me.

The gain is early integration. If you have more than one branch going on at the same time, they can diverge quite significantly, and merging can cause bugs, or sometimes more work. If you only ever have one feature branch at a time, you might as well be doing trunk based with manual deploys to prod.

Rebase early and often and this isn't an issue. Some see this as a chore, but I view it as taking advantage of the tool's power. You resolve the same set of conflicts as you would merging, but (as you say) earlier.

Edit: I don't think anyone was trying to imply a single allowed feature branch at a time; we can probably all easily agree that's basically no different than working on master.

Re: Trunk-Based Development

#25

Post by geocar »

nhumrich wrote: post #12
geocar wrote: post #7

Earlier quoted context omitted.

CD is not impossible with feature branches. My live system looks up the branch name in the URL or in a (signed) cookie and checks out the appropriate branch then and there . This is possible because my development system is integrated into my live system.

So your delivering all commits on all branches to prod? That sounds hairy

How many commits do you do in a day?

The hardest part is figuring out how to do this without a map.

Re: Trunk-Based Development

#26

Post by nhumrich »

hashkb wrote: post #20
nhumrich wrote: post #16

Earlier quoted context omitted.

By "short lived", how short lived? Is the branch only for one developer? Or is it shared? How do you enforce "short lived"? If the branches are not collaborated on, you might be doing trunk based without realizing it.

>you might be doing trunk based without realizing it. Then trunk based is poorly named and apt to start a fruitless holy war. Nobody wants too many people on a feature branch, or for one to live too long. (But it happens, like rebranding an entire app or rewriting all the auth code, which is a good thing to be able to do. ) Is there a threshold of time/collaboration that makes it not-CD?

My point is that the article says that branches for the purpose of WIP and code review is OK as long as you don't share the branches. Trunk based is trunk "based" as in your git "base". Your based on trunk, not a branch. It's not called "commit directly to trunk only" development.

Re: Trunk-Based Development

#28

Post by detaro »

joneholland wrote: post #4

Trunk based development works well on any scm that sucks at branching. Perforce, subversion etc. But, on git, using GitHub-Flow is far superior. The two poster children for TBD do not use git. Don't cargo cult their process without understanding the unique problems they have that you don't. Edit: downvotes on HN? This isn't Reddit, and I'm advocating github flow, not git flow. GitHub flow is trunk based development b…

From the page:

Depending on the team size, and the rate of commits, very short lived feature/task branches are used for code-review and build checking (CI) to happen before commits land in the trunk for other developers to depend on. This allows and engage in eager and continuous code review of contributions before they land in the trunk.

This sounds roughly like what you are advocating.

The resources about GitHub-flow that I've seen don't put emphasis on the lifetime of branches, only on them being finished at some time, with the completion of a feature, and being deployed immediately after being reviewed.

Re: Trunk-Based Development

#29

Post by hashkb »

vemv wrote: post #22

> Trunk Based Development is a key enabler of Continuous Integration, and by extension Continuous Delivery. Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now. Trunk-based development seems to rely heavily on feature flags, which are a huge source of complexity and inconsistency. Even whe…

I'm on your side but my comment (yours is better) faced opposition so:

They redefine CD and then say nothing else is it, and you aren't doing it.

Re: Trunk-Based Development

#30

Post by kyrra »

joneholland wrote: post #11
nhumrich wrote: post #9

Earlier quoted context omitted.

Who are your two poster children? Because in my mind it's Amazon and Google, who both use git

In the article it was google (perforce) and Facebook (mercurial with hacks). Both are massive mono repos. At Amazon they were mostly perforce when I was there. Granted that was a few years back.

Google doesn't use perforce anymore. They have a custom in-house SCM that has various interfaces wrapped around it. I'd recommend this video that describes it.

https://m.youtube.com/watch?v=W71BTkUbdqE

Post reply on HN