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

91–100 of 108 posts

Re: Trunk-Based Development

#91

Post by seattle_spring »

mgraczyk wrote: post #10

Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained l…

Someone on HN loudly proclaimed that requiring a code review before merging was antithetical to "trunk based development." He shared the link in OP a dozen times as "proof", but I couldn't find anything in there suggesting such a thing. I also know both Google and FB require code reviews.

Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-merge reviews.

Re: Trunk-Based Development

#93

Post by mixmastamyk »

seattle_spring wrote: post #91
mgraczyk wrote: post #10

Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained l…

Someone on HN loudly proclaimed that requiring a code review before merging was antithetical to "trunk based development." He shared the link in OP a dozen times as "proof", but I couldn't find anything in there suggesting such a thing. I also know both Google and FB require code reviews. Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-mer…

Sounds like BS, the two are orthogonal. Would help if you had a link.

Re: Trunk-Based Development

#94

Post by mixmastamyk »

Anticlockwise wrote: post #89

This site has developed a lot of content without seeming to directly address the major concerns anyone coming from git flow will have. For example, their code review page does not really address how github and gitlab are both set up to support branch based review, and trunk based review is a lot harder when using those tools. Similarly, I poked around and figured out what they recommend for hotfixes, which is just fi…

Maybe you missed this section?

https://trunkbaseddevelopment.com/#scaled-trunk-based-develo...

Trunk does not prohibit feature branches or code review.

Re: Trunk-Based Development

#96

Post by mixmastamyk »

edgyquant wrote: post #24
sowbug wrote: post #9

Earlier quoted context omitted.

Your local repo is the equivalent of the development branch. Yes, that means you don't collaborate with others on development branches, or go for weeks committing only to a branch. If you save up a bunch of work, dump it on the main branch, then start a new development branch that lets you escape from the integration pain of your big merge, then trunk becomes a dumping ground that nobody wants to (or can) work on.

Seems strange. Sometimes we’ll have feature branches that are made up of different parts, with different devs collaborating to build those parts out. For this I don’t see a way around having some staging branch with two devs sending PRs to before you work out all kinks and merge the staging branch back into main

Have the devs integrate in their own branch(es).

Re: Trunk-Based Development

#97

Post by Kinrany »

seattle_spring wrote: post #91
mgraczyk wrote: post #10

Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained l…

Someone on HN loudly proclaimed that requiring a code review before merging was antithetical to "trunk based development." He shared the link in OP a dozen times as "proof", but I couldn't find anything in there suggesting such a thing. I also know both Google and FB require code reviews. Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-mer…

Post-merge reviews obviously help with the same goal of having very little work stuck in WIP. But it's a 80/20 kind of goal, not all or nothing. Post-merge reviews are probably only worth it when you can trust the developers to not screw up too much and to broadly agree on quality standards.

Re: Trunk-Based Development

#98

Post by doobeewoo »

giancarlostoro wrote: post #42
pard68 wrote: post #22

I work at a place that has a few very large code bases, we use trunk-based. I will never go back, "what is your git workflow?" Is a question on my list of things to ask potential employers now and the only good answer is "trunk". So much mental load is wasted on these other strategies.

I'm not really sure what the mental load is but having gone to Trunk felt like a mistake, I don't know if it was just designed wrong at the last place I worked at, but we have to do more than normal per release, and I'm not a fan of squashing commits, it means I can't just go back to a branch and merge the development branch back into it, I have to check out a brand new branch. I also preferred having "master / main"…

If you deploy your main branch on every commit, there is no "development phase". You should deploy more frequently and work on smaller changes. So when your QA (or a user, or a monitoring alert) finds a bug, you are pretty sure that the bug was introduced recently.

Re: Trunk-Based Development

#99

Post by cassianoleal »

seattle_spring wrote: post #91
mgraczyk wrote: post #10

Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained l…

Someone on HN loudly proclaimed that requiring a code review before merging was antithetical to "trunk based development." He shared the link in OP a dozen times as "proof", but I couldn't find anything in there suggesting such a thing. I also know both Google and FB require code reviews. Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-mer…

There didn't use to be any mention of pre-merge reviews in that website. In fact, the text in the website used to be pretty emphatic against any branching whatsoever.

I have known and worked with Steve Smith (the only "friends" mentioned in the website [0] - hi Steve! :D ) for years and we had many discussions about the merits of short-lived branches for peer review. Myself and a few others have argued that you can have pretty much all the benefits they were looking for with TBD without the draconian "always push to trunk" rule. It just takes a bit of discipline and communication, but to be honest I think the draconian one needs even more of those if it is to succeed.

I'm happy that the website has been updated since (it's been at least a few months, maybe even a couple years) to acknowledge and "allow" that strategy.

[0] https://trunkbaseddevelopment.com/contributions/

Re: Trunk-Based Development

#100

Post by seattle_spring »

mixmastamyk wrote: post #93
seattle_spring wrote: post #91

Earlier quoted context omitted.

Someone on HN loudly proclaimed that requiring a code review before merging was antithetical to "trunk based development." He shared the link in OP a dozen times as "proof", but I couldn't find anything in there suggesting such a thing. I also know both Google and FB require code reviews. Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-mer…

Sounds like BS, the two are orthogonal. Would help if you had a link.

I spent quite a while trying to find the post and comments but came up empty. Am kind of hoping the same person will pop up here, as they seemed extremely passionate about pointing it out.
Post reply on HN