QA builds
Releases
Our releases are made live every other Tuesday morning. The Go Live workflow runs every Tuesday at 12:00 UTC (8AM ET). For iOS, it runs the Fastlane release lane which uses the Spaceship API to find a version pending developer release in App Store Connect and promotes it to production. For Android, it runs the Fastlane release lane which checks whether the Pre-Prod Stash track has a newer version than the production track and promotes it if so. On non-release Tuesdays when there is no staged build, the iOS lane will fail (no pending version found) and the Android lane will exit gracefully (no newer version to promote).
Release branches are cut by an Action every other Wednesday that follows a release. The release branch acts as a freeze on the develop branch for the next release that allows QA to run regressions from a static point and allows any last-minute changes to be added before being merged to main and built for review in the stores. This release branch being created then starts automation that creates the release ticket in GitHub and assigns the relevant people.
Releases coincide with the last day of a sprint and new release branches are cut on the first day of the sprint.
Release process approval uses GitHub environment protection rules. The release_branch_issue workflow creates two approval gates: a QA approval gate (environment: release-qa) and a release approval gate (environment: release). Authorized approvers for each environment are configured in the repository's environment settings. Once both gates are approved, the run_approval workflow merges the release branch to main, tags the release version, and triggers the production release build.
Once the release is approved, the build system will create and upload production versions of the app to the App Stores for review. Barring any issues, these should be released on the next Tuesday when the Go Live workflow runs.
Because crontab notation doesn't have a way to schedule a job at an interval (i.e. every two weeks), the Go Live workflow runs EVERY Tuesday. This means that if a release is approved and the release build completes before the Tuesday in the middle of the sprint, it will be promoted to production a week early on the next Tuesday.
Additionally, the manual dispatch of the Go Live workflow requires approval via the manual-release environment protection gate, but scheduled Tuesday runs bypass this gate entirely. Be aware of this distinction when coordinating release timing.
QA Builds
Daily Builds
Regular QA builds are distributed every weekday. These builds are based on the most current commit on the develop branch in order to provide QA with the most up-to-date versions as possible and can be augmented with the other types of builds.
On Demand Builds
In addition to our automatically scheduled builds, we also have the ability to create QA or UAT builds at any time from any branch, also known as On Demand builds. The On Demand Build Workflow, which can also be found on the left hand sidebar in GitHub Actions, allows us to specify a branch and an environment to create a build from (steps listed out in QA documentation).
On Demand Build Script
On Demand Builds can also be run from a developers local machine to create one-off-builds for distribution to a specific team or for a specific configuration. These builds use the on-demand script and require the developer to have a copy of the signing certificates and keychains on their local machine.
This type of build is usually for very specific builds the developer wants to distribute to other tracks in Test Flight and Play Store. It is also here as a back-up in case the automated build system experiences issues. This allows for manual kick-off of a build, but guarantees that the build will be, at minimum, configured and built correctly.