[agsnu]

Generally the app store review process is much less of a problem than it used to be, with happy path being 24-48 hours rather than 1 week+.

Of course everything is context dependent (team size, codebase size, testing maturity, frequency of release), but I guess we found GitFlow seemed to be better aligned with modelling the "versioned software" approach - i.e. with releases determined by features, everybody knows/cares about what is in version 2.1 etc, you might have multiple releases all on the go at the same time with development happening for 2.1.1 bug fixes, 2.2 minor features, and maybe master has moved on to stuff that will ship in 3.x etc.

Definitely with less frequent releases (App Store Review taking 1+ weeks and being unpredictable probably had greater influence on release frequency) and a large team, we ended up with releases feeling quite painful - there was a lot of pressure to land features close to the deadline because the next release might not be for a while, meaning there was more churn on release branches as people tried to stabilise things that were borderline "ready".

Git Flow's release branching model added overhead - people might forget to merge back to develop, deal with conflicts or semantic brokenness if you had different targeted fixes on the release branch to mainline development (e.g. let's just disable this functionality for now on release branch and push it to the next version, fix forward on develop, merge release branch back to develop -> now it's disabled there too, have to unwind).

We switched many years ago (probably after reading https://barro.github.io/2016/02/a-succesful-git-branching-mo... ) to a time-based continuous release model - periodically cut a release from master (there are lots of teams shipping mobile apps on a monthly, 2 weekly or even weekly cadence these days), with trunk-based development and cactus branching for releases. If we need to hotfix just need to go to the most recent release tag/branch and ship a fix based off that point, no merging back between branches. If you need to fix a bug in the release, it's on you to make sure an appropriate fix is applied in both places, through e.g. cherry-picking, no need to worry about merging anything back anywhere.

Together with some other actions (cultural focus on reducing post-branch churn and investment in testing capability to gain confidence in release candidates faster, set in the context of a goal to increase release cadence; increased usage of feature flags; etc), we ended up significantly improving release frequency & predictability, which reduced the time for stakeholders to get changes shipped and visible to users from when they were "done" (especially valuable for small changes, of course).

Nobody ever really understood the utility of the "production" branch from GitFlow.

tl;dr GitFlow seemed to add overhead with little value; we switched to trunk based development and didn't look back.

[bacro]

>If we need to hotfix just need to go to the most recent release tag/branch and ship a fix based off that point, no merging back between branches

Thanks for your sharing. Just out of curiosity, how do you tag the release that is in production? Is it automatically? I don't see how you can automate this step when you merge everything only to master.

The process we follow is actually very similar but having the master/develop branches we can automate things more easily, like if a commit is applied to master we know it needs to be tagged as it should come from a release branch, if a commit lands on develop we create an alpha release, if a commit lands to a rc branch a production release is submitted to testflight/playstore beta track for final tests before publishing. We automate all this with a jenkins pipeline. I am curious to see how this is done in a trunk based branching model. Care to share?

[agsnu]

I'm not sure I entirely follow the question. We don't attempt to have any tag in the repo itself representing what is "in production" - which itself is sort of a misnomer because of the iOS App Store 7 day phased release functionality anyway, plus of course lag in customers downloading updates onto their devices.

So if you need to patch something after a release branch point, there is inevitably a discussion dependent on the context of where any in flight release is - has it started rolling? if so how far is it? is it already completely rolled out? Are we halting the release or just following it immediately with a hotfix? Do we want the hotfix to go through phased release? We just have a separate dashboard tracking release status.

Jenkins pipeline wise very similar - land on main, will go in the next nightly build. If you need to patch a release, submit your patch to the relevant release branch, and the corresponding beta/production pipelines will trigger. (Release branches are protected and require special approval to merge to.)

[bacro]

So when you need to do a hotfix, how do you know which commit to branch from if you do not tag the releases that were deployed to production?

To me the only additional complication of gitflow to trunk-based development is the existence of the main branch, because you also create a release branch when you want to make a release. Getting rid off the main branch is usually through tagging, but as I mentioned is not easy to automate the tagging when you do not have an additional branch to use in your pipeline.