iOSアプリ自動リリース：fastlane/Bitrise編
どうもこんにちは.
VoicyのiOSエンジニア, mishima(@tihimsm)です.
前回の概要編に引き続き, 本シリーズ第二夜目でございます.
前回からかなり時間が空いてしまったのですが, 他業務に追われていたのと同時に, 実はCI周り(主にfastlane)も大きく修正しておりました.
今回は弊CIの要であるfastlaneとBitriseの構成についてお話したいと思います.
対象読者
・fastlane/Bitriseはなんとなーくどんなものか知ってるよって人
・Configurationで環境切り替えたい人
・CI化されてないことで精神が荒んでしまっている人
・この記事の不備やイケてない部分にFBをくれる人 ← 最重要
目次
- CI環境整理以前の問題点
- CIでやったこと概要
- fastlaneの設定
- Bitriseの設定
- CI化後の効能
- 次回予告
CI環境整理以前の問題点
CI環境を整える前に, 現環境の問題点を洗い出しました.
iOS開発熟練の方々からは
え? そんなことしてたん? マジで言ってる?
と思われてしまうかもしれませんがご容赦ください.
- Production/Staging/DevelopmentのAPI切り替えをGitブランチごとにコメントアウトで切り替えていました.
下記のようなイメージだと思ってもらえると…
- 環境による内部処理の切り替えをbuild番号にルールを設けて切り替えてました.
build番号が0.1ならDevelopment, x.9ならStaging, x.0ならProduction
というルールで, ざっくり下記のような感じで環境を判定していました.
上記のように運用をしていると, ブランチを切り替える度に, build番号の確認やAPIの向き先確認を行わなりません.
せっかくデプロイを自動化しても, StagingやMasterへのマージでミスをする可能性が多分にありました.
あと精神衛生上非常によくありません!
iOS開発チームの健康増進のため, 私は上述の問題に立ち向かうことを心に固く誓い, CI化を粛々と進めました.
CIでやったこと概要
- Xcode上でConfigurationの定義(こちらの記事を参考にさせていただきました. 本記事では細かい設定方法は割愛させていただきます.)
- fastlane match/Github Teamによる証明書の管理(こちらは次回配信の証明書編で別途公開させていただきます.)
- fastlane/Bitriseによりlane毎に環境切り替え
- fastlane scanによる自動テスト(ここはまだがっつり整えられてはいないので, 公開未定)
ここから先は詳細を
1. fastlaneの設定
2. Bitriseの設定
の順にFabricでのAdHoc配信を例に記述していきます.
fastlaneの設定
まずは結果から.
matchでadhoc用証明書を取得automatic_code_signingでManual Signingに変更run_testsでテスト実行build_ios_appでアプリをbuildcrashlyticsでFabric betaへAdHoc配信slackで完了メッセージ送信
このように, 証明書の管理からslackに通知まで一連の動作を全てfastlaneにロックインしています.
理由としては
・Bitriseの開発中止の可能性はありそうだけど, fastlaneは中止にはならなさそうなこと
・Bitrise以外のCIサービスへの乗り換えも有り得ること
・fastlaneにロックインしておくと他アプリへの転用が楽なこと
の3点です.
この辺りは意見分かれそうなので参考程度にお願いします.
Bitriseの設定
fastlaneに処理を寄せてしまっているので, ここの設定はとても簡単です.
BitriseのUI自体もとてもわかりやすいので, 僕のようなCI環境構築初心者でも簡単にポチポチできました.
ものすごく大雑把に分けるとBitriseで行うことは
・workflowの設定
・トリガーの設定
・環境変数の設定
の3つです.
ということでまずworkflowの設定が↓です.
簡単ですね?
fastlaneでまかなっている証明書の管理や, slackの通知などをBitriseで行うこともできますが, そうするとBitriseに証明書のアップロードなどをする必要があり, やや面倒です.
また, 概要編でもちらっと描きましたが弊社ではAcHoc配信を
developブランチにPRを出しているブランチにpushされたとき
に行っています.
その設定をWorkflow -> Trrigersで行います.
それが↓です.
簡単ですね?
ちなみに, Staging配信やAppStoreへの配信は↓です.
簡単ですね?
Appstore配信はmasterへのpushをトリガーにしています.staging配信はrelease/で切られたブランチにpushされたときをトリガーとしています.
そして最後にCRASHLYTICS_API_TOKENなどの環境変数の設定ですが, こちらは Workflow -> Secrets 内で設定可能です.
簡単ですね?
このようにしてfastlane/BitriseそしてConfigurationの設定により, デプロイのCI化が実現され, 我々の開発ライフが健康的なものになりました.
CI化後の効能
このCI化により本当に, 今夜もよく眠れるようになったのか, 検証していきましょう.
・Production/Staging/DevelopmentのAPI切り替えをGitブランチごとにコメントアウトで切り替えていました.
・環境による内部処理の切り替えをbuild番号にルールを設けて切り替えてました.
-> 上記2点無事解決されました.
XcodeでConfigurationを作成し, fastlane内でlane毎にビルド時のConfigurationを指定してやることで, APIの向き先の切り替えおよびbuild番号にルールを設ける必要がなくなりました.
また, 弊社ではFirebaseを使っているのでGoogle-Info.plist や, GoogleSignInに必要な reversed client ID なども環境ごとに切り替えが必要で, その辺りもやっております. (需要あれば今度この辺も書こうかなー)
そしてこれにより
上記のように運用をしていると, ブランチを切り替える度に, build番号の確認やAPIの向き先確認を行わなりません.
せっかくデプロイを自動化しても, StagingやMasterへのマージでミスをする可能性が多分にありました.あと精神衛生上非常によくありません!
我々の精神を健康に保つことにも貢献できましたね.
次回予告
これだけやっても, まだ大きく健康に害を及ぼしているものが解決されてませんね...
そう, 開発者証明書の管理です.
たしかにAdHoc配信やAppStore配信の証明書周りはfastlaneで解決していますが, 開発者が増える度に証明書登録するの辛すぎませんか?
次回はこの課題の解決について書いていこうと思いますので, 乞うご期待.
