I love TBD. But it has its places. For mobile apps I've used (and would use) release branches. You have a hard requirement on the way that app stores work.
You can still do TBD for most of the development of new features, though.
True but I have seen people claim TBD should be used in all cases and I was trying to get some insights on how people use TBD for mobile apps as using release branches is not TBD as well.
Release branches are fine (mobile apps, sure... web apps, probably not). Again, context is key.
You can still integrate to trunk as one would expect in TBD, no need for the delayed integration in Gitflow.
A common practice I see with mobile teams is they will create a 'release/x.y' branch sourced from trunk as part of their release routine (at some regular cadence, like 2-weeks).
If they need to (surgically) apply a hotfix, they can apply it to the release branch. Since the app store review process makes deploying immediate fixes impossible, a stronger emphasis on staging/RC QA is good as well.
TBD as described here also allows for feature branches (but they must be short lived and owned/worked on by a single developer -- which seems reasonable to me).
I think people are seeing TBD as "no-branches ever" and that is not it's goal or design.
We currently use short-lived feature branches, merged via Pull Requests (+ review / automated testing) into the main development line. This way, we can communicate changes in a detailed manner before they are added to the product and make sure there is no unfished or bad code in the main branch. (The dev team is small, 5-8 devs).
I don't see (yet?), what benefits TBD would provide in such a setup.
Is even easier with a small team to do TBD. Because the amount of integration is reduced the possible need of branches (or their TBD equivalents dark launch/branch by abstraction/feature flags) is greatly reduced. So the branches add ceremony where none is needed.
Though those branches could be needed if you are doing mobile, desktop or library/framework development.
Strong agreement with everything you've said here. I can't say enough good things about trunk-based development. I started managing a team with 15+ developers. They had used long-lived branches, with a develop, a staging, and a release branch. Not using TBD, "releases" were a huge ceremony and extremely inertial. Velocity went way, way up when we adopted TBD. It took some time for people to become comfortable with the new approach, not because it's complex, but precisely because they had grown so used to unnecessary complexity and had to unlearn many things.
Why do you think this? There is nothing about trunk-based development that rules out having several live release branches. Google is the poster boy for TBD in the article, and in their main monorepo there are always numerous live release branches but it is still trunk-based. Fixes go into main and are down-integrated to the releases.
I have worked at organizations that followed TBD and git-flow.
TBD is much better for software that is delivered to the end user as a package ( not as a SaaS ), ones that does not require a staging branch
> Why are the alternatives inferior?
This is specifically useful if your working on multiple releases at the same time. With git-flow, your pull requests ade blocked for the later release until the earlier release goes out of the door. When you later merge the PRs that has to go into the later release, you get massive conflicts which waste time.
With this model, all changes are always present on trunk first and are cherry-picked onto the release branch. Release owners can selectively choose to include whatever changes they are comfortable with onto their releases. This dramatically signifies communication and management of releases.
With TBD you can reduce the overhead of coordination between committers.
Edit for clarification: "Branching in code", á la Feature Toggles is much better, because everything around it can be automated. With CVS branches, you shift that process into an earlier development stage where you need more human collaboration. So TBD can shift the focus of collaboration to things that matter more: the code.
I have the same experience! Trying to introduce the teams I've worked on to TBD and frequent releases, but they don't see any issue with long lived branches and infrequent releases
Yeah, we also use something like this for building a website/webapp (for a client) with 5-10 people.
- Feature branch: do whatever you want
- Develop: should be good enough for the client (product owner) to look at
- Release branch: should be good enough to be tested by the test/QA team
- Master: should be good enough for website visitors
Branches are meant to be shortlived and merged (and code reviewed) into develop as soon as possible. We use feature toggles to turn off functionalities that end up in develop but can not go to production.
Release branches have a place where you are releasing software and supporting multiple different release versions for different clients, because you need to be able to bug-fix older versions and merge fixes forward rather than just fix current and re-release into your own system.
If you only ever give a shit about ‘latest’ then you don’t need to bother with them. IMHO.
Not that I don't see the value proposed by TBD, but I think you can have >90% of said value and none of the downsides using a well thought out branching strategy.
I've been developing like this for the past few years now but at my previous jobs people still used feature branches, so there are definitely other styles out there.
Holy shit. Just admit that TBD is a fad instead of trying to define every successful methodology into it.
Branches tend to be solo devs and tend to live less than a day. But nobody develops in master. It's actually locked down to just merges from pull requests.
It may be different if you develop something which is a library (rather than app) AND it is big enough you consider backporting changes to older versions.
If you don't, release branches (rather than tags) are nothing by a burden.
You can still do TBD for most of the development of new features, though.
reply