GitHub relies heavily on GitHub Actions to manage the release process for their iOS and Android apps. Using the right tools to automate the process allows the mobile team to ship a new release every week, GitHub engineer Taehun Kim explains.
Shipping a mobile app is not an easy task. Before a build goes out to our users’ hands, we must make sure the end result is properly built, all written tests are passed, and any critical issues are captured by testing.
The release process for GitHub mobile apps is controlled by a GitHub Actions workflow comprised of four main parallel tasks: one for the actual build/deployment itself; another to ensure the whole process is properly managed in all of its aspects; another leading to the redaction of a release notes document; and a final one aiming to ensure work can be resumed on the main branch with a new version number. This workflow is shown in the image below.
When the GitHub iOS team is ready to ship a new app, the fist step consists in build the app and upload it to TestFlight to make it available to beta testers. Similarly, although Kim does not expressly states it, the Android app can be pushed to the Play Store as a testing release. For this step, the team relies on fastlane, a tool that is able to automate all the steps required to release an iOS or Android app, including building, testing, code signing, and deploying it. The code signing step requires access to certificates and credentials as required by TestFlight and the Play Store. To handle this information in a secure way while making it available to the automation actions, the team uses GitHub Secrets.
For each new release, a new dedicated branch is automatically created. This allows to simplify the process of bug fixing for any bug that is discovered in the beta phase. When this happens, the bug is fixed on the main branch, then cherry-picked into the release branch.
Along with the dedicated branch, each new release also automatically gets an issue to track all steps that are required to a successful distribution, including verification of marketing materials, manual tests, and so on. The issue works as a playbook helping the assigned engineer, dubbed the release captain, to easily follow along. The release captain is assigned in a way this role rotates among all engineers. This is managed using PagerDuty, accessed using a GitHub action via its API.
Another major task that is required is preparing the release notes. This is also handled in large part in an automated way. In this case, all commits since the previous release are collected and all related commit messages and PR descriptions are used to create a text file. This file is the basis for the user-friendly release notes document, whose redaction will require human intervention. To handle this, a specific PR is created and assigned to another engineer.
A final task, as mentioned, aims to increment the version number for the main branch, so engineers can start the next development cycle.
This workflow in launched every Sunday, so beta testers get their beta-versions to test while both the release captain and the engineer responsible for the release notes will find their issue/PR ready on Monday. Beta testing goes on for the whole week. If a bug is found, a fix is generated on the main branch and cherry-picked into the release branch. Another action makes sure a new build is created and deployed to the relevant store whenever a code change is pushed into the release branch. If at the end of the week no significant show-stoppers are found, then the release is made public.
GitHub release process shows a streamlined way to build an efficient DevOps pipeline for mobile apps using a limited set of tools. If you are interested in the full detail, do not miss the original write up.