branchless development (2015)
19 points by quobit
19 points by quobit
Trunk based development is a more coherent explanation, although OpenBSD does something a little different. We don’t cherry pick changes from a single trunk to pull back to a release. The release is tagged, and then it’s done.
I think the approach in this article is still just trunk-based development. The original link in this paragraph itself links to https://trunkbaseddevelopment.com/, which defines it as
A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.
That criterion seems to apply here; I would argue that the release strategy is orthogonal to the version control strategy.
I see now that this article was authored in 2015. Most likely
I've worked at a couple of companies where we did branchless development (using a small team who were in constant communication) and it was very productive.
My last company used branches, and merging all those long term development branches at the last minute, just before the major release, was a huge productivity drain and a scheduling risk.
From the title I thought it would be more about managing changes without branches. Maybe I'm missing something but I don't understand how this is different given the motivating example about merging. Commits conflict just as easily as branches. A commit can sit in review (or on someone's computer) just as long as a branch, and have just as much trouble applying on main. I also don't know that anyone wants long lived branches. A statement like:
The solution is to bring all the code together as early and often as possible.
makes sense but isn't really all that actionable, "as possible" is doing a lot of lifting. It's like saying code should as few bugs as possible.
And that's also assuming that changes are uncontroversial: usually when there's a long running branch in an open source project, it's because it's not ready to be merged.
The "key" thing that's missing with branchless development is that you must break down feature development into a series of small, frequent commits that can land on the main branch. These commits go through all usual testing, are merged early when the chances of conflicts are low, and if they do anything wrong, are easy to revert. If you keep just one huge commit in your computer for months, yes, that's no different than a branch.
The thing is that knowing how to break the implementation of a feature into a sequence of small commits is pretty much a learned art. I often see leadership pushing for "we need people to split their work in small changes!" and, well, without concrete advice or training, most folks just don't know what to do. A consequence of such a push is that I've seen developers split their commits in "header files first", then one C file at a time, then tests... but that's counterproductive.
I don't know exactly how to teach people this skill, but what doesn't work is asking someone after they have implemented a huge PR to break it apart in chunks. What works slightly better is trying to come up with a "list of changes" that the developer must perform upfront, in the design doc that they theoretically write, but that still is too high-level and too difficult to do before starting to code. So I wonder if anyone has suggestions?
Some rules of thumb that I think are generally good:
Assuming you do those things, make your change as easy to review as possible. Sometimes this means make it as small as possible but not always -- it could mean putting two or three related pieces together in a change in order that the full context is available to the reviewer.
I think this goes to the "branch less" (not "branchless") comment.
Development is inevitably a distributed system once you have multiple devs who aren't all pairing/mobbing in one group. The changes I make on my local machine are not immediately serialized with the changes you make on yours.
The only question is scope: how long am I building in isolation from you? The trunk based answer is along the lines of roughly "a few hours, maybe a day, nothing more."
How do code reviews work in branchless development?
You can review the code periodically. Think, wake up in the morning, check what was pushed yesterday, then start making changes. Or, you can review once before every deployment (meaning you have to review everything that happened until then). Basically, you treat every commit/push as it's own merge if you want so.
For software with periodic releases, that’s fine. When every pushed commit goes straight to production I think “maybe let’s not do that”.
That’s assuming you have customers that value stability more than your ability to pivot fast towards what they really want. If you’re a startup at an early stage, do whatever lets you iterate quickly until breakages is becoming more of a liability than the speed boost.
I’m not an expert on this flow, but I suspect (particularly if you don’t have commit rights) you send patches to a mailing list. Then a committer will apply them, if they’re not ignored forever.
I don't think that was the intent of the author. That's basically just PRs without tooling.
Tools like jj making rebasing way easier makes me think we can get closer to all of these advantages by getting people to rebase "everything" way more often.
I still fail to undrestand how you can work in this environment in any situation where work you do takes over 24 hours. Where does WIP work go?
Where does WIP work go?
You simply throw it out if you couldn't finish it in a day. You should instead work on tooling, libraries etc. which will let you implement the change in 4-8 hours!
I'm not against branches though if I were to setup things from scratch I'd integrate on main where anybody could push to it and then a merge queue vets the change to throw it out if it doesn't pass.
In our current setup we have a monorepo so most changes that people make don't interfere with each other anyway, branches are short lived and used for CI and some reviewing, on merge the entire branch is squashed onto main. It's not that bad.