1. 『継続的デリバリー』読書会
第３章
継続的ンテグレーション
大崎的デリバリー
@pinori

2. 3.2.1
始める前に必要なもの
1.
バージョン管理
• プロジェクトにあるものはすべて単一のバージョ
ン管理レポジトリにチェックインしなければならな
い
– コード
– テスト
– データベーススクリプト
– ビルド・デプロイメントスクリプト
アプリケーションの構築・インストール・実行・テストを行
う上で必要なものすべて
• どんな小さいプロジェクトでも

3. 3.2.1
始める前に必要なもの
2.
自動ビルド
• ビルドはIDEを使わずコマンドラインから実行
できるように
– CI環境からビルドプロセスを自動的に実行でき、
何か問題が起こったときに監視できるように
– ビルドスクリプトもテストし、リファクタリングする。
– これによって、ビルドの理解や保守、デバッグす
るのが容易になる。

4. 3.2.1
始める前に必要なもの
3.
チームの合意
• 継続的インテグレーションはプラクティスで
あって、ツールではない。
• 故に下記のような規律を開発チームに
– インクリメンタルな変更を少しずつこまめにチェッ
クイン
– 変更によってアプリが壊れたら、それを最優先で
修正

5. 3.2.2
基本的な継続的インテグレー
ション
• CIツール例
– CruiseControlファミリー
– Jenkins
(旧Hudson)
– Go
(Thought
Works
Studios社)
– TeamCity
(JetBrains社)
– etc.

6. 3.2.2
基本的な継続的インテグレー
ション
• 自分の変更のチェックインの準備が整ったら
1. ビルドがすでに実行されているかを確認。実行中で
あれば終了を待つ。失敗したら他のメンバと動くよう
に修正。
2. 開発環境のコードをバージョン管理の最新バージョ
ンで更新、他人の変更を取得。
3. 開発機上でビルド＆テスト。
4. バージョン管理に自分の変更をチェックイン。
5. CIツールがビルド＆テスト。
6. 失敗したら、即座に修正して3.へ。
7. 成功したら、次のタスクへ。

7. 3.3
継続的インテグレーションの前提
条件
• CIはプロジェクトの途中から始めようと思うと
多大な苦痛を伴いかねない。
• 始める前に次に上げるプラクティスを準備し
ておく必要がある

8. 3.3.1
定期的にチェックインせよ
• trunkやメインラインにこまめにチェックインす
べし（少なくとも１日に２回）
– 変更は小さくなり、ビルドを壊す可能性も低くなる
– 間違った場合にも、元に戻りやすい。
– コンフリクトの可能性も低くなる。
• ブランチを使いながらの本当の意味でのCIは
不可能
– ブランチは他の開発者と統合していないから

9. 3.3.2
包括的な自動テストスイートを作
成せよ
• ユニットテスト
– コードの振る舞いを個別にテスト
• コンポーネントテスト
– アプリ内のコンポーネントの振る舞いをテスト
• 受け入れテスト
– 受け入れ基準のテスト
• 機能、キャパシティや可用性、セキュリティ、etc.
– アプリ全体を擬似本番環境で起動した状態で実
行するのが望ましい

10. 3.3.3
ビルドプロセスとテストプロセス
を短く保て
• ユニットテストの時間が長いと…
– チェックイン前に手元でテストするのをやめてしま
う
– ビルド中に複数のチェックインが行われた場合、
どのチェックインで壊れたのか分からなくなる
– チェックインをこまめにやらなくなる
• できる限り短くすべき
– 10分が限界？

11. 3.3.3
ビルドプロセスとテストプロセス
を短く保て
• ビルド時間を減らすために
– まず、ユニットテストをより高速に
• さらには、テストプロセスを複数のステージに
分けることも
– コミットステージ（第７章でより詳細に）
• コンパイル
• ユニットテスト
– 受け入れテストステージ
• 受け入れテスト、etc.

12. 3.3.4
開発ワークスペースを管理する
• 一般的に開発環境は開発者のローカルマシ
ンに置いておくべき
• そのためには…
– 自動テストが通り、構成管理されたソースコード、
テストデータ、DBスクリプトなどを取得
– 構成管理されたサードパーティーのライブラリや
コンポーネントを取得
– 開発機上で自動テストが通ることを確認

13. 3.4
継続的インテグレーションソフト
ウェアを使用する
• 継続的インテグレーションソフトウェアのの最も基本的な機
能
– バージョン管理システムをポーリング
– コミットがあれば最新バージョンをチェックアウト
– ビルドして結果を通知
• ガジェットで最新のビルドステータスを様々なスタイルで表
示できるので、可視性あげよう
– ラバーランプとか音声読上げとか…
– ビルドの状態が一目瞭然になる
• ちなみに、ビルドの失敗はごく自然なこと
– 品質への問題の兆候ではない
– 顧客が近いと不安になるかもしれないので、ちゃんと説明すべ
し

14. 3.5
基本的なプラクティス
• 継続的インテグレーションはツールではなくプ
ラクティス
• 開発チームはかなりの規律を守る必要があ
る

15. 3.5.1
ビルドが壊れているときには
チェックインするな
• ビルドが壊れたら直ちに修正する
• 問題が修正されるまでチェックインはしない
• さもなければ、
– 問題がより複雑になり、修正により時間がかかっ
てしまう
– 壊れたままの状態に容易に慣れてしまう

16. 3.5.2
コミットする前に、常にローカルでコミットテストを実
行せよ あるいは代わりにCIサーバーにやってもらえ
• コミットする前にバージョン管理から最新版を取得した
上で、ローカルでコミットテスト
– ビルドを壊していないかローカルで気づける
– CIのコミットメントステージでのエラーは、チェックインし忘
れか、もしくはこの作業中に他人がチェックインしたか
• この作業を自動化できるものもある
– プレテストコミット、パーソナルビルド、プリフライトビルドな
どと呼ばれる
– Pulse、TeamCity、ElectricCommanderなどがサポート
– コミットテスト終わるのを待たずに次の作業を開始できる

17. 3.5.3
次の作業を始める前に、コミット
テストが通るまで待て
• チェックインしたら、ビルドの進捗を観察する
責任が生じる
• コミットテストに通るまで、作業を新しく開始し
てはならない
• ビルドに失敗したらすぐに対応すべし

18. 3.5.4
ビルドが壊れているのに、家に
帰ってはならない
• 修正するか、変更を取り消すか
• そのためにも、業務終了時間前のチェックイ
ンは避ける
– チェックインは翌日に持ち越すとか
– 万が一失敗しても対応できるように

19. 3.5.5
常に以前のリビジョンに戻す準
備をしておくこと
• 問題の修正に時間がかかるようであれば、
– レポジトリをリバート
– 問題の解決をローカルで

20. 3.5.6
リバートする前にタイムボックス
を切って修正する
• 例えば10分とか決めて、その間に修正できな
ければリバートする

21. 3.5.7
失敗したテストをコメントアウトす
るな
• 原因を突き止め、以下のいずれかの対応を
– コードを修正（リグレッションが見つかった）
– テストを修正（仕様が変更された）
– テストを削除（テスト対象が削除された）
• 一度許すとテストのコメントアウトだらけになり
がち

22. 3.5.8
自分が変更してビルドが壊れた
ら、すべてに対して責任をとれ
• 自分の変更は他人の書いたテストも通ること
– 通らなければ、そのテストも修正を
– そのためには、全員がコードベース全体にアクセ
ス可能であること

23. 3.5.9
テスト駆動開発
• ユニットテストのカバレッジが十分である必要
がる
– 素早いフィードバックのために
• そのためにはテスト駆動開発は必須
– お勧め本
• 『Growing
Object-­‐Oriented
SoTware,
Guided
by
Tests』
• 『xUnit
Test
PaXerns:
Refactoring
Test
Code』

24. 3.6
やったほうがいいプラクティス

25. 3.6.1
エクストリームプログラミング
（XP）の開発プラクティス
• 継続的インテグレーションは、XPのプラクティ
スのひとつ
• 他のプラクティスとの相性もよい
• 特にリファクタリング
– CIとテスト駆動開発でリファクタリング可能に

26. 3.6.2
アーキテクチャ上の違反事項が
あった場合にビルドを失敗させる

27. 3.6.3
テストが遅い場合にビルドを失
敗させる

28. 3.6.4
警告やコードスタイルの違反が
あった時にビルドを失敗させる
• コードチェックツール例
– Simian
– JDepend
(Java)、NDepend(.NET)
– CheckStyle、FxCop
– FindBugs
• ラチェット方式
– 警告やTODOの数が以前のチェックインより増え
ていたら失敗

29. 3.7
分散したチーム
• チームが分散している場合のお話
– 物理的に離れている場合
– 時差がある場合

30. 3.7.1
プロセスに与えるインパクト
• チームが分散していても時差がなければ、継
続的インテグレーションに違いはない
• 時差がある場合は、よりプレセスを厳密に守
る必要がある
– ビルド壊れたまま帰宅しちゃうと…
• VoIPとかメッセンジャーでのコミュニケーション
が非常に重要

31. 3.7.2
中央集権的継続的インテグレー
ション
• １箇所で集中的に継続的インテグレーション
– 環境の一貫性を保証しやすい
• 開発者がすぐにこの環境にアクセスできるよ
うにしておかなければならない
– 申請して数日待たないといけないとか…

32. 3.7.3
技術的な問題
• バージョン管理システムとの回線速度や品質
を十分なものに
• さもなくば分散バージョン管理システム
– GitやMercurial
– 回線落ちててもチェックイン可能
• バージョン管理システムと自動テストホスト間
の回線なども大事

33. 3.7.4
代替案
• 中央と太い回線が用意できない場合、バー
ジョン管理システム、CIシステムをローカルに
たてる方法もある
– 中央と環境を合わせ、同じビルドができるように
– ローカルでバージョン管理のためには
• コンポーネントベースのアプローチ⇒13章
• 分散バージョン管理システム
• 長期的視点では回線を太くするほうが安上が
り

34. 3.8
分散バージョン管理システム
• 分散バージョン管理システムでCIするには
– 一つのレポジトリをマスターと定め、そこへプッ
シュする
• GitHubモデルはフォークしたレポジトリが分散
– どれが統合できるかわからない
– 変更をすぐにマージ？→たぶん失敗
– 各レポジトリでCI
• 変更があったらマスターをマージしてCI
• マスターにマージしても正常であることを保証