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.
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.
I haven’t worked on any teams where all members committed “every 24 hours”, and there have always been some branches that live longer than we’d like (usually just unfinished work that got deprioritized but still kept as an eventual “todo”), but most teams I’ve worked on have indeed followed the basic pattern of only one long-lived branch, reviews and CI required prior to merge, and all feature-branches being short-lived.
A hard timeline on commit strikes me as less than ideal.
People are people. They have issues, they screw up, but they still write good code.
Seems like a brutal metric that encourages minimal commits without real change.
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.
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.