Jenkinsを使ったiOSアプリビルド自動化10 ビルドとテストの基礎まとめ

Jenkinsを使ったiOSアプリ開発へのCI導入のうち、標準的な構成のアプリのビルドの自動化、テストの自動化についての説明が完了したので、一度ここでまとめておきます。

Jenkinsの導入はそこまで難しくない。少なくともここまでは。

今まで見てきたようにプラグインがとても充実しているので、標準的な構成のプロジェクトであれば導入は比較的簡単です。後に説明するようにUnity等を使っている場合は一筋縄ではいきませんが、そうでない場合はJenkinsの導入コストを懸念するべきではないでしょう。

自動化を前提とした開発への頭の切り替え

問題はこれからで、単にJenkinsを導入してアプリのビルドとテストを自動化しただけでは、実際のところチームの生産性は多分変わりません。大事なことは、自動化を前提とした開発フローに切り替えることです。Jenkinsに任せられることは任せ、任せられない創造的な仕事にリソースを集中させて、はじめて生産性の向上が見られるようになっていきます。

改めて考える、エンジニアにとってのJenkinsを導入するメリットについて

待ち時間の削減、ペースの維持

ビルドやテストには待ち時間がつきものです。ビルドやテストをJenkinsに任せれば、その間に自分の作業環境のリソースをとられることもないですし、テスト失敗時に通知をするように設定しておけばテスト結果を目で毎回チェックする必要もなくなります。また、中途半端な待ち時間で作業のペースを崩されることもありません。
最低限のテスト・チェックだけローカルで行ったら、時間のかかる通しのテスト等はJenkinsに任せて、ペースを崩さずに次の作業に取りかかることができます。あるいは自分のペースで休みをいれるのも良いでしょう。

集中力の節約

開発は創造性が求められる作業ばかりではありません。ビルド、テスト、デプロイ、リソースの更新、ドキュメントの更新…これらの作業は基本的には誰がやっても大きな差はでず、同時にミスがあってはいけない作業です。
一日にエンジニアが費やすことができる時間と集中力は(おそらく)有限です。こういった作業にエンジニアの集中力を費やすべきではありません。こういった作業は徹底的にJenkins等を使って自動化し、エンジニアはもっと創造性の求められる作業に集中力を使い、よい成果をだすべきです。

ミスの削減

人間は必ずミスをしますが、コンピュータは基本的にミスをしません。また、さぼったり体調を崩すこともありません。

作業の非属人化

Jenkinsのジョブは誰が実行しようが結果は同じです。ルーティンワークのマニュアルを作って他の人に任せるより、一度ジョブを設定したらそれを実行するだけにしておいたほうが、共有のコストも圧倒的に小さくなります。
つまり、エンジニアの限られた資源(時間、集中力、創造性)を有効活用し、逆にそれらを浪費する作業を徹底的に削減する、というのがJenkinsをはじめとするCIツール・自動化ツールの導入によって目指すべきところだと僕は考えています。

ノンエンジニアへの影響

エンジニアに頼らなくても自分に必要な色々な作業ができるようになること、そのための環境設定等を行わなくてよいこと等、Jenkinsの導入によるメリットはノンエンジニアの人たちにも関係があります。このあたりのメリットについては、デプロイやデバッグ・テストにおけるJenkinsの活用方法を見ていった後でまた説明していきます。

とはいえ実践はなかなかうまくいかない

と、ここまでは良いことばかり書いてきましたが、実際にはまだ技術的な問題に悩まされることも少なくありません。Native Code Pluginを使うようなUnityアプリケーションは自分で複雑なスクリプトを書かなければビルドの自動化ができませんし、テストに関するポストでも触れてきたように自動テストがカバーできる範囲は限られています。
これらの問題を超えていく方法はありますが、難易度は低くなく、ある程度コツが必要です。既存のプロジェクトに後からJenkinsを導入していくような場合では、苦労する場面、思い通りに行かない場面が多いと思います。プロジェクトの構成、仕様がJenkinsでできることとマッチしないことが多々あるからです。
一方で、あらかじめプロジェクトの最初の段階からJenkinsによるCI、諸々の作業の自動化を頭に入れて設計・開発を進めていけば、難易度はぐっと下がります。前述した通り、Jenkins導入による生産性の向上を最大化させるためには、Jenkinsを前提とした開発フローを頭に描いてプロジェクトを進めていく必要があります。
Jenkinsを前提とした開発フローはチームメンバー各々が描けていないといけません。チームの中にはJenkinsの導入に魅力を感じないメンバー(Jenkinsを信頼していないメンバー)、自分の今までの作業スタイルを急にかえたくないというメンバーがおそらくいます。また、「Jenkinsをどこで活用できるか」という感覚が生まれるまでは、新しいメンバーはなかなかJenkinsを活用できないでしょう。せっかくJenkinsのジョブを用意しても、それが活用されなければ効果はでません。
チーム全体で活用できれば、その効果は確実に大きいと思いますが、道のりがある程度険しいことは覚悟しておいた方がいいでしょう。

導入例

参考程度に、僕自身が関わっているプロジェクトでJenkinsを活用している場面をいくつか紹介しておきます。

最新版を自動的にTestFlightにアップロードして、社内での確認用にディレクターやテスターがいつでもインストールできるようにする。
安定版ができたタイミングでクライアントさんの動作確認用のビルドをTestFlightへのアップロードする。
リソースファイルの更新を自動的に行う。(グラフィック・UI関連の変更の反映の自動化)
AppStoreにサブミットするためのipaを生成する。
Pull Requestの内容をチェックするためのテストを走らせる。
プロジェクト間での共通モジュールを一つのレポジトリで管理するようにして、変更があった時に別のプロジェクトに影響がないか、最新版に差し替えてみてビルド・テストする。
デバッグ・テストに必要な外部サービスのアカウントを自動で生成する。
外部サービスの状態をチェックする。(これはJenkinsじゃなくてもいいんだけど)

いくつかの項目については、今後時間があれば具体的な手法を紹介していきたいと思っています。

Pocket