Trunk-Based Development
trunkbaseddevelopment.com
Trunk-Based Development
1–10 of 108 posts
Re: Trunk-Based Development
#2Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
Re: Trunk-Based Development
#3Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
Re: Trunk-Based Development
#4Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
I think the idea is that, rather than storing two versions of the code in your version control system, you store both versions in trunk and gate with a feature flag.
Re: Trunk-Based Development
#5Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
Or put the sha in the version number.
Re: Trunk-Based Development
#6Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
So if the “deployed branch” were really just a “tag”, that would fit trunk based development? Because that’s basically what git is doing. It’s not like there are two sets of files anywhere, afaik.
My understanding of this though is that there isn’t supposed to be a difference between “what we’re working on” and “what’s deployed”, which I think then means you don’t really do “long term” development.
Re: Trunk-Based Development
#7I 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 beyond Sapling now that Phabricator is no longer supported.
Re: Trunk-Based Development
#8There is no “right” or “best” way to do this job, right? But kudos for taking a position and articulating it.
Re: Trunk-Based Development
#9Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
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.
Re: Trunk-Based Development
#10Google 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.