みなさん、こんにちは〜😃
モバイルアプリケーション開発部のAndroidエンジニア、ジェロームです。 この記事では、モバイルアプリチームのリリースフロー改善について紹介します。
先日#ChatworkTechTalkで発表させていただいた内容をより多くの方に知ってもらいたいため、ブログにまとめました😄
リリースフローとは？
アプリの開発をしたり、不具合を修正した時に、ストアに新しいバージョンを公開するまでの流れのことです。
毎回おこなうリリースの作業、大変ですよね？
弊社ではAndroid / iOSのリリース時の作業の流れ、リリースフローがとても複雑で大変だったため、プロジェクトとして改善に取り組みました。特に注力したのは、リリースの作業をもっと楽にするための方法と、リリース時に行うペアオペ作業の削減、そしてfastlaneやスクリプトを利用した自動化です。
今モバイルアプリチームで使っているツール
- fastlane: iOS/Androidアプリの申請やテストの実行など、様々なことを自動化してくれるツールです。
- Bitrise: モバイルアプリ開発における継続的インテグレーション・デリバリー（CI/CD） プラットフォームをサービス（PaaS）として提供しています。
- GitHub: ソフトウェア開発のプラットフォームであり、ソースコードをホスティングするサービスです。
- Jira: 主にバグトラッキングや課題管理、プロジェクト管理に用いられます。
- deploygate: 開発中のiOS/Androidアプリを簡単にテスターや開発チームメンバーに共有することができます。弊社では、Androidアプリを社内配布するために、使っています。
- iTunes Connect: App Store上の情報、契約や支払い関係を管理できます。TestFlightという iOS アプリをテスターや開発チームメンバーに社内配布する機能も提供しています。
- Google Spreadsheets: Googleスプレッドシートとは、Google社が提供しているExcelのようなソフトです。リリースフローで、リリースノートを管理するために使っています。
リリースフロー改善では、fastlaneをメインツールにして、他のツールと連携しています。
改善前のリリース作業の違い
| iOSチーム | Androidチーム |
|---|---|
| fastlaneを使っている | バイナリをストアにアップする以外、fastlaneを使っていない。Bash scriptを使っている |
| ペアオペでリリースする | ペアオペでストア申請＋リリースする |
| git-flowはコマンドで管理する | git-flowはソフトで管理する(Sourcetree、 GitKrakenなど) |
→ AndroidチームとiOSチームはお互いのリリース作業の内容を知りませんでした。
リリースフロー
スケジュール
モバイルアプリチームはアプリを２週間に１回リリースしています。リリースフロー改善の前後でスケジュールは、このように変わりました👇
| 改善前 | 改善後 | |
|---|---|---|
| 金曜日 (リリース２週間前) | 翻訳依頼 (Androidのみ) | |
| 月曜日 (リリース１週間前) | コードフリーズ 翻訳依頼（iOSのみ） |
コードフリーズ＋翻訳依頼 |
| 火曜日 (リリース１週間前) | リリースノートの翻訳が終わったら、各言語用のファイルに取り込んで、PRを提出し、レビュー依頼をする | |
| 金曜日 (リリース１週間前) | ストア申請 | ストア申請 |
| 水曜日 | リリース | リリース |
ステップ
リリース作業のステップが４つあります。
1. リリースノート作成：リリースノートを準備したり、作成したりする
2. コードフリーズ： リリースするまで、不具合対応以外の対応をしないようにする
3. ストア申請：Google Play StoreやAppStoreにアプリを申請する
4. リリース：各ストアでアプリを公開する
今までの問題
- AndroidとiOSのリリースノートを作成するタイミングが違う
- Androidチームはコードフリーズする前にやる
- iOSチームはコードフリーズした後にやる
- AndroidとiOSチームはお互いのやり方を知らない
- 時間と手間がかかる
- 手動で作業するとミスすることがある。
- 各自のRubyのバージョンが違う
- たまーにgit-flowがおかしくなっている
- Windows環境でBash scriptが標準で対応されていない
どうやって改善するの？🤔
まずは、Bash scriptをやめます！あと、ミスをなくすために、ワンコマンドにして、出来れば全部をfastlaneで自動化します。各チームのリリース手順とタイミングが違ったので、タイミングを合わせるようにします。たまに、git-flowがめちゃくちゃになってしまうことがあったので、git-flowをfastlaneに任せます。最後は、みんなのローカル環境のライブラリバージョンを管理するために、Bundlerというツールを使います。
Bundlerとは
Gemfileをみて、Rubyのライブラリのバージョンを管理するツールです。
gem "fastlane", '2.147.0'
☝️を入れたら、みんな同じバージョンのfastlaneを使うようになります。
改善した後
リリースノート作成するタイミングを合わせるためにiOSチームとAndroidチームに相談し、「リリースノート作成」と「コードフリーズ」の順番だけ変更しました。全体のステップは変わらないようにしています。
1. コードフリーズ
| iOS (Before) | Android (Before) | Android / iOS (After) |
|---|---|---|
 |
 |
 |
改善前
iOSチームはまず、gitのリリースブランチを作り、各言語のリリースノートを確認するためにPRを出します。確認出来たら、リリースのブランチにマージしてから、社内配布しました。それに対して、Androidチームではgitでリリースのブランチを作り、GitHubのリリースドラフトを作ってから、社内配布していました。
改善後
リリースノートを準備するのはこのステップでやっていきます。社内配布時には、日本語のリリースノートのみで十分なので、まずこれを準備します。その後リリースブランチを作成し、GitHubのリリースドラフトを作ります。リリースノートの翻訳依頼をする前に、プロダクトマネージャー（PdM）に日本語のリリースノートの確認を依頼し、社内配布します。PdMから🙆♂️「OK」もらったら、翻訳依頼をします。
手順が全然違いましたが、改善後は統一されました。
👇 のワンコマンドを実行すると、この４つのステップを自動的におこないます。「日本語のみのリリースノート準備」が自動化されていない理由は、リリース担当者が対応されたチケットを見ながらリリースノートを書くため、自動化することができません。また、「翻訳依頼」が自動化されていない理由は、弊社のルールとして、PdMから🙆♂️「OK」をもらってから翻訳依頼を出すからです。
$ bundle exec fastlane code_freeze
翻訳依頼
モバイルアプリチームでは、リリースノートを管理するために、Google Spreadsheetを使っています。理由は、fastlaneで自動的にGoogle APIから各言語のデータを取ってきて、リリースノートを作成することができるからです。PdMがNGを出した場合、「×」になっており、fastlaneでリリースノートを作成しようとするとエラーがでます。PdMがOKを出した場合、「◯」になり、リリースノートが作成出来るようになります。
2. リリースノート
| Android / iOS (Before) | Android / iOS (After) |
|---|---|
 |
 |
このステップでは、各言語のリリースノートを作成して、チームメンバーにレビュー依頼するだけです。
全部fastlaneで自動化出来るので、👇 のコマンドを実行すると、自動的にリリースノートが作成されます。
$ bundle exec fastlane release_note
3. ストア申請
| iOS (Before) | Android (Before) | Android / iOS (After) |
|---|---|---|
 |
 |
 |
iOSチームでは、ワンコマンドで申請できていましたが、Androidチームではできていませんでした。改善後は、Androidも👇 のワンコマンドを実行すると、fastlaneがアプリをビルドし、作成されたバイナリをストアに自動でアップされるようになりました。
$ bundle exec fastlane submit
4. リリース
| Android / iOS (Before) | Android / iOS (After) |
|---|---|
 |
 |
このステップで、Gitのリリースブランチを終了し、Jiraのステータスをリリースに変更します。その後、GitHubのreleasesのdraftをリリースし、PdMに「リリースしました！」というメッセージを送ります。
改善後は、👇のワンコマンドで全部自動でリリースされるようになりました。
$ bundle exec fastlane release
改善のときに苦労したところ
fastlaneでは、Rubyを使う必要があったのですが、Rubyの開発経験がなかったので勉強しないといけませんでした。そして、fastlaneからいろんなツールと連携していたため、APIトークンやAPIキーなどをローカル環境に設定する必要がありました。
あと、本番環境で確認するのはNGなので、各サービスのテストアカウントを作らないといけなかったです。改善後のリリース手順とコードを共有するために、全員にレビューしてもらって、修正がある場合、両方のチームのファイルを修正しないといけないところが、大変でした。😅
改善した効果
リリース作業の時間がほぼ70%短縮！
| ステップ | Before (作業時間) | After (作業時間) |
|---|---|---|
| コードフリーズ＋リリースノート | 2.0h | 0.3h |
| ストア申請 | 0.5h | 0.2h |
| リリース | 0.5h | 0.2h |
| トータル | 3.0h | 0.7h |
Hotfixの場合？
| やること | fastlane | 備考 | |
|---|---|---|---|
| 不具合発覚 | コードフリーズ | fastlane code_freeze | hotfix ブランチが作られる |
| 修正作業開始 | hotfix ブランチから feature ブランチを作成 | ||
| 修正完了 | リリースノート用意 | PdM確認 | |
| アプリ審査提出 | リリースノート準備 | fastlane release_note | レビュー後 hotfix ブランチにマージ |
| 審査提出 | fastlane hotfix | hotfixブランチ終了、審査提出、社内配布 | |
| リリース | リリース作業 | App StoreかGoogle Play Store でリリース |
👇のワンコマンドでhotfixがリリースされるようになりました。
$ bundle exec fastlane hotfix
まとめ
fastlaneはとても便利なツールですが、改善後のリリースフローを考えるのは大変でした。 ワンコマンドだと、すごく楽になってみんな喜んでくれました。また、自動化したためミスがほとんどなくなりました。😃
みなさんもリリースフローを改善してみませんか？
リンク
弊社ではモバイルアプリチームの仲間も絶賛募集中です！私たちと一緒にリリースフローを改善しながら、アプリの機能開発をやりませんか？😃 recruit.chatwork.com
