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
Second diagram, yes absolutely.
Short lived (1-2 day) branches, and a strong CI systems to catch regressions.
Be warned, the strength in the CI lies in its capacity to detect when some functionality that previously worked doesn’t work anymore. So, the flow must be green always, and it must evolve as the features evolve. Without good CI you’re destined for failure.
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.
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 ^^
Most likely CD is intended to mean continuous delivery, which commonly means automation in processes that deliver your software to it’s target audience.
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.
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.
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.
Seems to work fine. I think this is different than trunk based development but honestly I’m not sure I understand trunk.
Same. But it feels like you’re doing it.
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.
