stand.fmのアプリリリースを迅速に行うための取り組み

はじめまして、stand.fmのエンジニアの冨田と申します。
今年の9月に入社し、早いもので4ヶ月近くが経ちました。

今回は、弊社アプリのリリースサイクルを早めるために行った工夫と取り組みをご紹介します。
実際には、2~3週間に1回であったリリース頻度を週1回リリースにすることができ、ユーザーにいち早く価値を提供できるようになりました。

実際に行った取り組み

・ releaseブランチの運用
・QAのプロジェクト管理
・曜日によるスケジュール設定
順にご説明します。

releaseブランチの運用

これまで、弊社のGitブランチ運用はmasterと開発用のfixブランチのみでしたが、ここにreleaseブランチの運用を加えました。
参考にしたのは、React Native Communityのブランチ運用です。

運用の流れ
1.  全ての開発はmasterから開発(fix)ブランチを切って行う
2.  1.が完成したらPRを出しレビュー、masterにマージしていく
3.  リリースが決まったらreleaseブランチを切り、RC版をビルドし、動作テスト(QA)をする
4.  QAで問題が見つかった場合の修正や、急ぎで含めたい開発があった場合は、masterからリリースブランチにcherry-pickをする
5.  確定したら本番用にビルドし、アプリ審査に提出→リリース

このようにreleaseブランチを用いることで、以下のメリットが生まれました。
・開発とリリース準備(QA・審査提出)を非同期に行えるので、開発が滞らない
　これまでは、開発が終わったがまだリリースしたくないものは、リリース準備が終わるのを待ってmasterにマージする必要があった。
・リリースに問題が起こったとき用に、過去バージョンの状態を保存しておける

GitHub Flowに近いですが、それはRC版での修正をreleaseブランチで行うのに対し、弊社ではmasterで修正しcherry-pickする手法にしています。これにより、開発者は常にmasterブランチのみを意識すればよくなりました。

QAのプロジェクト管理

安定した製品を作るために、動作テスト(弊社では総称してQAと呼んでいます)は欠かせません。
QAには大きく2種類あり、開発した機能単位のものと、リリース時の全体のものがあります。

前者は開発した機能やバグ修正の動作確認テストで、後者は、複数の開発により意図せぬ箇所に不具合が起きていないかのリグレッションテストです。両方のテストを効率的に管理するために、Github Projectsを用いたカンバン方式を導入しました。

ぼかしている箇所の1つ1つのカードが、masterにマージされたPull Requestです。これらについて、必要に応じてテスターに動作確認を行ってもらっています。

現在は以下の7種類のリストを用いて、ステータスを管理しています。
1.  QA予定
　masterにマージされ、まだリリース予定には含まれていないもの。
2.  他エンジニア担当
　リリース予定に含まれ、テスターによる動作確認は必要ないもの。
3.  QA待ち
　リリース予定に含まれ、テスターによる動作確認を要するもの。
4.  着手中
　テスターが動作確認中のもの。
5.  QA済み
　動作確認が完了したもの。
6.  QA済み(問題あり)
　動作確認に問題があったもの。
7.  修正Issueアサイン済
　6. から修正のIssueを立て、担当エンジニアのアサインが完了したもの。

これらのリスト間のカード移動を、リリースマネージャーとテスターが行います。
これにより、各開発がテスト済かどうかの品質状態がひと目でわかるようになりました。

なお、PRがmasterにマージされたら自動でQA予定にカードを追加するために、Github Actionsのワークフローを使っています。ライブラリを使った簡単なコードですが、参考までに。

name: Add Pull Request To QA project

on: # masterにPRがマージされたとき
 pull_request_target:
   types: closed
   branches:
     - master
     
jobs:
 add-pr-to-qa-project: # QAプロジェクトのQA予定リストにカードを追加する
   runs-on: ubuntu-latest
   steps:
     - uses: alex-page/github-project-automation-plus@v0.3.0
       with:
         project: QA
         column: QA予定
         repo-token: ${{ secrets.アクセストークン名 }}

動作確認の内容は、エンジニアやレビュワーがPull Requestにチェックボックス形式で記載し、テスターはその結果をコメントします。もし問題があればテスターがカードを移動し、新しくIssueを立ててもらいます。

またリグレッションテストについても、基本機能の項目を洗い出し、動作確認テストがすべて完了したらテスターに行ってもらっています。リグレッションテストという名前のIssueに、確認内容をチェックボックス形式でコメントする形です。

このIssueのカードもProjectに入れられるので、動作確認テストと合わせて管理が可能です。

曜日によるスケジュール設定

以前は不定期であったリリーススケジュールを、毎週月曜日と決めるようにしました。
リリースマネージャー(RM)とテスターの業務は、以下です。

・月曜…開発の締切、動作確認テスト
　RM: masterからreleaseブランチを作成し、RC1版を作成する。QA予定にあるカードを確認し、動作確認の要否判断や確認内容の追加を適宜行い、カードを移動する。
　テスター: QA待ちにある動作確認を行う
・月曜〜水曜…cherry-pick、動作確認・リグレッションテスト
　RM: 修正Issueや間に合わなかった急ぎの開発をcherry-pickし、RC2~版を作成
　テスター: 追加の動作確認、リグレッションテストを行う
・木曜...サーバーデプロイ
    RM: API等のサーバー側変更をデプロイ
・金曜‥審査提出
　RM: 最終版をビルドし、iOSとAndroidそれぞれを審査に提出。社内に共有
・月曜…リリース
　RM: リリースし、社内に共有

月曜リリースにしているのは、土日を審査の時間に使うため、リリース後の万が一の不具合時に対応しやすくするためです。

まとめ

以上の取り組みのおかげで、次のような改善がありました。

・各開発の進捗や優先度に依存することなく、安定してリリースができるようになった
・リードタイムが短縮された
・チームのコミュニケーションコストが削減された
・テスターの稼働日を事前に決められるようになった
・リリースマネージャーの業務が効率化し、負担が減った

今回の取り組みについてはまだ実験中で、改善の余地があればどんどんしていくつもりです。(もっと良い方法があるよという方がいたら、コメントで教えてください！)
また今後はUIテストの自動化の導入等で、さらなる品質向上と効率化を図りたいと考えています。CtoCのサービスは、ユーザーの声にいかに早く応えられるかどうかが勝負です。

最後にstand.fmでは、サービスの品質保証を行えるQAエンジニアを大募集中です。サービスが伸び盛りで、ユーザーと開発エンジニアの人数も増えており、QAの重要性が増しています！

他業務のエンジニアについても大募集中ですので、興味のある方は採用ページを覗いて頂ければ幸いです。

採用情報 | 株式会社stand.fm