チームやアプリの規模はリリースプロセスに影響しますか?まあ、それは状況によります。 1 つの小さなチームからなるスタートアップを想像してみましょう。この場合、チームは通常、機能を作成し、それをリリースするだけです。ここで、多くのチームが取り組んでいる大規模なプロジェクト (銀行アプリなど) を想像してみましょう。

この場合、おそらくプロセス、リリース サイクル、そしておそらく何らかの官僚主義が存在するはずです。それがなければ混乱が生じます。

それでは、アプリにそのようなプロセスを設定する時期が来たことが明確になるのはいつでしょうか?

この記事では、Dodo Pizza アプリ (Android および iOS) のリリース トレインを実装した私の経験と、チームがリリース トレインを実装するために直面した問題について共有します。

あなたが急速に成長している Android または iOS プロジェクトのチーム リーダー/技術リーダーであり、リリース プロセスをまだ管理していない場合、私たちの経験が役立つことを願っています。

かつての様子

2021 年、私たちはすでにチーム内でトランクベース開発 (TBD) アプローチを使用していました。機能の切り替え、分解されたタスクを含むコードをカバーし、単体テストと UI テストを実行しました。私たちの機能ブランチは長く存続せず、CI が機能していました。

リリース プロセスは非常にシンプルでした。機能を公開する準備ができている人は誰でも、それを公開しました。

理想的なシナリオ

ブランチのワークフローの大まかなものは次のとおりです。いくつかのチーム (グレー、ブルー、オレンジ、グリーン) がさまざまな機能に取り組みました。私たちは TBD に従って作業していたため、各機能は複数の連続したブランチを通じて存続することができました。

たとえば、灰色のチームは 4 ステップでフィーチャを作成し、青とオレンジのチームは 1 ステップでフィーチャを作成し、緑のチームは 2 ステップでフィーチャを作成しました。

チームは機能を完成したら、リリースを展開できます。たとえば、青のチームが機能を完成させたら、リリースを行うことができます。その後、オレンジ チームは機能を完成させ、別のリリースを行うことになります。

当時はそう見えたように、我々には完璧な流れがあった。ある時点まではうまくいきましたが、良いことにも終わりが来ます。

何か問題が発生しました: 困難、混雑、予測不能

マンモス

私たちが最初に遭遇した問題は、リリースが多くの機能を蓄積し始めて大きくなりすぎたことでした。

チームは必ずしも自分たちの機能をすぐにリリースしたいとは限りませんでした。リリースとリグレッションのプロセスには時間がかかり、3 ～ 4 日かかりました。そのため、機能が小規模で緊急ではない場合、必ずしも自分でリリースできるわけではありません。おそらく、他のチームがすぐにリリースを行い、そのリリースに含まれることになるからです。ざっとこんな感じでした。

これは、特にチーム数が増え始めたときには非常に脆弱な取り決めでした。多くのチームが多くの小さな機能を開発し、新しいリリースごとに新しいコードの総量が膨大になりました。誰かが大きな長編をリリースするときは、巨大な作品を丸ごと一緒にリリースしなければなりませんでした。

巨大なリリースにより、次のような結果が得られました。

• 遅延型回帰。

• 回帰バグのリスクが高くなります。

• 本番環境でバグが発生するリスクが高くなります。

例の青とオレンジのチームがリリースしたくない場合でも、何らかの形でリリースできるようにする必要がありました。

ボトルネック

すべてのチームはユニークであり、すべての機能が異なります。場合によっては、複数のチームがほぼ同時に機能を完了するような事態が発生することがありました。この場合、「待ってください、明日の朝にマージします、約束します!」ということがたくさんありました。回ってます。

このようなボトルネックにより、最終的に次のような結果が生じました。

• 放たれるとマンモスになる。

• リリースの遅れは、特に他の全員のニーズが満たされた場合に、リリース チームの計画に悪影響を及ぼします。

2 つの重要な変更を加える必要がありました。

1. リリースチームは誰かを待つ必要はありません。

   
   

2. 他のすべてのチームは、次のリリースがいつ予定されるかを知っておく必要があります。

予測可能性の欠如

青のチームが小さな機能を作成し、オレンジのチームがすぐにリリースすることを期待していたと想像してください。しかし、何か問題が発生し、オレンジ チームも独自の問題のためにリリースを公開しませんでした。

その結果、青色のチームは、この機能がすぐに本番環境に導入されるだろうと企業に伝えましたが、それは十分に早くないことが判明しました。そのため、この機能がいつ運用されるようになるかを予測することは不可能です。

これは、青チームが無責任だという意味ではありません。超重要な機能や緊急の機能がある場合は、当然、自分たちでリリースします。ただし、その機能がいつユーザーに利用可能になるかを正確に知る方法がない場合もあります。

ご想像のとおり、このような問題は頻繁に発生していました。私たちは、その規模や緊急性に関係なく、顧客が本番環境で機能をいつ入手できるかを正確に知る必要がありました。 3 つの問題 (膨大なリリース、ボトルネック、予測可能性の欠如) はすべて密接に関連しており、相互に補完し合っています。

しかし、おそらくそれらすべての中で最も基本的かつ重要なのは、予測可能性の欠如です。それは他の問題を引き起こします。

リリーストレイン

もう十分だ。変化を起こす時が来ました。リリーストレインはそれを助けるはずでした。

リリース トレインという用語は、スケジュールされたリリース プロセス、またはリリース プロセスを管理する専任チームなど、さまざまな意味を持ちます。ここでは、予定されているリリースのプロセスについて説明します。

私は、Martin Fowler による「ソース コード ブランチ管理のパターン」記事での Release Train の説明と、 Thoughtworks の技術レーダーでの定義が気に入っています (おそらく、これも Martin のものでしょう)。

これは、私たちが独自にリリース トレインを定義した方法です。

リリース トレインは、チーム間でリリースを調整するプロセスです。すべてのリリースは、機能の準備ができているかどうかに関係なく、固定スケジュールで行われます。電車は誰も待ちません。遅れた場合は次の時間を待たなければなりません。

色分けされたチームを使用して、いくつかの例で詳しく見てみましょう。

マンモス問題の解決

リリース トレインはスケジュールどおりに実行され、誰が何をメイン ブランチにマージしたかには依存しません。以下の例では、青チームとオレンジチームの機能がリリースされます。残りの人は次の電車を待ちます。もう少し待てばマンモスが手に入るだろう。

ボトルネックの解決

同時に、リリース トレインは、作業をより効率的に計画するのに役立ちます。青チームは当初、機能を後で完成させる予定だったとします。ただし、リリース日は誰もが知っているため、計画を少し変更して機能を早期に終了することができます。

あるいは、逆に、次の電車には絶対に間に合わないことがわかり、全体のスケジュールを把握しているため、安全に特集を終えることができます。

以下の例では、青のチームはリリースに到達し、リリース前にすべての変更をマージしたいと考えていました。そうでなければ、ボトルネックがあった可能性があります。

最も重要なことは、Release Train により、設計により予測可能性が得られたことです。

これらの例は明白に思える人もいるかもしれませんが、私たちは問題が発生するたびに解決してきました。リリースに問題がなかったときは、リリース トレインをわざわざ使用することはありませんでした。問題が積み重なったとき、私たちはその時が来たことに気づきました。

チームにリリース トレインを実装する方法

私たちが最初にやったのはRFCを書くことでした。 RFC は、多くの企業がプロジェクトに取り組む前に使用するプロセス自体と設計文書の両方を指します。具体的に RFC を使用する場合もあれば、ADR を使用する場合もあり、単により一般的な用語 Design Doc と呼ぶ場合もあります。

Dodo Engineering では、RFC と ADR の両方を使用します。

私たちの RFC プロセスは次のようになりました。

1. 私たちは RFC 文書の草案を作成しました。

   
   

2. 私たちはそれについて小グループで話し合い、コメントを集めて調整しました。

   
   

3. その後、RFC はより幅広いグループに伝えられました。

   
   

4. それからそれを実装しました。

   
   

5. その後、フィードバックを収集し、指標を追跡し、結果を評価しました。

リリース トレインの RFC ドキュメントの構造は次のとおりです。

• リリーストレインプロセスの説明。

• どのチームが関与しており、何をしているのか。

• スケジュールはどうなるのか。

• メトリクス。

RFC の草案を作成する際に、私たちは他の企業の経験に依存しました。

• スカイスキャナー
• サウンドクラウド
• モンツォ
• フェイスブック

最初の実装

まず、次のプロセスを思いつきました。

• 毎週リリース。

• 水曜日の朝にリリース ブランチを作成します。

• リグレスを完了し、金曜日にレビューのためにアプリを送信します。

• 月曜日にリリースの展開を開始します。

• リリースチーム:

  • いずれかの機能チームの iOS 開発者 1 名と Android 開発者 1 名。

  • QAエンジニア2名。

    
    

• 水曜日に新しいリリース ブランチを作成します。

• 1四半期前にスケジュールを立てて、各チームがいつリリースするかを示します。四半期後に集まり、スケジュールを延長します。

概略的には、リリース トレインは次のようになります。

すべてがスムーズにはいかなかった

1か月後、最初の経験は素晴らしかったが、

• 毎週回帰を行って金曜日までに完了するのは本当に大変でした。

• ホットフィックスを適用する時間がなく、時々ホットフィックスが発生することがありました。

2021 年、回帰テストには平均 3 ～ 4 日かかっていました。 2022 年にはなんとか 2 ～ 3 日に短縮できましたが、場合によってはその期間を超えることもありました。私たちは e2e テストで回帰ケースをカバーし続けましたが、まだ 100% カバーしていませんでした。各プラットフォームでの回帰ケースのカバー率はそれぞれ約 70% と 60% でした。

ここからわかることは、回帰テストの完了に数日かかる限り、リリース サイクルを毎週実行するのはおそらく不快であるということです。

最終的な答え

最終的に 2 週間のリリース サイクルに移行し、リリース トレインは次のようになりました。

• 2週間ごとにリリース。
• 水曜日の朝にリリース ブランチを作成します。
• リグレスし、金曜日にレビューのためにアプリを送信します。
• 月曜日にリリースの展開を開始します。

• リリースチーム:

  • いずれかの機能チームの iOS 開発者 1 名と Android 開発者 1 名。

  • QAエンジニア2名。

    
    

• 1四半期前にスケジュールを立てて、各チームがいつリリースするかを示します。四半期後に集まってスケジュールを延長します。
• 徐々にリリースをロールアウトします。
• 必要に応じて、時間があるときにホットフィックスを実行します。
• 1 週間後の水曜日に、新しいリリース ブランチを作成します。

すべてが計画どおりに進んだ場合のプロセスは次のようになります。

潜在的なホットフィックスを適用する時間が十分に残っていることを除けば、すべてが毎週のサイクルのように見えます。拡張回帰テストの場合は次のようになります。

どちらも大したことはありません。ホットフィックスを適用するまでにはまだ時間があります。

新しいプロセスは予測可能性にどのような影響を与えましたか?

私たちの主な目標は、予測可能性を高めることでした。これは 2 つの部分に分けることができます。

1. アプリケーションはいつリリースされますか。
2. 私の機能はどのリリースに組み込まれますか?

「いつリリースされますか？」という質問に答えました。リリーストレインプロセスを実装することによって。これで、各チームは「私の機能はどのリリースで完成するのか?」という質問に答えることができるようになります。機能を計画および評価する時点では、独立して実行されます。

以前は、別のチームがリリースを行うかどうかがわからないため、確実に言うことはできませんでした。今では、すべてはそのチーム自身の計画にのみ依存します。

これをさらに確認するために、モバイル開発者、QA、製品マネージャーを対象にアンケートを実施し、他の質問とともに次のことを尋ねました。

• 次のリリースはいつですか? (この質問には 100% が回答しました)。

• Release Train はチームワークの計画に役立ちましたか? (75% が肯定的に答えましたが、リリース トレインがなくても自分の作業を完全に予測した人もいました)。

Release Train は、コードのフリーズとリリースのフリーズにも役立ちました。大晦日（たとえば、9月1日やいくつかの休日）に加えて、それらがいくつかありました。 Release Train を使用すると、リリース ブランチの作成や回帰テストなどを行ってこれらの日付に調整する必要がなくなります。リリースは予定どおりに機能します。後で店で開けるだけです。

指標への影響

問題を解決するだけでなく、指標も測定しました。主なものを見てみましょう。

リードタイム

私たちが測定した最初の重要な指標は、リリースまでのリードタイムコミットメントでした。

グラフはこんな感じです。リリース トレイン プロセスを開始した時点を矢印でマークしました。

グラフは、リードタイムが約 6 日程度に短縮されたことを示しています。 6日間は長いのでしょうか、それとも短いのでしょうか？

Google ベンチマーク

があるこの指標に対する Google のベンチマーク, しかし、それは主にバックエンド用です。その規模に応じて、次のグループが区別されます。

• エリート: 1 時間未満
• 高: 1 時間から 1 週間
• 中型: 1週間から6か月
• 低: 6 か月以上

標準的なモバイル アプリのリード タイムは、理想的にはリリース サイクルの長さの半分を目指すべきだと私は考えています。これは、タスクを毎日メイン ブランチにマージするのと同じです。つまり、リリース サイクルが 14 日の場合、リード タイムは 7 日を目指す必要があります。

回帰あたりのバグ数

私たちが追跡するもう 1 つの指標は、回帰ごとのバグの数です。リリース候補がどの程度安定しているかを説明します。以前のリリースがかなり前のものであれば、おそらく多数のバグが含まれる可能性のある新しいコードを多数作成し、回帰と修正により多くの時間を費やす可能性があります。

ある時点では、この指標は 3 つのバグにまで減少しました。具体的な数字はそれほど重要ではありませんが、全体的に見ると、傾向が下がっていることがわかります。

その他の指標

リリース トレインの一部としてどのような指標も監視されたかについて簡単に説明します。

• クラッシュフリー。私たちは常にこの指標に注目しています。回帰をより狭い時間枠に収めようとしたため、減少するだろうという仮説がありました。まあ、ドロップは起こりませんでした。

• 私たちは、頻繁（毎週）のリリースが顧客離れやアプリの削除に影響を与えるかどうか疑問に思いました。その結果、影響は検出されませんでした。

実装、改善

現在のプロセスは目標を達成していると考えており、気に入っています。さらに改善する方法もわかっています。

• 私たちは回帰を自動化し、よりシンプルかつ高速にする取り組みを続けています。

• ここまでは作業の自動化（分岐用のスクリプト）に関する部分を省略してきましたが、これも今後の大きな成長ポイントになるでしょう。

• 私たちのアプリは 20 か国で動作するため、アプリケーションをさまざまな言語に翻訳する必要があります。これには内部サービスがありますが、開発者はリリース前にこのプロセスに手動で参加する必要があります。このプロセスを自動化すると、リリース サイクルがさらに改善される可能性があります。

まとめ

私たちは比較的小規模でしたが、リリース トレインは必要ありませんでした。リリース、そのサイズ、数を予測できないという事実に直面したとき、私たちはリリース トレインを実装することにしました。最初は毎週のリリース サイクルを試しましたが、時間がかかるリグレッションのため、2 週間のリリース サイクルに切り替える必要がありました。それ以来、私たちはこのように生きています。

現在、リリースは予測可能であり、指標はポジティブなダイナミクスを示しています。私たちは、e2e テストによる回帰ケースのカバー範囲を増やし、ブランチでの作業プロセスを自動化し、翻訳プロセスを最適化する予定です。

この記事と私たちの経験が、特に同様の問題にすでに直面しており、リリース プロセスについて考えるきっかけになった場合に役立つことを願っています。

私の記事を読んでいただき、誠にありがとうございます。楽しんでいただければ幸いです。ご質問やご提案がございましたら、コメント欄にご記入ください。必ず読ませていただきます。

そしてTwitterでフォローしてください。普段は Android 開発とソフトウェア エンジニアリング全般について投稿しています。

ここでも公開されています