BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース DoorDash社から学ぶモバイルアプリ リリース管理の重要な教訓

DoorDash社から学ぶモバイルアプリ リリース管理の重要な教訓

原文リンク(2023-12-02)

DoorDash社のモバイルアプリのリリースプロセスは、チーム間で共有された明確な責任の所在、効果的なコミュニケーション、テスト、リグレッションやホットフィックスの取り扱いに関する厳格なルールに基づいていると、DoorDash社のエンジニアであるManolo Sañudo氏は説明する。すべての組織がDoorDash社のような規模で仕事をしているわけではないが、彼らのアプローチの中には、小規模な組織にも参考になる側面が数多くある。

DoorDash社のリリースサイクルは非常にシンプルだ。新しいリリース対象ごとにリリースブランチが作成され、1週間かけてテストと修正を実施、最終的に正式リリースに至る。

新しいリリース対象ごとにリリースマネージャーが割り当てられ、プロセスを監視し、すべてがスムーズに進むように管理する。誰も負担を強いられることはないようリリースマネージャーの人数は十分に確保されているが、リリース全体で一貫した意思決定を行うことを妨げたり、リリースプロセスの発展や改善を危うくしたりするほど多いわけではない。

各リリース対象には独自のSlackチャンネルが用意され、ステータスの更新や会話を一箇所に集中させることで、本番環境のバグに対するホットフィックスなどリリースとは関係のない情報が入ることを防いでいる。

テストについては、1週間で完全なリグレッションテストを行うことは不可能であるため、いわゆるコンポーネントオーナーがすべてのコンポーネントを個別にテストし、モバイルリリース管理プラットフォームRunwayを使用してテスト状況を追跡する役割を担っている、とSañudo氏は述べている。

各コンポーネントオーナーは、コンポーネントを承認する前に特定のテストを実行する必要があります。そして、リリースに向け審査を行う前に、すべてのコンポーネントが承認されなければいけません。

時折、このテスト段階でバグが発見される、とSañudo氏は語った。この場合、リリースマネージャーは該当するチームと協力して修正プログラムを開発し、それをメインの開発ブランチにプッシュするが、その修正がリリース対象のブランチにマージされるのは、そのバグがユーザーの利用に影響する場合だけだ。ユーザーに影響を与えない不具合も、新しい機能も、このフェーズでは反映を許さない。そして、選び抜かれた修正は、チームによって評価され、リリースマネージャによって承認されなければならない。

レビュープロセスの後半でアプリにバグが検出された場合、ホットフィックスの実装はリリースの遅延となる可能性があるため、さらに厳しいルールが適用される。

アップデートはまだ公開されていないが、レビュー待ちであったり、すでに承認されている可能性もあります。これはリリースを遅らせる恐れがあるため、修正が必要かどうか、どのようにアプローチするかはケースバイケースで評価します。

Apple社による承認後、新しいリリースはユーザーベースの1%にロールアウトされ、大きな問題が表面化していないことを確認する。このフェーズでは、チームは主要なメトリクスを使用して、新しいリリースで自分たちのコンポーネントで何が問題になっているかを把握する。同様に、リリースマネージャーはSentryを使用して、クラッシュ率や傾向的な問題など、より高いレベルのメトリクスを追跡する。

作者について

この記事に星をつける

おすすめ度
スタイル

BT