I’ve heard it thrown around in professional circles and how everybody’s doing it wrong, so… who actually does use it?
For smaller teams
“scaled” trunk based development
Scaled trunk based all year long, every year, every team.
Life is too short to tolerate long-lived branches.
I’ve been doing this for the past 10 years or so. When I joined my current company a few years ago, it was one of the first things I pushed for. It made cycle times go down drastically and value is being delivered to end users at a much higher rate now.
With enough tests and automation, there is almost no reason not do on the web. On embedded or mobile platforms this might be a bit more difficult, although not entirely impossible.
The use of feature toggles also greatly enhanced our trust in being able to turn a feature off again if it turned out to be faulty somehow. Although we usually opt for patching bugs, it gives the business as a whole more confidence.
We have hundred of individual repos and use git flow: short lived feature branches but also long lived develop, master and support branches (for LTS releases).
Scaled absolutely. Works really well. We have a pr ci pipeline. And cd set up on the trunk. Everything is PRed before being merged to the trunk.
Google operates on a trunk model, according to this:
Team of three. We do the feature branches, pull requests and code reviews. With the right culture, it keeps devs informed about the various projects and gives a nice space to discuss about the practice.
EDIT: we do automated linting and formatting checks too. Keeps things coherent.
Here there’s main. You branch off. Do your work. Make a PR to main. Build passes and someone approves, merge to main. Production release is done by tagging main.
The branches are short lived because the units of work we select are small. You have like one pr for an endpoint. You don’t wait until the entire feature with 20 endpoints is ready to merge.
Seems to work fine. I think this is different than trunk based development but honestly I’m not sure I understand trunk.
We do, for two 2-3 person projects, where no code reviews are done. This is mostly because (a) it’s “just” a rewrite and (b) most new functionality is small and well-defined. For bigger features a local branch is checked out and then merged back later. Commits are always up-to-date, which makes it much easier to test integration of new featues.
With git. Every time we start work, we pull. After every commit, we push (and pull/merge/rebase) if necessary.
Wait, you push to main directly? That’s not exactly what “trunk based” means.
Team of one here tends to work on master only for very small stuff.
There’s a branch for the next release which will get merged once everything’s done. Occasionally there are smaller branches that fork off of the release branch and get merged back.
Meanwhile master is, most of the time, an old copy of the new release branch so merging goes without issue. Unless there’s a problem in prod, then it gets fixed in master and backported to the feature branch.
I should use feature toggles more (usually
, sometimesif (config_Flag)), occasionally a big feature creeps in and i know management will change it at least 3 times and 2-3 new releases will come out in between…I do, on a 900+ developer mono repo. Works like a charm.
We just have a CD that allows to deliver each project each micro service individually.
Out of curiosity, how long are CI and CD runs? And are there any particularities in the way of working for example every PR/MR is created by pair programmers, or the use of josh to cut down on time to clone, stuff like that.
If cloning a repo is an issue, you’re using CI wrong. --shallow has it’s purpose.
Anyway, in my project a complete CI run including local integration tests takes about an hour. We could cut that down by running things in parallel, but we never bothered to add more runners.
I would say, if your tests hold you back, you might want to reconsider testing. Staged testing is an option, or just reevaluate whether you really need all those test cases. Many integration tests are not really testing that much, because 95% of them overlap.
You deliver your software on CDs?
Most likely CD is intended to mean continuous delivery, which commonly means automation in processes that deliver your software to it’s target audience.
It does indeed ^^
Holy crap that’s a lot of devs 😳
Yeah, the biggest problem is keeping up to date.
That’s where the mono repo really shines. We have a folder for common stuff that everyone depends upon. A modification is automatically applied/compatible with every micro service. Really streamline the lib updates problem ^^
At my last company, we used the scaled TBD. For personal projects I do the same. It’s honestly really nice. Not having to worry about merging issues between a dev branch and main branch was probably the biggest benefit. The code base also felt more accessible to the team. Cherry-picking a particular commit that a teammate worked on that’s been merged but I needed on my feature/bug branch was also painless.
Only for repos where there are no code reviews or releases. E.g small single developer utilities, configuration repos, etc.
Were there at least tests (where possible) if there were no code reviews?
I’ve been a fan of git-flow for a long time. It makes the master consistently stable and production ready, gives mechanisms for hotfixing, patching, releasing, tagging, and regular feature dev with a running develop branch. This tends to be more stable than Wild West commits into dev direct, since you work on a feature in isolation, and then merge the feature in when it’s ready, and keeps prod in its own lane so there’s no risk of a feature accidentally nuking something.
Doesn’t the “scaled trunk-based development” do that too, with feature branches and merge requests? Trunk is your production-ready branch there.
Not saying anything about good or bad, but trunk-based development doesn’t work when the business requires you to have multiple releases under development concurrently.
I don’t think anything works in that situation.
In TBD, it’s not a “release” until its production ready. The methodology and philosophy doesn’t prevent you from developing multiple feature branches at once or even deploying a work in progress feature branch to a dev environment.
All TBD requires in that case is once the feature branch is production ready, it’s merged to the trunk. You may need to add a feature toggle if there are multiple release like for different architectures. And you also might benefit from using git tags and deploying to production from a git tag instead of the most recent commit on a branch.
Exactly what you need to do is going to depend on the project’s exact needs but TBD is totally possible in that example.
We’ve used the “scaled” approach for a whilen and we make tags to release. Every time we have a long-lived branch that isn’t main/master something gets fucked up or we spend an extra few days just to reconcile the conflicts. Luckily we’re service based so supporting multiple versions of a product is very rare.
