GitHubのiOSおよびAndroidアプリケーションのリリースプロセス管理は、GitHub Actionsに大きく依存している。モバイルチームが新リリースを毎週提供できるのは、適切なツールを使用してプロセスを自動化しているからだ — GitHubのエンジニアTaehun Kim氏はそう説明する。
モバイルアプリのリリースは簡単な作業ではありません。ビルドがユーザの手にわたる前に、最終結果が正しくビルドされていること、記述したテストがすべてパスしたこと、重大な問題がテストですべて把握されていることを、確実なものにしておかなくてはならないのです。
GitHubでモバイルアプリのリリースプロセスをコントロールするGitHub Actionsワークフローは、おもに4つの並列タスクで構成されている — 実際にビルド/デプロイそのものを実行するタスク、プロセス全体がすべての面で適切に管理されていることを確認するタスク、リリースノートの改訂を行うタスク、そし新たなバージョン番号でメインブランチを再開可能にするタスクである。ワークフローを以下の図に示す。
GitHub iOSチームのリリース準備が整った時の最初のステップは、そのアプリをビルドし、TestFlightにアップロードして、ベータテスタによるテストを可能にすることだ。Kim氏の説明にはなかったが、Androidアプリの場合も同じように、テストリリースとしてPlay Storeにプッシュすることができる。このステップでチームが利用するfastlaneは、ビルド、テスト、コード署名、デプロイなど、iOSあるいはAndroidアプリのリリースに必要なすべてのステップを自動化可能なツールである。コード署名のステップでは、TestFlightおよびPlay Storeの要件として、証明書と認証情報へのアクセスが必要になる。この情報を安全な方法で、自動化アクションに対して利用可能にする手段として、チームはGitHub Secretsを使用している。
新たなリリースには、専用のブランチが自動的に作成される。これにより、ベータフェーズで発見されたバグの修正プロセスを単純化することが可能になる。バグが発生した場合は、メインブランチで修正した上で、リリースブランチにチェリーピックする。
新リリースには専用ブランチの他にも、マーケティング資料の検証やマニュアルテストなど、ディストリビューションを実行するために必要なすべてのステップを追跡するためのイシューが自動的に用意される。このイシューは、リリースキャプテンと呼ばれる担当技術者によるフォローを簡単にするためのプレイブックとして機能する。リリースキャプテンは、この役割がすべての技術者の間を回るようにアサインされる。この管理にはPagerDutyが使用され、API経由でGitHubアクションを使ってアクセスする。
もうひとつの主要なタスクは、リリースノートを準備することだ。これについても大部分は自動的に処理されている。このケースでは、すべての前回リリース以降のコミットが収集され、関連するコミットメッセージとPR説明をすべて使ってテキストファイルが生成される。このファイルがユーザフレンドリなリリースノート資料のベースになる。編集には人の手が必要だが、これを処理するための特別なPRが作成され、別の技術者にアサインされる。
最後のタスクは、すでに述べたように、メインブランチのバージョン番号をインクリメントして、次の開発サイクルの開始を可能にするものだ。
このワークフローは毎週日曜日にローンチされるので、月曜日になれば、ベータテスタはテスト対象のベータ版を入手し、リリースキャプテンとリリースノートを担当する技術者は自分用のイシュー/PRが用意されていることになる。ベータテストは1週間を通じて実施される。バグが見つかれば、メインブランチにフィックスが作成されて、リリースブランチにチェリーピックされる。コード変更がリリースブランチにプッシュされると、新たなビルドが生成され、関連するストアにデプロイするアクションが別に実行される。週末の時点で致命的なバグが発見されていなければ、リリースが公開される。
GitHubのリリースプロセスは、限られた数のツールを使って、モバイルアプリ用の効率的なDevOpsパイプラインを構築するための合理的な方法を示している。詳細について興味があるならば、元の記事を参照して頂きたい。