Mercari Advent Calendar 2017 の21日目はメルカリ カウルチームのiOSエンジニアの@motokieeがお送りします。
はじめに
メルカリ カウルは今年の5月のローンチしたエンタメ専用のメルカリ姉妹アプリです。立ち上げから半年ほどが経過し、日々サービスの改善を続けています。
iOS版メルカリ カウルはこの7ヶ月で30回アップデートしており、ほぼ週に一度はアップデートしていることになります。もちろん規則正しく週1でリリースをしているわけではないのですが、開発サイクルの速さがお分かりいただけるのではないでしょうか。
現在メルカリ カウルのiOS版はほぼ1人で開発をしています(自分の他にもう1人iOSエンジニアはいるのですが、PJの都合上BIがメインの業務となっています)。
少ない人数でも改善を続けることができているのは、メルカリエンジニアの行動指針の1つであるAutomation, Karakuri
に基づいて開発に関わる業務を効率化をしているからです。
今回はiOS版メルカリ カウルの高速アップデートを支えているAutomation, Karakuri
についてご紹介いたします。
ビルドの配布
メルカリをはじめ、メルカリ アッテ、メルカリ メゾンズのiOSのCIは主にBitriseが使われていて、メルカリ カウルのiOS版も同様にBitriseを使用しています。
BitriseではTriggerごとに1つのWorkflowを実行することができます。
WorkflowでFabricへのアップロードやSlackへの通知などのタスクを順番に実行するように設定を行います。
作成したWorkflowにTriggerを設定することができます。Triggerごとに1つのWorkflowを実行できます。
メルカリ カウルでは以下の3つのWorkflowを定義しており、Triggerに応じて必要なビルドが配布されるようにしています。
unit-test
archive-qa
ready-for-submission
unit-test
は文字通りユニットテストを実行します。このWorkflowはPull Requestトリガーで実行され、ユニットテスト実行後にその結果をSlackに通知しています。
archive-qa
ではFabricへのアップロードを行います。master
ブランチにpushがあると実行されます。master
マージ後開発メンバーはすぐに新しい機能を確認できます。
最後のready-for-submission
はrelease/*
ブランチへのpushトリガーで実行されます。FabricへのアップロードとiTunes Connectへのアップロードを同時に行います。検証用のビルドとリリース用のビルドが同時に必要な場所にアップロードされるので、QA完了後すぐにサブミットすることが可能です。
開発メンバーへの連絡
リリース候補のビルドは、Bitriseを使って開発メンバーがいるチャンネルとQAチームのチャンネルにSlackで通知しています。
目的は以下の通りです。
- iOSのサブミットが近づいていてリリースに向けた準備が必要なことの周知
- QAチームにリリース候補がアップロードされたことの連絡
前者は新規APIのリリースをiOSのサブミットまでに終わらせておかなければならないことがあるような場合に有用です。開発メンバー間でスケジュールの把握がうまくできていないこともあるので、その予防策を仕組みとして用意しています。
後者は修正版が上がるタイミングとその連絡をQAチームに同時に行うためのものです。以前は手動で連絡していました。
しかしサブミットが近づいてくると、QAで見つかったバグの修正などでどうしても更新が必要になります。
連絡を手動で行っているとQAチームは修正版の連絡を待たなければいけませんし、連絡する側もビルドがいつ終わるのかを気にしていなければならないため、気が付かないうちにかなりの時間を無駄にしてしまいます。
個別のチャンネルに流すことで、QAチームは新しいリリース候補のビルドをすぐに把握でき、開発メンバーもビルドがいつ終わるのかを気にせず別のことに集中して取り組むことができます。
iTunes Connectのmetadata更新
App Storeのリリースノートを始めとしたメタデータの更新はiTunes Connectの管理画面から更新することが多いと思いますが、これをリポジトリで管理してBitriseから更新しています。
Bitriseはfastlaneを使ってiTunes Connectにアップロード行うのでfastlaneの機能を使用することができます。
メタデータをリポジトリで管理すると以下のようなメリットがあります。
- リリースノートや検索キーワードがgit管理できる
- アップデート文言をPull Requestで確認できる
diffを見れるようになったので前回どのような文言だったのか把握しやすくなりました。この修正を忘れる可能性もあるのですが、次に説明するDangerを使ってリリース前に更新が必要なことに気がつけるような仕組みを用意しています。
忘れがちなことをDangerで気づく
Dangerはコードレビューを自動化するためのツールです。Dangerfile
に記述したルールをCIで実行してGitHubにコメントを残すようにしています。
先程のリリースノートの更新を忘れを防ぐために、release
ブランチのPull Request時にリリースノートの更新が含まれていない場合、GitHubにwarningが表示されるようになっています(リリース時にrelease/*
からmaster
へのPull Requestを作成するので、そこでチェックが通るようにしています)。
Dangerfileには以下のように記述しています。
active_files = (git.modified_files + git.added_files) warn "Please update fastlane/metadata/ja/release_notes.txt" if github.branch_for_head.start_with?("release") && !active_files.include?("fastlane/metadata/ja/release_notes.txt")
この他に開発のために一時的に変更したAPIの向き先の戻し忘れ、wikiの更新が必要なファイルを変更した際に警告を出すなど、人が忘れがちなことをDangerに設定するようにしています。
iTunes Connectのステータス変更監視
iOSの新しいバージョンをリリースする際、チームメンバーへの周知をしているかと思いますが、これも自動化しています。以前はサブミットとリリースのタイミングで手動でSlackに投稿していました。
リリースの頻度が数週間に一度くらいであればそこまで必要ないのですが、週1くらいでやっていたのでさすがに面倒になりました。現在はGoogle Apps ScriptでiTunes Conenctのステータスのメールを定期的にチェックしてSlackに通知するようにしています。
iTunes Conenctのステータスのメールが届かず困っていたのですが、これを受け取るには iTunes Connect ユーザ > 通知 > App ステータスレポート
からテリトリを指定する必要がありました。
サブミットとリリースだけでなく、ステータス変更ごとにSlackにpostするようにしているので、審査にどの程度時間がかかったのかも把握しやすくなりました。
おわりに
一部ではありますがメルカリ カウルのiOS開発環境のAutomation, Karakuri
についてまとめました。
小さなタスクの一つ一つは大きな手間ではないのですが、週に一度リリースをするようなサイクルだと積み重なって大きな手間になってしまいます。
今回はご紹介できませんでしたが、メルカリ カウルではiOSに限らず多くの自動化を行っています。各職種のメンバーがAutomation, Karakuri
を進めて業務を大きく効率化しています。
機械にできることは機械に任せることで、人間にしかできない本質的なことに時間をかける環境を整えています。
明日 22 日目はそのZapierについて @tadashi0713 が詳しくまとめます。ぜひ読んでみてください!
Mercari Advent Calendar 2017も終わりが近づいてきましたが引き続きお楽しみください。