[bacro]

Question: For mobile apps, wouldn't gitflow be more suitable, since the app is only released after app store validation? The release branches here seem to match well this purpose. Just to curious to know how trunk-based development is applied in practice for mobile apps.

[cjfd]

That release branches make sense in some circumstances does not mean one has to take all of 'git flow' on board. This is the problem that the comment you are responding to notes. One should design a branching strategy depending on what one needs to do and not do things because one has a branching strategy.

[bacro]

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.

[MiyamotoAkira]

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.

[izacus]

We always worked in a way where the master branch is running a regular release train into our internal / beta / preview release (depending on company and audience size). Both major play stores provide ways of automatically and regularly releasing builds with minimal review (internal channel, TestFlight, Firebase app distribution. etc). Those channels are fed directly from master and used for testing, showing demos to customers and other bleeding edge use-cases.

One of the builds is then chosen as an "actual release" and promoted to the release channel in the store - the commit with the cutoff is tagged in Git.

If, for some reason, a patch needs to be applied to that exact build, you can always branch off from that tag and apply patches. But that was usually avoided and a newer, fixed, build promoted as release instead. I think we had to backpatch things less than once a year and only in very rare cases.

[bacro]

# We always worked in a way where the master branch is running a regular release train into our internal / beta / preview release (depending on company and audience size).

Care to elaborate how you decide if it is an internal / beta / preview release? Some kind of tagging strategy or are all generated at the same time?

[izacus]

Oh we just chose one (I just used slashes because different systems used different names). In reality we had only two builds - the "daily" preview that was built automatically when PRs merged and were used by developers and beta testers (we published to beta channel) and the actual releases that went to production (which were market with git tags).

[agentjj]

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.