コンテキスト

App StoreやPlay Storeでのアップデートの定期的なリリースは、特に複数のアプリを同時に管理する場合、思っている以上に複雑です。異なるチームのワークフローを探ることは興味深いものです。共通点や相違点を明らかにすることで、有益な戦略が見つかる可能性があります。ここでは、eyLogのモバイルリリース管理についての概要を紹介します。

リリースサイクルの概要

私たちのリリースサイクルは、多くの企業が行っていることと非常に似ています。以下は、私たちがどのように管理しているかの簡単な説明です：

  • 私たちは毎月新しいバージョンをリリースしているので、毎月リリースカットを行います
  • リリースカットが行われたら、すぐにテストが始まります。主要な問題を修正するためには約1週間の時間があり、その間にリリースブランチに修正を追加していきます
  • テストと修正が完了した後、通常月の中旬にApp Storeレビューにアプリを提出します。このタイミングで、もし審査での拒否や遅延があった場合に余裕を持つことができます
  • 承認を得ると、ビルドは月末までリリースの準備を整えておきます
  • リリース当日、私たちは自動更新で小規模なユーザーグループにフェーズリリースでアップデートを展開します。これにより、テストで見逃した大きな問題を早期に発見することができます
  • 新しいリリースのパフォーマンスを慎重に監視した後、7日目には全ユーザーへの展開を加速させます
  • この間に、次のリリースの準備も始めているので、サイクルは連続的に進行します

コミュニケーションの管理

リリースやロールアウト中にコミュニケーションを明確で整理されたものに保つために、各リリースごとにCliqチャンネルを作成します。例えば、#ios-release-6-1-0 のように。この方法により、特定のリリースに関する更新情報や議論を一元化することができ、他のチャンネルでの気が散る情報を減らし、過去のリリースに関する情報も簡単に見つけることができます。

専用のCliqチャンネルを持つことは、ホットフィックスを発行する際に特に有用です。私たちは毎週更新をリリースしているので、既存の問題に対するホットフィックスは、2つのリリースが同時に行われることを意味します。それぞれのリリースのコミュニケーションを独立したチャンネルで行うことは、混乱を避けるために重要です。例えば、バージョン6.1.0のホットフィックスに関連する内容は#ios-release-6-1-0で議論され、次のバージョン6.2.0に関する議論は#ios-release-6-2-0で行われます。

リリース候補のテスト

私たちのアプリは非常に大きいため、リリース候補のテストを1人または少人数のグループで全て処理することは不可能です。品質保証（QA）チームだけでは、毎週行われる重いテストに追いつくことができません。多くの変更や新機能が迅速に開発されているため、正しいテストが行われているかを確認することが難しいです。実際に機能を開発している人々が、何が新しいのか、何が変更されたのか、どのようにテストすべきかを最もよく理解しています。

そのため、リリース候補のテストには「ウォッチドッグ」と呼ばれるエンジニアグループを頼りにしています。このグループはバックエンド、フロントエンド、モバイルエンジニアで構成されており、それぞれが自分の担当するアプリの部分をテストします。ウォッチドッグは、テスト中に見つかった問題を修正するか、修正を他の人に委任します。各部分は通常、私たちのプロダクトチームに対応しており、例えばログインチームはアプリのログイン機能をテストします。ウォッチドッグは、承認する前に必ず実行しなければならないテストを持っており、すべてのコンポーネントが承認されてからリリースをレビューのために提出することができます。

リリース候補のテスト中に発生した問題の処理

ウォッチドッグがリリース候補のテスト中に問題を見つけた場合、彼らはチームと協力して問題を解決し、標準的なプルリクエストを使用してメインブランチに修正を加えます。修正がマージされた後、その修正は「チェリーピック」というプロセスを通じてリリースブランチに追加される可能性があります。しかし、変更を最後の瞬間に加えることはリスクを伴うため、リリースに含めることができる内容には厳格なルールがあります。

私たちは、ユーザー体験に影響を与える重大な問題や新たに発生したバグの修正は許可しますが、ユーザーに影響を与えない軽微なバグ修正や、締切を過ぎた新機能を追加することは許可していません。修正リクエストをレビューするシステムを開発しており、チームは問題を説明し、証拠を提供するリクエストを提出し、それをリーダーが確認します。

リリース後のホットフィックスのプロセスは、リリースサイクル中のチェリーピックのリクエストに似ていますが、ルールはさらに厳格です。ホットフィックスを作成するにはより多くの労力が必要で、今後の通常のリリースに干渉する可能性があります。リリースサイクルの遅い段階でバグが発見された場合（アプリがレビューに提出された後、公開前など）、修正するかどうかは、リリース後のホットフィックスと同じ厳格なルールに基づいて決定されます。

更新がまだ公開されていなくても、レビュー待ちやすでに承認されている場合があります。これを修正するには、現在のビルドを却下してアプリを再提出する必要があります。これによりリリースが遅れる可能性があるため、修正が必要かどうか、またその処理方法をケースバイケースで評価します。ビルドを却下して修正を適用し、再提出することもあれば、予定通りリリースを実施し、後でホットフィックスを発行することもあります。あるいは、バグがホットフィックスを必要とするほど重大でないと判断し、次のリリースサイクルで修正することを選択することもあります。

リリース後のロールアウトの監視

リードと担当開発者は、リリース後の監視を共同で担当しています。私たちはNew RelicとFirebaseを活用して、クラッシュやシステムの健全性を追跡しています。リードが異常を検知した場合、担当開発者に詳細な調査と必要な修正を指示します。一方、問題が発生しない場合、自動的にフルロールアウトに進むことが可能です。