mattsson mattsson - 1 month ago 9
iOS Question

Adhering to git flow rules while taking the App Store review times into account

We've been using git flow for our iOS projects happily for a while now. However, something dawned on me today which means we're actually not following the git flow specification.

When we start doing the final testing of a release, we release a BETA version to several hundred people within our organization. Now, this BETA is basically a Release Candidate since no additional bugs may be found in which case it's ready for App Store release. Since there's 7+ days of review time we always upload this BETA to iTunes Connect and set it to wait for review.

We release this BETA from a tag on the master branch after merging in its release branch. However, git flow dictates that the master branch must reflect what is currently in production. Now, there will always be a wait time until it's actually in production (so we can't not break the git flow model), but if serious bugs are found in this BETA, we remove it from the review queue meaning it's not going to be released, and now the latest commit on master is not reflective of what's going to be in production.

How do you get around this in your workflow?

Answer

We release this BETA from a tag on the master branch after merging in its release branch. However, git flow dictates that the master branch must reflect what is currently in production.

So, why would you do that if the BETA is not currently in production? :)

I mean, the release branch is meant precisely to track the lifecycle of release candidates while they are being evaluated, regardless if that means internal testing, beta users testing or, why not, App Store review process.

So, I’d suggest you keep the release branch open during the entire lifecycle of your BETA and build from there the version submitted to the App Store:

  • If you get a rejection or have any problem with it, you can still tweak it and resubmit a new candidate from that same release branch.
  • Once you get the App Store approval, you can then close the release branch (which merges all changes both to master and develop) and set it live on the App Store.