お元気ですか。Zaim の iOS エンジニアの watura です。
今日は、Zaim の iOS 版アプリの開発において CI（Continuous Integration：継続的インテグレーション）および CD（Continuous Delivery：継続的デリバリ）のシステムをどう構築し、活用しているのかを書いていきます。
まずは CI からです。現在、Zaim の iOS 開発では Bitrise と fastlane を中心に、一部 Jenkins を利用しています。
Bitrise - Mobile Continuous Integration and Delivery
かつての Jenkins CI 環境にあった三つの課題
Bitrise を採用する以前は、LAN 内にある MacBook Air にインストールした Jenkins だけで CI 環境を構築していました。しかしながら、これには以下のような課題がありました。
- 端末のメンテナンスが面倒
- パフォーマンスが悪い
- 外部からアクセスできないため Github などから hook できない
Bitrise 採用の決め手はマルチプラットフォームの料金
これらを解決するには、SaaS として使える CI ツールが必要だと判断し、いくつかを比較したところ、Bitrise と CircleCI が最終候補に残りました。
機能や使いやすさはどちらも同じくらい充実していたものの、最後の決め手は料金体系でした。
Zaim は iOS 版以外にも Android 版や Web 版が存在します。このため、プラットフォームとしては、いずれ Mac 以外の CI ツールを使うことを想定していました。CircleCI は Mac と Linux で料金が分かれていて別々に契約が必要ですが、Bitrise は同一契約内で済むようになっています。コスト面や管理面でのメリットが大きいとして、Bitrise を選択しました。
今であれば、マイクロソフトが今年の春頃にリリースした Visual Studio App Center を採用するのも手かもしれません。
Bitrise＋fastlane（＋Jenkins）に任せている四つの作業
iOS の CI および CD 作業全体としては、上記のようにして採用した Bitrise を使っています。
Bitrise にはさまざまなアクションを自動化する公式ステップがあり、ほとんどすべての作業は公式ステップの組み合わせで実現できます。ですが、 Bitrise にロックインされ、今後よりよいサービスが出てきた時に乗り換えられないという事態を避けたいと考えているため、基本的にはこうしたフローの制御は fastlane を使って実現するようにしています。
そして実は、Jenkins で実行している箇所も一つだけまだ残っています。早く引退してほしいのですが、まだまだ現役です。
これらのツールを組み合わせて、以下の作業を自動化しています。
- Danger の実行
- テストの実行
- DeployGate への配信
- App Store へのアップロード
（１）Danger の実行
Pull Request の簡易チェックツールである Danger を使って、Pull Request の一次確認を実行しています。
Danger は旧 CI マシンである Jenkins から起動しています。 Jenkins である理由は、「Pull Request の本文やタイトルに変更があった場合、そのコメント欄に "danger please" と書き込むことで、Danger に再チェックしてもらいたい。これは、今のところ Bitrise ではできない」 という事情があります。
例えば Zaim の iOS 版では「Pull Request のタイトルに必ず呼応する issue 番号を入れる」という内部ルールがあるものの、これは忘れてしまいがちです。やらかすと、Danger から以下のように怒られます。
タイトルを修正して即 Danger が再実行できればよいのですが、Bitrise でやろうとすると、空のコミットをプッシュする必要があります。Jenkins を使えば、コメント欄に「danger please」と記述するだけ。
Danger が動き出し、LGTM になります。明らかに便利です。
Github のコメントが Bitrise のトリガーになる方法があれば、Danger も Bitrise にしちゃいたいと思っています。
（２）テストの実行
次はテストです。Unit Test と UI Test を、Bitrise で実行しています。トリガーは Pull Request と develop ブランチの更新です。
これらのテストの実行には、fastlane scan を使っています 。ちなみに、Bitrise のような、シミュレータ の画面が見えない環境でも UI テストは動かせます。
（３）DeployGate への配信
ここからは CD の話です。まずは、本番にアップロードする前のテスト用アプリをどう社内に配布しているかについて説明します。Zaim では DeployGate を使っており、主に 3 種類のアプリを配信しています。
- Hourly：develop ブランチを更新するごとに配信
- Beta：1 日に 1 回 develop ブランチを配信
- Inspect：引数などで指定した特定のブランチやコミットを配信
（４）App Store へのアップロード
社内テストだけではなく、本番用の申請作業も簡単にしたいですよね。Zaim で App Store へのアップロードをツール経由でできるようにしたのは、ごく最近の 2018 年の 9 月からです。全体のフローがシンプルになって、めちゃくちゃ楽になりました。
以前のリリース作業は、
- Jenkins で App Store 用にビルドする
- ローカルにビルドされたアーカイブをダウンロードする
- Xcode でアーカイブを開き、App Store Connect にアップロードする
- リリースノートなどの各種メタデータを手動で書き込む
- iTunes Connect に申請する
という手順でした。それぞれは大変な作業ではありません。ただ、あいだに待ち時間があるため、途中までやって忘れてしまうことが多々ありました。
これを Bitrise 経由にすると、
- リポジトリ内にある各種メタデータを更新する
- Bitrise で App Store 用の Workflow を実行する
- iTunes Connect に申請する
という作業でリリースできるようになりました。時間がかかるのは「Bitrise で Workflow を実行」の待ち時間のみで、あとはすぐに完了します。また、App Store へアップロードが終わると App Store Connect からメールが届くため、まだか、まだかと Bitrise の画面を見る必要もありません。
また、事前準備として、リリースノートやアプリの詳細といったメタデータも Github で管理できるようになるようになりました。
とはいえ、そもそも DeployGate への配信や、App Store へのアップロードの管理は、CI を使おうが直接 Xcode でやろうが全体で見ると面倒な作業が多くありますし、権限管理も複雑になります。例えば、証明書や Provisioning Profile は Xcode に任せるのか、開発メンバーや CI で共通のものを作成するのか、それともそれぞれが作って管理するのか。Developer Portal へのアクセス権限はどれくらい必要なのかなど、考えなければならないことが多々あります。
Zaim では、こうした部分も fastlane を使ってシンプルに管理できるようにしています。この詳細については別記事で、まとめていきたいと思います。
さらなる CI/CD 環境の改善を目指したい
一連の流れで、かなり CI/CD は充実してきましたが、まだまだよくしたいと考えています。例えば、以下のようなことです。
- Bitrise の Workflow を Slack から楽に呼び出せるようにする
- 任意のブランチ、コミットを簡単にデプロイできるようにする
- ライブラリを自動アップデートできるようにする
こうした改善により、開発作業にさらに多くの時間を割けるようにして、効率的かつメンバーにとって心地よい環境を作っていきたいと思います。
Top comments (0)