Edited at

一休.com iOSアプリでのfastlane使用例

More than 1 year has passed since last update.

一休.comのレストラン事業部でiOSアプリのエンジニアをしている @hirosawak です。

普段の一休のアプリ開発で利用しているfastlaneの使用例を紹介します。

開発しているアプリはこちら


fastlaneとは

ネイティブアプリの面倒な作業を自動化するためのツールです。

導入方法 & fastlaneの説明は以下の記事がいい感じです。

https://qiita.com/gin0606/items/162d756dfda7b84e97d4


自動化している主な作業

を使って、


  • ライブラリ関連

  • リリース作業

  • Dangerによる簡易的なレビュー

などを自動化しています。

一つ一つ実際のレーンをご紹介していきます。


ライブラリ関連

iOSのライブラリ管理ツールは CocoaPods & Carthage の2つを使っています。

pod install + carthage update or carthage bootstrap が面倒なので2つまとめて実行するレーンを作っています。

特にCarthageのビルドに時間がかかるので、

carthage_cacheというフレームワークをs3に上げてキャッシュするツールを使っています。

fastlaneのプラグインもあるので、簡単に使用することができます。

これのおかげでチーム内で誰かがライブラリをビルドしていれば、

s3から落としてくるだけでビルドする待ち時間が減り、CIでのビルドも簡単になりました。

carthage_cache: https://github.com/guidomb/carthage_cache

fastlane plugin: https://github.com/thii/fastlane-plugin-carthage_cache


lane :update_library do
carthage_update
cocoapods
end

desc "Carthageを実行するレーン(carthage_cache)"
lane :carthage_update do
is_exist = carthage_cache_exist(bucket: BUCKET_NAME)
if is_exist then
carthage_cache_install(bucket: BUCKET_NAME)
else
carthage(platform: "iOS", cache_builds: true, use_binaries: false)
carthage_cache_publish(bucket: BUCKET_NAME)
end
end


リリース作業

バージョンのインクリメント関連は、プラグインのversioningを使います。

review_timeを入れて、レビューのだいたいの待ち時間も通知するようにしています。

  desc "App Storeへ提出するレーン"

lane :release do
# バージョン関連
increment_version_number_in_plist(version_source: APP_STORE)
increment_build_number(build_number: app_store_build_number)

# タグ付け
tag
match(type: APP_STORE)
deliver(
app_version: get_version_number,
force: true
)
slack(message: "アップロードが成功しました。レビューにかかる時間は、 約 #{review_time} 日程です。 :rocket:")
# テスト配信
crashlytics_beta
end


Dangerによる簡易的なレビュー

Dangerで指摘する主な項目は、


  • SwiftLintによるチェック

  • 変更が多いとPRを分けろと警告

  • WIPがついている状態だと警告

の三つです。

スクリーンショット 2017-12-16 18.06.46.png

指摘があった箇所にコメントをしてくれます。

# 修正範囲のみをコメント対象にする。

github.dismiss_out_of_range_messages

warn("WIPがついています。") if github.pr_title.include? "[WIP]"

# swiftlint設定
swiftlint.binary_path = "./Pods/SwiftLint/swiftlint"
swiftlint.config_file = ".swiftlint.yml"
swiftlint.lint_files inline_mode: true

# LGTM
lgtm.check_lgtm

参考にした記事: http://tech.connehito.com/entry/danger


課題


Dangerの指摘を細かくカスタマイズする

Dangerの記事をみてそのまま導入してみたが、自分たちのチームにはカスタマイズが必要だと思いました。

現状、BitriseのPRトリガーでDangerのレーンを走らせています。

とりあえずPRを作ってWIPでも ci skip をつけないとDangerが走ってしまい、いまいちな状況になってしまっているので今後解消していきたいです。


自動テスト

現在のプロジェクトでは、テストカバレッジが良くありません。

一応、Pushの度にテストを回してはいますが、テストの追加に手が回っていない現状です。

こうしたインフラ面を整えたので、積極的にテストに取り組んでいきたいと思っています。


布教

手元でテスト配信したいときに

テスト配信のレーンは作ってあるが、現状チームメンバーには使われていないので、まだまだチームメンバーへの説明が必要かなと個人的には感じています。


おわりに

デザイナーさんも利用してくれたり

スクリーンショット 2017-12-16 17.58.58.png

細かい指摘はDangerでやってくれたりするので、レビューに集中できたり

スクリーンショット 2017-12-16 17.45.32.png

チームメンバーが実際に使ってくれるようになり、fastlaneで作業の効率化ができるようになりました。

効率化によってアプリ自体の開発に専念できるように、今後も積極的に取り入れていこうと思っています。

明日は@kichionさんによる「あえてテクニカルなコーディングをしないという選択肢」です。