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
I guess we do scaled trunk development, if you want to call it that. We do allow direct commits, for trivial or safe stuff where reviews would be more noise and hindrance than value. (Code formatting etc.)
We only have one current release version though. (And at times a current test version that deviates from it.)
If there’s a need to create a patch release for a tagged version when the trunk proceeded forward with something that shall not be included, I create only a temporary branch from the earlier tagged commit to tag (=create) that patch release.
What are the release branches supposed to be in your graphs? It says developers don’t commit. Then who does?
Those aren’t my graphs, there are from the link in the post. I’ve only once worked with release branches and it was a nightmare.
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.
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.
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.
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.
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.
Most likely CD is intended to mean continuous delivery, which commonly means automation in processes that deliver your software to it’s target audience.
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 ^^
