4 ms·

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

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 literal copies of all the files for multiple years. I don't think revision control is the right place to solve that problem though, because there were no clear service boundaries to decide what things to pin, we just did it in an adhoc way.

ec109685 3y ago
How did the hold back end up working out? Was the learning worth the hassle?
- mgraczyk 3y ago
  Yes for sure. In some sense, I learned more from these holdouts than from anything else I've ever done in my career.
Scubabear68 3y ago
I am amazed at how much “process” developers these days have to adhere to, including complicated branching strategies plus a whole lot more. So much time wasted doing busy work. I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.
- dboreham 3y ago
  Imho this is an emergent property from the fact that most folks don't understand what they're doing. If they did, then every time Mr Dilbert pointy head dude comes up with some nonsense process, they'd explain why it isn't beneficial. Instead most of the time everyone nods. Lawyers don't have crazy people telling them how to write contracts. Doctors don't have people telling them how to saw off legs. Teachers kind of do have dumb people telling them how to teach though.
  - withinboredom 3y ago
    That’s because the kids have parents who are developers… /s
  - tnecniv 3y ago
    Lawyers do. My dad is winding down his legal career but the bulk of it was spent writing corporate loan contracts. He’d constantly have clients asking him to make “small changes” to the document that either made no sense or were, in fact, large changes that would rob him of his weekend. While his specialty was niche, it was not so niche that appeasing the client for their future business was not important. His clients drove him crazy with this stuff but at least he could bill those hours. I know less about doctors, but they certainly have people that think they know better and question their course of treatment. Just look at the pandemic and vaccine nonsense. Doctors benefit from supply and demand (artificial or otherwise) meaning that they’re basically always booked up. Developers have neither of those privileges unless you’re an in demand consultant.
andix 3y ago
If Google and Facebook are doing it, then we need to start doing exactly the same! /s
- gipp 3y ago
  I think their point is more that the usable scale of teams/codebases is not limited by trunk based development. Which that is pretty ample evidence of.
  - andix 3y ago
    I get that. But aren't we all struggling with complex branching strategies and microservices, because someone told us "that's how Facebook/Google is doing it!"? :D
    - mgraczyk 3y ago
      Probably not, because neither of them have complex branching strategies
seattle_spring 3y ago
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.
- mixmastamyk 3y ago
  Sounds like BS, the two are orthogonal. Would help if you had a link.
  - seattle_spring 3y ago
    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.
- Kinrany 3y ago
  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.
- cassianoleal 3y ago
  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/ https://trunkbaseddevelopment.com/contributions/

ec109685 3y ago

How did the hold back end up working out? Was the learning worth the hassle?

mgraczyk 3y ago
Yes for sure. In some sense, I learned more from these holdouts than from anything else I've ever done in my career.

Scubabear68 3y ago

I am amazed at how much “process” developers these days have to adhere to, including complicated branching strategies plus a whole lot more. So much time wasted doing busy work. I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.

dboreham 3y ago
Imho this is an emergent property from the fact that most folks don't understand what they're doing. If they did, then every time Mr Dilbert pointy head dude comes up with some nonsense process, they'd explain why it isn't beneficial. Instead most of the time everyone nods. Lawyers don't have crazy people telling them how to write contracts. Doctors don't have people telling them how to saw off legs. Teachers kind of do have dumb people telling them how to teach though.
- withinboredom 3y ago
  That’s because the kids have parents who are developers… /s
- tnecniv 3y ago
  Lawyers do. My dad is winding down his legal career but the bulk of it was spent writing corporate loan contracts. He’d constantly have clients asking him to make “small changes” to the document that either made no sense or were, in fact, large changes that would rob him of his weekend. While his specialty was niche, it was not so niche that appeasing the client for their future business was not important. His clients drove him crazy with this stuff but at least he could bill those hours. I know less about doctors, but they certainly have people that think they know better and question their course of treatment. Just look at the pandemic and vaccine nonsense. Doctors benefit from supply and demand (artificial or otherwise) meaning that they’re basically always booked up. Developers have neither of those privileges unless you’re an in demand consultant.

andix 3y ago

If Google and Facebook are doing it, then we need to start doing exactly the same! /s

gipp 3y ago
I think their point is more that the usable scale of teams/codebases is not limited by trunk based development. Which that is pretty ample evidence of.
- andix 3y ago
  I get that. But aren't we all struggling with complex branching strategies and microservices, because someone told us "that's how Facebook/Google is doing it!"? :D
  - mgraczyk 3y ago
    Probably not, because neither of them have complex branching strategies

seattle_spring 3y ago

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.

mixmastamyk 3y ago
Sounds like BS, the two are orthogonal. Would help if you had a link.
- seattle_spring 3y ago
  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.
Kinrany 3y ago
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.
cassianoleal 3y ago
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/ https://trunkbaseddevelopment.com/contributions/