はじめまして、メルペイのiOSチームでEngineering Managerをしている玉城です。この記事は、 Merpay Advent Calendar 2021 の11日目の記事です。

はじめに

メルカリアプリでは2020年の8月ごろから約1年ほどかけてリリースサイクルを2週間から1週間のサイクルに更新し運用してきました。この記事ではリリースサイクルをアップデートする為にどのような準備をしてきたかをご紹介したいと思います。

リリースサイクルを短くするねらい

これまでメルカリアプリのリリースはリリーストレインというルールに基づき2週間に1度のサイクルで継続的にアプリをリリースする運用を続けていました。しかし、一度リリーストレインを逃すと次のリリースである2週間後まで待つかhotfixを検討する必要がありました。前者はお客さまのフィードバックを迅速に得られず、後者はイレギュラーな対応のため多くのリソースを割く必要があります。リリースサイクルを短くすることで、「より柔軟にリリースプランができ、よりhotfixを減らし素早くリリースができる」ことの需要が社内で高まったことでリリースサイクルのアップデートの活動が始まりました。

新しいリリースサイクルのための準備

1週間サイクルの工程整理

これまでの2週間サイクルを1週間サイクルとした場合の工程を整理し、各工程がこのスケジュールに合わせて完了可能かを検討しました。これまで別のタイミングで行っていたリリースブランチカットを同日にしたりLinked Limit（リリースに含める変更を紐づける期限、参考 ）を廃止したりといった単純化が可能であること、メルペイのリリース判定テスト（Release Judgement Test)を1日で完了させる事が必要であることがわかりました。

メルペイのリリース判定テストの短縮化

前述した工程の整理でメルペイのリリース判定テストの短縮化が必要だとわかったので、メルペイではリリース判定テストにかかる時間を短縮する具体的な方法を検討することにしました。
リリース判定テストの時間短縮のために、エンジニア側では既存の手動テストの何割かを自動化するゴール設定を行いテストの整備を実施、QA側ではテストケースの見直しによるテストケースの全体数の圧縮や補助的に人員追加などを行って実現することが出来ました。

リリーススキップに関わる運用ルールの追加

新サイクルではリリース判定テストをパスしなければその週のリリースをスキップするのが基本方針です。しかし例外的にリリース時期の変更を避けたい場合のハンドリングのための基準やルールを以下のように新たに作成しました。

• 事前にリリースがスキップされる可能性についてPMに周知し事前にイレギュラーなハンドリングが起こるのを避ける。
• スキップ可能である場合、リリース判定テスト中に問題が発生したらその週のリリースをスキップする。
• スキップを避けたい場合は、リリース判定テスト中に問題が発生したらイレギュラーなリリースを要望する担当PMが問題解決のハンドリングを行う。

Feature Flagによるリリースコントロール

リリースサイクルを短くするのと合わせてFeature Flagによる機能のリリースをコントロールする事もグループで徹底するようにしています。現在メルカリ・メルペイは基本的にFeature Flagによる制御によって、問題があった際に対応が完了するまでの間 機能を閉じるといったことができるようにしています。これもhotfixによるイレギュラーな対応を極力減らす為に必要な施策です。以前から導入していたFeature Flagの仕組みですが新しいリリースサイクルを支える重要な要素となっています。

Client on-call体制の整備

リリースサイクルを短くしたことに合わせてクライアント側でもオンコール体制を取る試みを始めました。前述したFeature Flagによるリリース制御があるため、ロールバック可能なケースが多いですが、それで対応できない場合のためのオンコール体制を整備しています。

新しいリリースプロセスの実施

トライアル期間を設ける

新しいリリースサイクルを始める条件が整った時点で新サイクルのトライアルを実施をし、新しいプロセスの問題点を洗い出しを行いました。
具体的には今まで通りの2週間サイクルでリリースを行いつつ、以下のような観点で問題がないかを数サイクル運用しながら確認しました。

• リリース判定テストがiOS/Androidでそれぞれ１日で終わるか？
• リリース判定テストが終わらなかった原因は定常的なものか？
• リリースのスキップについて新しいルールに従い周知できているか？
• その他、トライアル中に見つかった問題はないか？
  

  フィードバックを得る

  新しいリリースサイクルを実施できたからといって、それで当初の目的が達成されたとは限りません。目的に向かって正しく進んでいるのか、それとも新たな課題が発生して悪い方向に進んでいないのかを知る為に、新リリースサイクルに対してプロダクト側、エンジニアリング側の双方からフィードバックを得るためにエンジニア、QA、PMO、PdMなどにサーベイを取りました。

新しいリリースサイクルへの満足度は、5段階評価で3(17.9%)、4(42.9%)、5(39.3%)と概ね回答者からは高い満足度であり、社内の需要を一定満たしていることがわかりました。

良い点と改善点についてのフィードバックについても概ね想定した通りで、最も多かった良い点のフィードバックは「より柔軟にスケジュール出来ることで無理な予定が組まれにくくなった」といった意見が多くありました。その反面、改善点としては新しいリリースプロセスの周知徹底やhotfixの基準のより明確化を求める意見も挙がっており、今後の運用を通じて意見を元にした改善を進める必要性も感じています。

おわりに

1週間サイクルでのリリースを実現したことにより、当初の目的である「より柔軟にリリースプランができ、よりhotfixを減らし素早くリリースできる」をある程度達成できました。今後はサイクルの仕組みや体制を維持するために、グループや職能を横断して互いが一つの目標のために協力するメルカリグループのAll for OneというValueを発揮し続けていく必要があります。メルカリ・メルペイは今後も努力を継続し、お客さまに価値あるサービスを届け続けていきたいと思います。

明日のMerpay Advent Calendar 2021は@poanさんで「Chaos engineering with chaos mesh in payment-service」をお届けします。