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.
lies in its* capacity
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.
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 ^^
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.
