Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

ブランチ運用の見直しと自動化で、モバイルアプリ開発における問題を解決!

freee、マジ価値開発の現場から 第5回

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/10/22 13:59

 freeeの価値基準の一つである、ユーザーにとって「本質的(マジ)で価値ある」ものを届けるということ。本連載ではそれに向かって、日々挑戦を続ける開発現場の事例をお伝えします。今回はfreeeのモバイルアプリ開発における、ブランチ運用方法の見直しや自動化の取り組みについて紹介します。

目次

対象読者

 モバイルアプリ開発において、Gitやリリース周りをもっとラクに運用したい方向け。

freeeのモバイルアプリ開発変遷

 freeeでは現在、モバイルアプリの開発を専業で行っているエンジニアは6名いて、その6名で「会計freee」「人事労務freee」という2種類のアプリを、iOS/Androidの両OS向けに提供しています。

 ただこの規模になったのもここ最近の話で、2年前は2~3人のエンジニアでOS別も含めて4つのアプリの開発を行っていました。

 エンジニアの人数が増えたおかげで、飛び交うPullRequestの量やリリースに含まれる追加機能、機能修正の量も2年前とは比べ物にならないくらい増えましたが、Gitの運用やQA、リリース周りの運用をあまり見直してこなかったため、いろいろと問題が起きてしまいました。

 そこで、エンジニアがちゃんと本業のアプリの開発に専念できるように、モバイルチームでは去年からブランチ運用方法の見直しや運用フローの自動化などを少しずつ進めてきました。その結果、今では運用の多くの部分を自動化し、リリースまでに必要な作業を最小限に抑えることができました。

 加えて、ブランチの運用も柔軟に行えるようになりました。モバイルアプリ開発ではアプリをリリースするまでに、QA中以外にもストア審査中、段階リリース中などモバイルならではのステータスがあり、また状況によってはそれらが同時に進行することもあります。

 そのためWebアプリ開発と比較してもブランチの運用が煩雑になりがちですが、こうしたケースでも比較的運用しやすい状態になっています。

 今回は、以下のユースケースを題材にして、それぞれが昔とどう変わって、今ではどのような仕組みで動いているのかを紹介できればと思います。

  1. アプリをリリースしたいので、QAチームに見てもらう
  2. QAチームに、リリースされるバージョンに含まれる内容を伝える
  3. QAチームのチェックでOKになったので、アプリをリリースしたい
  4. 現在QAチームに見てもらっているが、前のバージョンに不具合があって、その修正を先に出したい

1.アプリをリリースしたいので、QAチームに見てもらう

 freeeではモバイルアプリをリリースするまでに、以下のような流れがあります。

  1. アプリをリリースしたいタイミングでステージング版アプリを作成し、QAチームにチェックを依頼する
  2. QAチームが、そのバージョンで追加・修正された機能のテストと、リグレッションテストを行う
  3. QAチームが確認して問題がなければ、リリース版のアプリを作成しストアにアップロードする

 以前、モバイルチームのGitの運用はGit-flowで行っており、リリースしたい際は最新のdevelopブランチの状態からステージング用のバイナリを作成し、QAチームに渡していました。そのため、QA中はそのリリースに関係のないPullRequestはリリースが終わるまでmergeできない運用になっていました。

QAが終わってリリースされるまで、新規のPullRequestはmergeできない
QAが終わってリリースされるまで、新規のPullRequestはmergeできない

 そこでGitの運用を見直し、現在はGitLab flowの「Release branches with GitLab flow」で運用しています。

 これにより、リリースしたいタイミングでmasterブランチからバージョン別のブランチを切るため、QA中にmasterにリリースと関係ないPullRequestがmergeされたとしても、リリースに影響が出ない環境が実現できました。

リリースしたいタイミングでバージョン別のブランチを切る
リリースしたいタイミングでバージョン別のブランチを切る

2.QAチームに、リリースされるバージョンに含まれる内容を伝える

 QAチームにチェックを依頼する際に、そのバージョンで追加・修正された機能を確認してもらうため、どのような修正が入っているのかを伝える必要があります。

 以前は、1バージョンに含まれる修正の数がそれほど多くなかったため、QAチームに依頼する度にチェック項目を作ってQAチームに渡し、確認してもらっていました。

 しかし現在では、1バージョンに含まれる修正量も多く、チェック項目を洗い出すだけでそれなりの時間を取られてしまうので、こちらは手動運用と自動運用をうまく組み合わせて解決しました。

 流れとしては、以下の通りです。

  1. リリースより前の段階として、日頃PullRequestを作る際に、チェックしてほしい項目を書き出してPullReuqestに記載する
  2. 併せて、PullRequestにMilestoneを設定する(Milestoneは、1.1.0、1.2.0といったようなリリースバージョン別のものが事前に作成されています)
  3. QA依頼時には、MilestoneのURLを渡す
  4. Milestoneに含まれるPullRequestからチェック項目を生成する

 そのため、エンジニアとしてはPullRequest作成時にチェック項目を書き出し、Milestoneを設定していれば、あとはそこからリリース内容とQA時のチェック項目が把握できます。

 ただ、Milestoneを手動で設定していると、付け忘れてしまったためにQAのチェック項目から漏れてしまうリスクもあるので、ここも極力自動化して漏れがないようにしています。

 具体的には、SlackとGitHub連携用のbotを作成し、Slackからbotに対してPullRequestのURLを送ると、botがGitHub APIを利用してPullRequestに対してMilestoneを設定してくれるようにしました。

 botとのやりとりはこんな感じです。

Slack上からbotに対してPullRequestのURLを送る
Slack上からbotに対してPullRequestのURLを送る

 ちなみに、このbotは「Cloud Functions for Firebase」というサーバーレスコンピューティングサービス上で動かしています。そのため、bot用サーバーの面倒を利用者が見る必要がなく、運用がラクです。

 またこのbotは、AssigneeとReviewerも設定して、誰がレビュアーになったのかSlack上で教えてくれます。

 このように、「PullRequestのURLを投げるだけであとはよしなにやってくれる」といった状況にしたことで、無理なくMilestoneの付け忘れを防ぐことができ、結果として各バージョンに含まれる内容が正確に把握できるようになりました。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:freee、マジ価値開発の現場から
All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5