アプリを安全にリリースするための取り組み(Release trainとClient release process)

QAエンジニアの@rinaです。

今回は、メルカリがおこなっているiOSとAndroidのアプリリリース（メルカリではClient releaseと呼んでいます。以下、Client releaseと表示します）を支えるRelease trainという仕組みとプロセスについて紹介します。

Release train導入の目的と背景

メルカリはRelease trainを導入し、Client releaseを月に2回程度おこなっています。

Release trainを導入する前のリリースでは以下の問題を抱えていました。

• ある機能の開発が間に合わなかった場合に、すでに決まっていたリリース日を延長する。
• あるいは、新たな追加のリリース日を設定する。
• リリースまでの締め切りがはっきりしないまま機能が追加され、その結果、QAによる品質確認が十分でないまま見切りリリースされることがある。

さらに、開発組織の規模の拡大に伴って、上記の問題が多く発生するようになり、リリース日の調整が困難にもなってきました。

これらの問題を解決するために、リリース日をきちんと決めて、リリースに間に合わなかった機能開発は、自動的に次のリリースへ先送りするというRelease trainを導入することにしました。つまり、「電車のように時間になったら出発し、出発時間に間に合わなかったもの（機能）は次の電車を待つ = 次のリリースを待つもの」とすることで、安定した定期的なリリースを実現することを目指すことにしました。

メルカリではAgileとスクラムを4月から導入しています。Release trainは複数のスクラムチームで同期をとるためのスタンダードな手段でもあります。

Release trainを導入することで、複数プロジェクト開発で発生する依存関係を調整し、スクラムチーム間で同期的にリリースを可能にし、安定した開発リズムが提供できるようになることを期待しています。

Release trainでは何をおこなっているのか

Release trainとは、時間になると出発すると発車する電車をイメージしていただきたいと説明しましたが、実際にはリリースブランチカットのことを指しています。リリースブランチのカットに間に合わない機能は、次のリリースを待つことになります。

iOSとAndroidではブランチの運用が異なっており、それに伴いリリースのブランチカットのタイミングも変えています。

現在、iOSでは、QAが終わってからリリースブランチカットをおこないますが、 AndroidではQAが終わっていなくても、リリースブランチカットをおこなっています。

次にRelease trainを用いたリリースプロセスについて説明します。

Client release processについて

Client release processはRelease trainとあわせて実施するプロセスです。プロセスはLinked Limit、Resolved、QA Deadline、Release Judgement Test、Submit といったプロセスがあります。
次に各プロセスについてご紹介します。

Linked Limit

リリースバージョンに対して、プロジェクト施策を紐付ける期限です。 Release trainで「乗車予約をする」とイメージしていただくとよいかもしれません。

実作業としては、チケットの紐付けをおこないます。メルカリではチケット管理にJIRAを採用しています。リリースには、JIRAのリリースページという機能を使い、リリースバージョンの進捗状況などを管理しています。ここでは、JIRAのチケットをリリースバージョンに紐付けをおこないます。 プロジェクト施策に紐付かないが、リファクタリングなどの個別に対応してリリースしたいチケットも紐付けします。
紐付けが完了すると、次のリリースにどのような機能が載るか把握することができます。 ここで、QAとCSがすべてのチケットを確認し、把握しておかなければならない機能や CS対応が必要になる変更内容を確認します。

Resolved Day

これはAndroidのみ設けられている日です。 Androidではこの日までに実装を完了し、リリースブランチカット（Release trainが発車する）します。
チケット管理では、ステータスを「Resolved」にすることから、「Resolved Day」と呼んでいます。

QA Deadline

これは、QAが完了しなければならない期限日です。ここでのQA活動は、各施策、チケットに関してのテスト実施やレビューなどのQA活動が完了していることを指します。
iOSの場合、この日にリリースブランチカット(=Release trainが発車)します。
このタイミングでQAが終わっていなかったりバグフィックスが残っている場合には、基本的にリリースを見送る判断をプロジェクトチームにしていただいています（それがRelease trainだからです）。とはいえ、施策によってはどうしてもリリースに間に合わせないといけないものもあり、現在は、そのような場合は、次のプロセスであるRelease Judgment Testの開始タイミングを調整するなどの対応策を考えています。

Release Judgment Test

ここではリリース対象バージョンのクライアントアプリの最終確認をおこなっています。 主にQAチームが担当しており、メルカリの主な機能が問題なく動作することを検証対象としています。 手動によるManual確認と、Automationでの確認をおこなっています。
また、このテストはクライアントアプリがリリースされる日の状態で確認を行うため、クライアントアプリに必要なAPIがすべてデプロイされた状態でテストを行っています。

Submit

アプリを審査に出す日です。 審査に時間がかかったり、Rejectされる場合の対応の予備日として、1日予備日を設けています。

Client release

リリース当日です。 ここでは、開放率を段階的にあげていき、クラッシュレートがあがっていないか？お客さまからのお問い合わせが増加していないかを確認しながらおこなっています。ここで、何らかの問題が発生した場合は公開を中止するなど、影響範囲を少なくするようにしています。開発エンジニア・CS・QAがおこないます。

Client release facilitatorについて

Client releaseでは、開発エンジニア*1、QA、CS、PMOなど、多くの人が関わります。今回紹介したような、Release trainの導入やリリースまでのプロセスを整備して安全にリリースができるようにしていますが、そのための進行役や、（今回は説明していませんが）イレギュラーなことが起こった場合にも、状況を整理し進行を続けるための役割が必要となります。これが、ファシリテーターの役割となります。

Client release facilitatorは、これらのプロセスの進行や、関係者へのリマインドをおこなって、リリースを進行を促進する活動をしています。リマインドはBot通知なども併用しています。
また、リリース後にはファシリテーターのメンバーで集まってふりかえりをおこない、プロセスカイゼンや、ファシリテートのカイゼンをおこなっています。

ファシリテーターは専任ではなく、普段は他のプロジェクトの仕事をやっています。その中でも、何か普段と違うことがあった場合に、Client releaseの優先度をあげて対応や判断をすることが求められるため、集中力を保つことが難しいです。
これは、今の課題でもありますが、できるだけ自動化できる部分は自動化し、人が介入しすぎないようにしています。

おわりに

今回ご紹介したRelease trainの導入とリリースプロセスの整備により、以下の効果を実感しています。

• リリース日やプロセスが明確になったので、開発規模が増えても、何をするかが明確なために混乱することが減った。
• 開発遅れによるリリース日の変更が減った。
• 次のリリース日が明確なので、QAの相談や調整がよりスムーズになった。

これらは導入途中であり、さらにプロセスをカイゼンすることにより、プロセスがよりシンプルにできそうな部分や、自動化を取り入られる部分がありそうです。究極には、Client release facilitatorが必要なくなると完全にうまくいった状態なのかもしれません。