ビルドプロセスとCI

2014.12.14 #STAC2014 at Yahoo! JAPAN @nowsprinting / Koji Hasegawa

自己紹介• @nowsprinting

• フリーランス（iOS/Androidアプリ受託開発）

• テスト自動化研究会、Androidテスト部、VR部

• アプリ『山吹色の茸疾走』『フットサル ルールと雑学』『電エースQuiz - 河崎実監督と特撮映画の世界』

• 著書『システムテスト自動化 標準ガイド』（共訳・共著）『iOSアプリ テスト自動化入門』『Androidアプリ テスト技法』（共著）

著書

第14章『CI』担当

• Android Bazaar and Conference 2014 Winter http://abc.android-group.jp/2014w/ 12/21（日） 10:00～18:00東海大学高輪キャンパス（東京都・品川）

• 【VR部屋】タオバイザー(Cardboard)ハンズオンhttps://atnd.org/events/60117

アジェンダ

• ビルドプロセス、CIの概要（本日お話する範囲）

• テストウェアアーキテクチャ（STA第5章）

• 前処理と後処理の自動化（STA第6章）

• ビルドパイプラインの事例

ビルドプロセス、CI

“ビルド”の定義• 狭義のビルド

• 製品のコンパイル、リンケージ、パッケージング

• 広義のビルド

• 自動化されたテストの実行

• 各種テスト環境へのデプロイ（配備）

• 商用環境へのデプロイ、リリース

CI• 継続的インテグレーション

• 自動化されたビルドプロセス（Integration）を 繰り返し・継続的に（Continuous）実行する

• CIツール/サービス

• Jenkins, CloudBees, Travis CI, Circle CIなど

CIツール/サービスを使えばCIと言える?

“ハンマーを持つ人には すべてが釘に見える”

“If all you have is a hammer, everything looks like a nail.”- Abraham Harold Maslow

http://www.wwezone.org/wwe/triple-h/page/8/

数年前…

©BeeworksGames

同じ過ちを繰り返さないために 『システムテスト自動化

標準ガイド』 から知見を得ましょう！

テストウェア アーキテクチャ

テストウェア• 自動・手動の区別なく、テストに関わる作成物

• テスト資料

• ドキュメント、データ、スクリプト、入力、期待結果

• テスト結果

• 実際の出力、ログ、ステータス、比較レポート

テストウェアアーキテクチャ

• テストウェアを

• どこに格納し、利用するか

• どのようにグループ化し、参照するか

• どのように変更し、保守するか

5.1「テストウェアアーキテクチャとは何か」より

なにが問題になるか• 規模（ファイルの数が多い）

• 再利用性（建て増し旅館）

• 複数のバージョン（製品のバージョンとの同期）

• プラットフォームと環境からの独立（動作環境ごとにテストウェアのコピーを作るのか）

5.2「カギとなる4つの課題」より

ツールで解決できるもの• 規模（ファイルの数が多い）

• 再利用性（建て増し旅館）

• 複数のバージョン（製品のバージョンとの同期）

• プラットフォームと環境からの独立（動作環境ごとにテストウェアのコピーを作るのか）

5.2「カギとなる4つの課題」より

規模（1/2）• 「テスト結果」のうち、実際の出力、ログなどについてはCIツールに任せる

規模（2/2）• CIツールのレポート機能で、失敗したテストだけを視認し、調査できる

複数のバージョン（1/3）

• 緊急修正を行なった際の回帰テストで、どのバージョンのテストセットを実行すべきか

• インクリメンタルな開発・テストでは、どのテストセットを実行すべきか

複数のバージョン（2/3）

• 「テスト資料」は、バージョン管理システムで管理

• 例えば、テストコード、テストデータ（SQL）、テーブル定義、比較用の出力データ（期待結果）、サーバ構成定義、VMイメージ

複数のバージョン（3/3）• Git-flowなど、ブランチやタグの運用ルールを導入する

• テスト実行環境の再現性を得るために

➡サーバ構成管理ツール、仮想マシンの活用

ほかの課題に対して

• 5.3「取り組み方」に、以下のようなヒントがあります

• テストセット、データセットといった論理構造

• 物理的構造、命名規約

前処理と後処理の 自動化

前処理と後処理

• テスト実行の前処理、後処理

• 前処理・・・生成、チェック、再配置、変換

• 後処理・・・削除、チェック、再配置、変換

6.2「前処理と後処理」より

前処理• 生成・・・・DBへのデータ投入など

• チェック・・テスト実行環境のチェック　（自動実行できない前提条件・環境のチェック）

• 再配置・・・ファイルの移動など

• 変換・・・・zipの展開など

6.2「前処理と後処理」より

後処理• 削除・・・・不要な生成物の削除

• チェック・・テスト出力の事後チェックなど　　　　（スクリプト内でチェックできない場合）

• 再配置・・・ファイルの移動など

• 変換・・・・zipへの圧縮など

6.2「前処理と後処理」より

後処理の補足• 「削除」「再配置」は、極力「前処理」で行なうほうが、安定します

• テストが異常終了したとき

• バージョンを切り替えたとき

• ログなど、CIツールに任せればよいものは任せる

前処理/後処理の自動化• なぜ自動化が必要なのか

• テスト実行環境の再現性

• 繰り返しテスト実行に耐えるように

• 実装は、スクリプト（6.4.2）、コマンドファイル（6.4.3）、もしくは専用のビルドツール

ビルドツール• Make、Rake、Ant、Gradle など

• ライブラリ依存関係の解決

• タスク単位（狭義のビルド、テスト実行など）でのスクリプト記述

• タスクの前提条件を考慮した実行

（改めて）CI

CIの定義とメリット• ビルドプロセスを、少なくとも1日1回、理想的にはバージョン管理システムへのチェックインごとに自動実行する

• バグの作り込みを、早期に検出できる

• メトリクスの採取、通知（チャットやメール）などとの連動

Jenkins

• http://jenkins-ci.org

• 自前の筐体にインストールして起動するタイプ

• 操作、管理はWebブラウザから可能

• 豊富なプラグインで拡張できる

CloudBees

• https://www.cloudbees.com

• Jenkinsのホスティングを提供するサービス

• プラグイン等、Jenkinsの利点はそのまま

Travis CI• https://travis-ci.org

• GitHub上のリポジトリを対象としたCIを提供

• WorkerにMac OS Xがあり、iOSでも利用可能

• 実行環境自体がImmutableで、ビルドの定義はYAML形式のファイルで指定できる

Travis CIの例

• Androidアプリの例 『システムテスト自動化 標準ガイド』14.1に掲載されています

• iOSアプリの例『iOSアプリ テスト自動化入門』7.3に掲載されています（サンプルコードはGitHubにあります）

ビルドパイプライン

ビルドパイプライン• テストレベル（結合度）ごとに順番に実行する

• フィードバックを素早くする効果

• STA 9.2「どのテストをいつ実行するか」

• 各種テスト環境へのデプロイ（配備）

• 自動テストをパスしたら、次の工程に進む

• 手動トリガーで次工程をキック

ビルドパイプラインの実現

• Jenkinsのプラグインを利用するBuild Pipeline Plugin、Delivery Pipeline Plugin

• ビルドスクリプトで組む

• Walterなどのツールを利用する

Build Pipeline Plugin

Delivery Pipeline Plugin

Walter• https://github.com/walter-cd/walter

• Go製のパイプライン実行ツール。YAML形式でパイプラインを記述し、実行できる

ビルドパイプラインの事例

前提• BtoBtoCのスマートフォンアプリ

• 弊社はシステムテストまで。顧客で受け入れテスト

• ビルドターゲットが複数（OEMなど）

• ビルドコンフィグも複数（サーバ接続先に応じて）

• Git-flowを利用

前提 - Git-flow• masterはリリースされているアプリの状態

• 開発中のコードはdevelop

• リリース候補はdevelopからrelease/1.1など

• 緊急修正はmasterからhotfix/1.0.1など

• アプリ等に向く（Web向き：GitHub Flowなど）

パイプラインの事例1. ユニットテスト、統合テスト（UI操作が中心）、

メトリクス採取

2. システムテスト

3. UAT・リリース向けに全ターゲットのビルド

4. DeployGateにアップロード

パイプラインの事例1. ユニットテスト、統合テスト（UI操作が中心）、

メトリクス採取

2. システムテスト

3. UAT・リリース向けに全ターゲットのビルド

4. DeployGateにアップロード

• UI操作のテストは、ユニットテストフレームワーク上で動作するもの（iOS: KIF, Android: Robotium）＋モックサーバで構築

• develop, release, hotfixブランチで実行

パイプラインの事例1. ユニットテスト、統合テスト（UI操作が中心）、

メトリクス採取

2. システムテスト

3. UAT・リリース向けに全ターゲットのビルド

4. DeployGateにアップロード

• 1の後、2を実行（ひとつのジョブ） • 当初、Frankでごくシンプルな機能テストのみ実装→OSバージョン問題で動かない

• OSのバリエーションをマトリクスで実行（予定）

パイプラインの事例1. ユニットテスト、統合テスト（UI操作が中心）、

メトリクス採取

2. システムテスト

3. UAT・リリース向けに全ターゲットのビルド

4. DeployGateにアップロード

• release, hotfixのとき実行 • Pythonのスクリプトで複数ターゲットxコンフィグのビルド

• BundleVersionなども自動設定

パイプラインの事例1. ユニットテスト、統合テスト（UI操作が中心）、

メトリクス採取

2. システムテスト

3. UAT・リリース向けに全ターゲットのビルド

4. DeployGateにアップロード

• 3の後、4を実行（ひとつのジョブ） • アップロードAPIをスクリプトから実行 • 以前はTestFlightを利用 • https://deploygate.com

パイプラインの事例1. ユニットテスト、統合テスト（UI操作が中心）、

メトリクス採取

2. システムテスト

3. UAT・リリース向けに全ターゲットのビルド

4. DeployGateにアップロード

パイプラインの事例1. ユニットテスト、統合テスト（UI操作が中心）、

メトリクス採取

2. システムテスト

3. UAT・リリース向けに全ターゲットのビルド

4. DeployGateにアップロード

パイプライン じゃない

構築のポイント

• 分割する意味のあるジョブだけ分割する（手動トリガーでキックしたい等）

• ブランチを利用する

• パイプラインにこだわらない

参考文献

まとめ

“ハンマーを持つ人には すべてが釘に見える”

“If all you have is a hammer, everything looks like a nail.”- Abraham Harold Maslow

http://www.wwezone.org/wwe/triple-h/page/8/

まとめ

• 基本は『システムテスト自動化 標準ガイド』

• テストウェアアーキテクチャ（第5章）

• 前処理と後処理の自動化（第6章）

• ツールに振り回されず、開発が捗るCI環境を！