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

61–70 of 108 posts

Re: Trunk-Based Development

#61

Post by andix »

c-hendricks wrote: post #54

I've been pushing and using trunk for years. To think someone looked at the graph for git-flow and said "yes please" is madness. That said, trunk-based is probably not great if you actually do need to support multiple versions of a piece of software simultaneously.

I'm not sure if any branching strategy helps supporting multiple software versions simultaneously. There is a reason why "rolling releases" are the default now.

For a short while it may work to just merge bugfixes to older versions. But after a while the changes to older versions need to be done independently. Implementing a fix for three versions will just take three times longer than for one version very soon.

Re: Trunk-Based Development

#62

Post by andix »

AdrianB1 wrote: post #60

How does this look like when you have multiple active versions of an application? In some cases there are apps deployed in different environments (or to different clients) in different versions and having a single place to make all commits is not feasible. How do things that have LTS versions in parallel with "regular" versions organize?

How I've done it: Just tag the commit that is used to build a release. If you need to add a fix to an older release, create a branch from the tag. Do the changes trunk based on this branch, then tag and release. If needed just repeat it.

I'm convinced that complex branching strategies never magically solve any issues. They just confuse many people until every successful release feels like dark magic.

Re: Trunk-Based Development

#63

Post by andix »

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…

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

Re: Trunk-Based Development

#64

Post by AdrianB1 »

andix wrote: post #62
AdrianB1 wrote: post #60

How does this look like when you have multiple active versions of an application? In some cases there are apps deployed in different environments (or to different clients) in different versions and having a single place to make all commits is not feasible. How do things that have LTS versions in parallel with "regular" versions organize?

How I've done it: Just tag the commit that is used to build a release. If you need to add a fix to an older release, create a branch from the tag. Do the changes trunk based on this branch, then tag and release. If needed just repeat it. I'm convinced that complex branching strategies never magically solve any issues. They just confuse many people until every successful release feels like dark magic.

Why not keep a permanent, separate branch for each version that is still maintained? And do trunk on each version branch.

Re: Trunk-Based Development

#65

Post by purerandomness »

giancarlostoro wrote: post #51
andix wrote: post #47

Earlier quoted context omitted.

I think you're mixing up a lot of things. Trunk-based development also doesn't mean that you are not allowed to create branches. And you can still check out an older version.

They deleted every branch on merge, and had us rebase for merges. Before trunk based development was introduced, everyone on the team understood what the flow was. Afterwards, whichever developer was picked to cut a release, took half a day to figure it out to make sure they didn't screw up. I would have rather just used SVN and called it a day.

> They deleted every branch on merge

Wait, this doesn't sound like trunk-based development.

This sounds like a traditional branch-based workflow.

> to cut a release, took half a day to figure it out to make sure they didn't screw up.

Do you remember what was making the process complicated?

In trunk-based development, you ideally can tag a release wherever you're at. Your trunk is always stable and releasable. If it's not, you fix it and then release.

Re: Trunk-Based Development

#66

Post by andix »

AdrianB1 wrote: post #64
andix wrote: post #62

Earlier quoted context omitted.

How I've done it: Just tag the commit that is used to build a release. If you need to add a fix to an older release, create a branch from the tag. Do the changes trunk based on this branch, then tag and release. If needed just repeat it. I'm convinced that complex branching strategies never magically solve any issues. They just confuse many people until every successful release feels like dark magic.

Why not keep a permanent, separate branch for each version that is still maintained? And do trunk on each version branch.

I don't like long lived branches. For me a branch is work in progress. Work should be finished, once finished the branch should be deleted. If you start work again, create a new branch.

But sure, if supporting an older release is some kind of ongoing trunk-based process this is also a viable solution.

Re: Trunk-Based Development

#67

Post by gipp »

andix wrote: post #63
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…

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

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.

Re: Trunk-Based Development

#68

Post by ramraj07 »

Flux159 wrote: post #7

I think that good tooling is a necessity to do trunk based development well - not just CI/CD and testing on PRs, but also being able to have stacks of commits in multiple PRs before landing as a whole (from ghstack, Sapling, or Graphite). Having worked at Facebook before where managing stacks of diffs was far better than GitHub, I wish that more of the improvements to the developer workflow could be open sourced beyo…

Which of those three tools works best on GitHub? Ideally without paying (not that I mind paying but it’s impossible to get the approval for some niche tool like this)

Re: Trunk-Based Development

#69

Post by andix »

gipp wrote: post #67
andix wrote: post #63

Earlier quoted context omitted.

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

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.

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

Re: Trunk-Based Development

#70

Post by andix »

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.

Whenever I even mention doing trunk-based people look at me like I'm an idiot and have no idea about anything.

Same if I say "I'm not doing TDD, because I think it's bad". I've seen so many people claiming to do TDD, but none of them ever actually did.

Post reply on HN