ビルドプロセスとci #stac2014
TRANSCRIPT
自己紹介• @nowsprinting
• フリーランス(iOS/Androidアプリ受託開発)
• テスト自動化研究会、Androidテスト部、VR部
• アプリ『山吹色の茸疾走』『フットサル ルールと雑学』『電エースQuiz - 河崎実監督と特撮映画の世界』
• 著書『システムテスト自動化 標準ガイド』(共訳・共著)『iOSアプリ テスト自動化入門』『Androidアプリ テスト技法』(共著)
• 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• 継続的インテグレーション
• 自動化されたビルドプロセス(Integration)を 繰り返し・継続的に(Continuous)実行する
• CIツール/サービス
• Jenkins, CloudBees, Travis CI, Circle 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/
テストウェアアーキテクチャ
• テストウェアを
• どこに格納し、利用するか
• どのようにグループ化し、参照するか
• どのように変更し、保守するか
5.1「テストウェアアーキテクチャとは何か」より
なにが問題になるか• 規模(ファイルの数が多い)
• 再利用性(建て増し旅館)
• 複数のバージョン(製品のバージョンとの同期)
• プラットフォームと環境からの独立(動作環境ごとにテストウェアのコピーを作るのか)
5.2「カギとなる4つの課題」より
ツールで解決できるもの• 規模(ファイルの数が多い)
• 再利用性(建て増し旅館)
• 複数のバージョン(製品のバージョンとの同期)
• プラットフォームと環境からの独立(動作環境ごとにテストウェアのコピーを作るのか)
5.2「カギとなる4つの課題」より
複数のバージョン(2/3)
• 「テスト資料」は、バージョン管理システムで管理
• 例えば、テストコード、テストデータ(SQL)、テーブル定義、比較用の出力データ(期待結果)、サーバ構成定義、VMイメージ
前処理• 生成・・・・DBへのデータ投入など
• チェック・・テスト実行環境のチェック (自動実行できない前提条件・環境のチェック)
• 再配置・・・ファイルの移動など
• 変換・・・・zipの展開など
6.2「前処理と後処理」より
後処理• 削除・・・・不要な生成物の削除
• チェック・・テスト出力の事後チェックなど (スクリプト内でチェックできない場合)
• 再配置・・・ファイルの移動など
• 変換・・・・zipへの圧縮など
6.2「前処理と後処理」より
前処理/後処理の自動化• なぜ自動化が必要なのか
• テスト実行環境の再現性
• 繰り返しテスト実行に耐えるように
• 実装は、スクリプト(6.4.2)、コマンドファイル(6.4.3)、もしくは専用のビルドツール
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などのツールを利用する
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/