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

51–60 of 210 posts

Re: Trunk-Based Development

#51

Post by notarealdoctor »

nhumrich wrote: post #3
hashkb wrote: post #2

The suggestion that feature branches hinder CD is just untrue, at least in my experience. To me, this seems like a silly restriction to put on such a critical tool (the scm) which is designed to support unlimited flexibility.

You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…

> CD means every commit gets built and delivered all the way prod if it passes all tests.

I always wondered why a company would allow code to go straight to production, live, affecting customers, without a human giving the OK to release.

Re: Trunk-Based Development

#52

Post by nhumrich »

hamandcheese wrote: post #47
nhumrich wrote: post #3

Earlier quoted context omitted.

You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…

How does code review fit in to such a workflow? That's also a manual step, but one I and many others consider good and necessary.

According to the article, and my personal experience, you don't commit directly to trunk. Trunk based means that you don't "collaborate" on a branch. So you write your code based off of trunk, once it's ready you commit in a branch, simply for purpose of code review. It gets reviewed, and probably runs an automated build. Once both pass, you merge and it goes through your deployment pipeline. Yes the merge/code review are manual, but your not merging to say, "I'm ready for this feature to be on prod now" your simply saying it looks good. The biggest difference is that if developer B wants to use your new method, he has to wait for it to be on trunk rather than branching off of your branch, etc.

Re: Trunk-Based Development

#53

Post by joneholland »

nhumrich wrote: post #23
joneholland wrote: post #11

Earlier quoted context omitted.

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.

I agree, which is also why I think monorepos are an anti pattern.

Re: Trunk-Based Development

#54

Post by notarealdoctor »

hashkb wrote: post #24
nhumrich wrote: post #18

Earlier quoted context omitted.

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.

Rebase is evil.

Re: Trunk-Based Development

#55

Post by notarealdoctor »

whyileft wrote: post #42

If you need to hide feature work behind a flag on prod you're probably doing it wrong. There are a few times when you need to, but features can in most cases be written in a way that they can live inside production before complete. And learning to work like that also has the benefit of aggressively fighting features that drag on forever. There are definitely exceptions, but 9 times out of 10 learning to develop featu…

> There are a few times when you need to, but features can in most cases be written in a way that they can live inside production before complete.

That should never, ever, ever be done.

Re: Trunk-Based Development

#56

Post by jessaustin »

nhumrich wrote: post #46
jessaustin wrote: post #36

Earlier quoted context omitted.

So write the tests first; isn't that what we're supposed to do anyway? That way the branch doesn't move to prod on commit, because it isn't passing the tests yet. BTW "commit" is also a "manual step".

I'm kind of lost by your comment. > Write tests first What does this have to do with TBD vs branch based? Should be that way either way. In fact TBD breaks down if you don't write your tests. > A branch doesn't move to prod on a commit Are you saying your shipping branches to prod regardless as to if it's on trunk or not? Or perhaps your whole comment is just saying how TBD is supposed to work and your agreeing with…

Ah, never mind, I was confused.

Re: Trunk-Based Development

#57

Post by nhumrich »

notarealdoctor wrote: post #55
whyileft wrote: post #42

If you need to hide feature work behind a flag on prod you're probably doing it wrong. There are a few times when you need to, but features can in most cases be written in a way that they can live inside production before complete. And learning to work like that also has the benefit of aggressively fighting features that drag on forever. There are definitely exceptions, but 9 times out of 10 learning to develop featu…

> There are a few times when you need to, but features can in most cases be written in a way that they can live inside production before complete. That should never, ever, ever be done.

Why not? Loads of companies do this. Almost all the big ones I know of do this.

Re: Trunk-Based Development

#58

Post by hamandcheese »

nhumrich wrote: post #23
joneholland wrote: post #11

Earlier quoted context omitted.

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.

Wouldn't you have the same problem with trunk though? If you commit at the same time as someone else, and they push their changes first, then you'll have to resolve any conflicts before you push.

It seems that trunk based development is merely a means of enforcing extremely short lived "branches".

Re: Trunk-Based Development

#59

Post by nhumrich »

whyileft wrote: post #42

If you need to hide feature work behind a flag on prod you're probably doing it wrong. There are a few times when you need to, but features can in most cases be written in a way that they can live inside production before complete. And learning to work like that also has the benefit of aggressively fighting features that drag on forever. There are definitely exceptions, but 9 times out of 10 learning to develop featu…

I would say for backend you can get away without feature flags most of the time. But for the frontend, it's almost impossible to ship a new incomplete feature without feature flags

Re: Trunk-Based Development

#60

Post by hamandcheese »

joneholland wrote: post #53
nhumrich wrote: post #23

Earlier quoted context omitted.

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.

I agree, which is also why I think monorepos are an anti pattern.

If two teams are working on two parts of an app that could be in different repos then they would have no conflicts while in a monorepo.
Post reply on HN