対象読者
モバイルアプリ開発において、Gitやリリース周りをもっとラクに運用したい方向け。
freeeのモバイルアプリ開発変遷
freeeでは現在、モバイルアプリの開発を専業で行っているエンジニアは6名いて、その6名で「会計freee」「人事労務freee」という2種類のアプリを、iOS／Androidの両OS向けに提供しています。
ただこの規模になったのもここ最近の話で、2年前は2～3人のエンジニアでOS別も含めて4つのアプリの開発を行っていました。
エンジニアの人数が増えたおかげで、飛び交うPullRequestの量やリリースに含まれる追加機能、機能修正の量も2年前とは比べ物にならないくらい増えましたが、Gitの運用やQA、リリース周りの運用をあまり見直してこなかったため、いろいろと問題が起きてしまいました。
そこで、エンジニアがちゃんと本業のアプリの開発に専念できるように、モバイルチームでは去年からブランチ運用方法の見直しや運用フローの自動化などを少しずつ進めてきました。その結果、今では運用の多くの部分を自動化し、リリースまでに必要な作業を最小限に抑えることができました。
加えて、ブランチの運用も柔軟に行えるようになりました。モバイルアプリ開発ではアプリをリリースするまでに、QA中以外にもストア審査中、段階リリース中などモバイルならではのステータスがあり、また状況によってはそれらが同時に進行することもあります。
そのためWebアプリ開発と比較してもブランチの運用が煩雑になりがちですが、こうしたケースでも比較的運用しやすい状態になっています。
今回は、以下のユースケースを題材にして、それぞれが昔とどう変わって、今ではどのような仕組みで動いているのかを紹介できればと思います。
- アプリをリリースしたいので、QAチームに見てもらう
- QAチームに、リリースされるバージョンに含まれる内容を伝える
- QAチームのチェックでOKになったので、アプリをリリースしたい
- 現在QAチームに見てもらっているが、前のバージョンに不具合があって、その修正を先に出したい
1．アプリをリリースしたいので、QAチームに見てもらう
freeeではモバイルアプリをリリースするまでに、以下のような流れがあります。
- アプリをリリースしたいタイミングでステージング版アプリを作成し、QAチームにチェックを依頼する
- QAチームが、そのバージョンで追加・修正された機能のテストと、リグレッションテストを行う
- QAチームが確認して問題がなければ、リリース版のアプリを作成しストアにアップロードする
以前、モバイルチームのGitの運用はGit-flowで行っており、リリースしたい際は最新のdevelopブランチの状態からステージング用のバイナリを作成し、QAチームに渡していました。そのため、QA中はそのリリースに関係のないPullRequestはリリースが終わるまでmergeできない運用になっていました。
そこでGitの運用を見直し、現在はGitLab flowの「Release branches with GitLab flow」で運用しています。
これにより、リリースしたいタイミングでmasterブランチからバージョン別のブランチを切るため、QA中にmasterにリリースと関係ないPullRequestがmergeされたとしても、リリースに影響が出ない環境が実現できました。
2．QAチームに、リリースされるバージョンに含まれる内容を伝える
QAチームにチェックを依頼する際に、そのバージョンで追加・修正された機能を確認してもらうため、どのような修正が入っているのかを伝える必要があります。
以前は、1バージョンに含まれる修正の数がそれほど多くなかったため、QAチームに依頼する度にチェック項目を作ってQAチームに渡し、確認してもらっていました。
しかし現在では、1バージョンに含まれる修正量も多く、チェック項目を洗い出すだけでそれなりの時間を取られてしまうので、こちらは手動運用と自動運用をうまく組み合わせて解決しました。
流れとしては、以下の通りです。
- リリースより前の段階として、日頃PullRequestを作る際に、チェックしてほしい項目を書き出してPullReuqestに記載する
- 併せて、PullRequestにMilestoneを設定する（Milestoneは、1.1.0、1.2.0といったようなリリースバージョン別のものが事前に作成されています）
- QA依頼時には、MilestoneのURLを渡す
- Milestoneに含まれるPullRequestからチェック項目を生成する
そのため、エンジニアとしてはPullRequest作成時にチェック項目を書き出し、Milestoneを設定していれば、あとはそこからリリース内容とQA時のチェック項目が把握できます。
ただ、Milestoneを手動で設定していると、付け忘れてしまったためにQAのチェック項目から漏れてしまうリスクもあるので、ここも極力自動化して漏れがないようにしています。
具体的には、SlackとGitHub連携用のbotを作成し、Slackからbotに対してPullRequestのURLを送ると、botがGitHub APIを利用してPullRequestに対してMilestoneを設定してくれるようにしました。
botとのやりとりはこんな感じです。
ちなみに、このbotは「Cloud Functions for Firebase」というサーバーレスコンピューティングサービス上で動かしています。そのため、bot用サーバーの面倒を利用者が見る必要がなく、運用がラクです。
またこのbotは、AssigneeとReviewerも設定して、誰がレビュアーになったのかSlack上で教えてくれます。
このように、「PullRequestのURLを投げるだけであとはよしなにやってくれる」といった状況にしたことで、無理なくMilestoneの付け忘れを防ぐことができ、結果として各バージョンに含まれる内容が正確に把握できるようになりました。
