Using Fastlane to promote QA builds to beta

We’re trialling Fastlane at White October at the moment, and getting quite excited about it :-) Fastlane is a set of tools that take all the pain out of building, provisioning and shipping iOS apps. We’re using it as a streamlined and consistent way to produce iOS app builds that get shipped to QA (via HockeyApp), TestFlight and finally the App Store. Our current process follows something like this:

  1. Developer is satisfied with current build, runs fastlane qa to ship a build to HockeyApp (build number is bumped)
  2. QA team is notified and carry out testing
  3. Once QA team are happy, the build needs to go to TestFlight for the client to test
  4. Once the client is happy, the build gets promoted to the App Store

It’s normally the case that between steps 2 and 3 above, further development occurs. In this case, we don’t want to ship the newer code to the client and say “test the earlier features that QA have signed off but ignore these possibly-broken features”. We’ve adjusted our Fastlane config to find the most recent QA build based on git tags, and to ship this to TestFlight instead, signed with the appropriate provisioning profile. Here’s a trimmed-down snippet from our Fastfile:

I’m sure the Ruby code could be improved, but the general idea is to find the most recent QA build, check that tag out and build that release to ship to TestFlight. This should ensure that the QA build that’s been signed off is the one that the client gets.

This relies on your use of the Fastlane default git tags in the format builds/iosqa/#{build_number}.

I’m excited to see how else Fastlane can streamline our mobile build processes!

Post a Comment

Your email address is never published nor shared. Required fields are marked *

Ready to talk?

Whether you want to create a new digital product or make an existing one even better, we'd love to talk it through.

Get in touch