Agileツール適合化分科会（ci ツール）

1Copyright (C) Masanori Kataoka All Rights Reserved.
CI(Continuous Integration)
ツール
２０１４年１２月３日
片岡雅憲
2014/12/5
1
Agileツール適合化分科会（第３回）資料

＜内容＞
１．ソフトウェア構成管理技術とは
２．CI(Continuous Integration)
３．Jenkins
４．まとめ
＜参考文献＞

ソフトウェア構成管理技術は、ソフトウェアの開発に必要とされる
リソースを統合的に管理する技術である。
この技術は、次の技術から構成され、発展してきた。
１）ソフトウェアリソースを開発チームのメンバー間で共有し、その
変更履歴を管理する技術。また、この変更履歴とバージョンとの
関係を管理する技術。
２）ソフトウェアの開発プロセスおよびビルド（作成）プロセス、デプロイ
（提供）プロセスを自動化する技術。また、これらプロセス間を
POM(Project Object Model)モデルに基づき相互接続し、ワーク
フロー化する技術。
３）上記ワークフローを反復型プロセスに発展させ、その自動化を含
めて総合的に改善するCI(Continuous Integration)および
CD(Continuous Delivery)技術。

２．ＣＩ(Continuous Integration)
2.1 CIとは何か
CI (Continuous Integration:継続的統合）とは、ソフトウェア開発チー
ムにおいて、メンバ各自の成果物を頻繁に統合するソフトウェアのプラ
クティスを言う。統合時のエラーを出来るだけ早く検出できるように、テ
ストを含めこのプラクティスにおける作業の大部分は自動化されている。
これにより、作業の正確性を高め、作業効率を上げ、失敗に迅速に対
応し、フィードバックする。
システムインテグレーション作業は、失敗しがちな難しい作業とされ
ている。CI は、
「つらい仕事をこなすコツは、それを小さく分けて、頻繁に行うこと」
との考え方を徹底するものである。そして、この考え方は、アジャイル
開発のそれと相性が良い。

2.2 CI作業のすすめ方
１）すべての開発者は自分の作業環境上でプライベートビルドを実行し
（最低１～２回／日）、それが正しく行われたことを保証する。
２）そして、これをCI用のバージョン管理リポジトリにコミッする。（上記
の１）で失敗したものを、決してコミットしてはならない）
３）CIは、専用マシン上で数回/日、または、コミットがある度に自動的に
実行される。統合ビルドは、短時間（たとえば、５分以内）で実行され
なくてはならない。
４）CIでは、そこに組み込まれた確認テスト(regression test)の１００％
成功が必須である。
５）失敗したCIの修復は最優先事項（例えば、１０分以内）として処理す
べきである。失敗の可能性があるので、コミットは、帰宅の１時間以上
前に実施するべきである。
６） CIサーバーマシンは専用のものを用意する（他の用途との混用を
して、その影響を受けてはならない）。
２．CI(Continuous Integration)

開発者
開発者
開発者
-----------------------
-----------------------
-----------------------
-----------------------
-----------------------
-----------------------
-----------------------
バージョン管
理リポジトリ
（ソースコード
管理リポジリ）
CI サーバー
（インテグレー
ションビルドマ
シーン）
ビルドスクリプト
・ソースコードのコンパイル
・DB のインテグレーション
・リグレッションテスト
・インスペクション
・ソフトウェアのデプロイ
フィードバック手段
変更を
コミット
変更を
コミット
変更を
コミット
監視
ツール類を
起動、結果
を得る
結果をフィー
ドバック
2.3 CIサーバの動作環境: CIサーバは、ソースコード管理リポジトリ、
ビルドツール、リグレッションテストツール他と連動する。
（注）開発者は各々がプライベートビルドを実行、結果が正しいことを確認した上でバージョン管理
リポジトリに変更をコミットする。CI サーバは、これを監視していて、ビルド他のプロセスを実行する。
プラベート
ビルド
図2.1 CI サーバの動作環境（参考文献5））

2.4 CI による自動化の意義
CI は、技術的な改革だけでなく、文化的な変革をもたらす。
１）手作業を減らし（自動化）、思い込みを減らす（リスク軽減）。
２）ソフトウェアが常に健康であることを保つ（不具合な点をすぐに検出
してくれるので、そのソフトウェアについての信頼を深める）。
３）プロジェクトの可視性を高める（ビルドステータスのメールでの転送、
インスペクションによる品質メトリックスの表示、等）。
４）上記３）の結果を、そのソフトウェアの改良に活用出来る
（インスペクション結果＝＞リファクタリング支援）。
５）CIサーバは、”Tools Manager/Integrator/Executer”として働く
（ ①個別ツールの自動化、②ツール群連携、
に加えて、
③ツール群反復型連携、④管理情報可視化（見える化）
の観点からツール群を有機的に統合し、より高度な自動化を実現）。

2.5 統合ビルドツール対ＣＩ支援ツール
CI 支援ツールは、POMモデルによるMaven等の統合ビルドツール
の発展形ともとらえられる。しかし、次の観点からビルドツールを超え
た、より高度なシステムととらえるのが妥当である。
１）反復型改善サイクルを支援するために、時間的な制約を強く意識
している。この一環として並列（コンポーネント別並列、負荷並列）
処理機能がある。
２）定期起動、イベント起動などの自動起動機能を持つ。
３）チーム内、チーム間の協業支援のためのメールによる結果通知
機能、フィードバック型改善推進のためのメトリックス分析機能、
プロジェクト状況のWeb表示機能がある。
４）各プロジェクト固有の特性を反映するために、プロジェクト固有
ツールの接続、統合を可能としている。

初期化
ソースコードの
コンパイル
データベースの
インテグレーション
リグレッション
テスト
インスペクション
ソフトウェアの
デプロイ
------------------------------------
------------------------------------
------------------------------------
------------------------------------
------------------------------------
------------------------------------
------------------------------------
------------------------------------
------------------------------------
-
CI ビルドスクリプト
2.6 CI ビルドスクリプト
＜参考＞ CI ビルドの種類
① プライベートビルド
② インテグレーションビルド
(a) コミットビルド（５分以内が望ましい）
(b) ２次ビルド（含：インスペクション）
③ リリースビルド
図6.2 CI ビルドスクリプト

2.7 CI に基づくビルドの種類
１）プライベートビルド：
開発者各々が自分自身の担当分の開発のために行うビルド
２）インテグレーションビルド：
a) コミットビルド：バージョン管理システムに変更がコミットされたこと
に伴い起動される。①コミットのたびに起動、②一定時間（例えば
５分）間隔で監視し、変更があれば起動等の起動方法がある。
b) ２次ビルド：静的コードインスペクションを含めて実施する。
時間がかかるので、例えば、１回/日、夜間に行う。
３）リリースビルド：
顧客にリリースするためのビルド

2.8 CI サーバ（CI支援ツール）の例
１） CruiseControl: ThoughtWorks社のCIサーバで、2001年にOSS
として公開され、広く普及した。
同社は、現在はこれをベースに更に拡張した有料ツールGo を
販売している。これは、同社の有料ツールMingle（プロジェクト管
理）、 Twist（テスト支援）と連動し、大規模アジャイル開発向けの
統合環境を提供している。
２） Continuum: OSSのCIサーバで、Maven2との親和性が高い。
Subversion等のソースコード管理ツールとも連動。
３） AnthillPro: Urbancode社製のCIサーバ。２００１年に初出荷され
ており、老舗的存在である。その後、Urbancodeは、クラウドシステ
ムを対象にCI/CDツールの拡張を続けた。２０１３年にUrbancode
社はIBM社に買収されIBM社のクラウド戦略の中に組み込まれた
（IBM社での製品名称は、Urbancode)。

2.8 CIサーバ（CI 支援ツール）の例（続き）
４） Jenkins(Hudson): 2004年Sun Microsystemsにいた川口他が開
発したOSSのCIサーバである。第２世代のCI サーバを標榜してい
て使い易さが売りである。オラクル社とのトラブルで、２０１２年に
HudsonからJenkinsに名称を変えた。Subversion等のバージョン
管理ツール、Ant, Maven等のビルドツールと連携している。日本語
化も徹底されている。
５） Rational BuildForge： IBM社の大規模アジャイル開発向けのCI
ツールである。分散ビルド、テスト、デプロイ機能を持つ。
６） TFS(Team Foundation Server)： Microsoft社の大規模ソフトウェ
ア開発向けの統合環境である。アジャイル開発用CIサーバ機能を
含んでいる。
７） Draco.NET: OSSベースの .NET用CIサーバである。
８） Travis CI: GitHub専用のCI サービスである。 Jenkins用のサー
バーを特別に用意することなく、CI を実現できる。

3.1 Jenkinsの特徴
CruiseControl等を第一世代のCIツールとすると、Jenkinsは第２
世代のCIツールを標榜していて、次のような長所を持っている。
１）ユーザインタフェースが全てGUIインタフェースになっていて、
使い易い。
２）インストール、セットアップが容易である、
３）多様なプラグインが用意されていて、拡張性に富んでいる。
４）創始者が、日本人の川口氏であることから、日本語対応がしっかり
としていて、日本人にも使い易い。

3.2 Jenkinsを使ったビルドのプロセス
１）ビルドジョブの種類の設定
次の３種類のビルドがあり、そのいづれかを選択する。
a) フリースタイルのビルド
ビルドの内容を自由に設定する。
b) Maven2プロジェクトのビルド
Maven2のPOMに従ってビルドする。
c）マルチ構成プロジェクトのビルド
同一のビルドおよびテストを複数の異なる環境で行うようにする。
以下、２）以降では、a)フリースタイルのビルドについて、ビルド
手順を説明する。

3.2 Jenkinsを使ったビルドのプロセス（続き）
２）ビルドジョブを設定
名称だけでは、後で何のためのビルドであったか思い出せなくな
るので、説明にコメントを書くことが大切である。
３）バージョン管理システムを設定
CVS, Subversionについては、標準サポートされている。Git等
その他のツールを使う場合は、プラグインが必要である。
４）ビルドトリガを設定：次のどれかを選定。
a）一定時間間隔でコミット有無をポーリング
（CVSでは、負荷が高い。Subversionでは軽い。）
b)変更がコミットされる度に起動
（そのためのフックが必要）
c)定期的に実行

3.2 Jenkinsを使ったビルドのプロセス（続き）
５）ログの保存
ビルドの失敗等の原因追跡のために、ビルドのログを保存する
必要がある場合は、それを指定する。
６）ビルド手順の設定
次のどれかを設定する。複雑な場合はビルド手順自身をバージョ
ン管理する。
a) ビルドスクリプトを直接に書く
b) Ant, Maven等のビルドツールを使う
７）ビルドの後処理
a) ビルド結果を開発者にメールでフィードバックする。あまりに多く
の関係者に知らせると、狼少年扱いされて読まれなくなってしまう。
b) テスト結果の集計と表示

3.3 ビルド作業の分割と並行処理
１）ビルドとテストを分離する。ビルドが完了後、その成果物を引き継
いで、テストを自動起動する様にする。
２）ビルド自身を複数のプロジェクトに分割する。（Jenkinsは、複数プ
ロジェクトのビルドを並行処理出来る）
３）テストを分割して、並行処理および順次処理する。
４）複数のコンピュータで分散処理する。この場合に、Jenkinsは、
マスタースレーブ方式をとる。ジョブの起動は、マスター起動方式と
スレーブ起動方式の両方がある。

3.4 JenkinsとRedmineの連携
JenkinsとRedmineでは、双方向の連携が可能になっている。
１） Redmineのプラグインsimple_ci により、Jenkinsの直近のビルド
履歴をRedmine上で表示する。このビルド番号のリンクを押下する
とこのビルドに取り込まれたコミットログを表示する。
２） Jenkinsのビルド番号の画面を表示して、これにリンクされたコミット
ログにあるチケット番号のリンクを押下する。これによりRedmineの
チケットを表示し、チケットに表示されているSubversionリビジョンを
得る。
３）上述したようにツール間で次のように作業分担し、かつ連携する。
―Redmine: チケット番号を含めたアジャイル開発作業の管理
―Subversion: リビジョン番号を含めたソースコード変更歴の管理
―Jenkins: ビルド番号を含めたビルド作業とその成果物の管理

3.5 BuildHive
BuildHiveは、GitHub上でJenkinsを活用するためのサービスである。
２０１２年に川口氏が所属するCloudBees社がリリースし、無料で使用
することが出来る。
BuildHiveは、GitHub上に組み込まれ、GitHubに更新をpushするた
びにJenkinsが自動的に起動されてビルドが行われる。Jenkins用の
サーバーを特別に用意することなく、CI を実現できることが大きな長所
となっている。

４．まとめ
１）情報システムの大規模化・複雑化・分散開発化が進んでいる。
世界的なレベルでの標準部品化・標準パターン化・標準フレーム
ワーク化・クラウド化がこれをさらに加速している。
２）これらの課題に対処するためにソフトウェア構成管理が必須に
なってきている。
－誤りのないソフトウェア資産（リソース）管理
－ソフトウェア開発の高度な自動化の推進
３）ソフトウェア開発の自動化は、個別プロセスの自動化にとどまらず、
複数の関連プロセスを連携させる統合的、システム的な自動化が
期待されている。さらには、反復型ライフサイクルによる高速回転
型自動化が期待されている。
４）ソフトウェア自動化ツールの統合化は、この構成管理を核として
進めることが大切である。より具体的には、CIおよびCDによる自動
化ツールの統合化が重要である。

1) “Continuous Integration” P. M. Duvall, S. M. Matyas, A. Glover
2007 by Pearson Education, Inc. 「継続的インテグレーション入門」（訳）大
塚庸司、丸山大輔、岡本裕二、亀村圭助２００９年日系ＢＰ社
2) “Continuous Delivery: reliable software releases through build,test and
deployment automation” Jez Humble, David Farley 2010 Addison-Wesley
3) 「Hudson を使ったアジャイルな開発入門（第１回～第５回）」川口耕介２００８
年５月～６月 http://gihyo.jp/dev/feature/01/Hudson/0001~0005
4) 「Jenkins実践入門～ビルド・テスト・デプロイを自動化する技術」和田貴久、
川村雅人、米沢弘樹、山岸啓（著）２０１１年技術評論社
5) “Continuous Integration” P. M. Duvall, S. M. Matyas, A. Glover
2007 by Pearson Education, Inc. 「継続的インテグレーション入門」
（訳）大塚庸司、丸山大輔、岡本裕二、亀村圭助２００９年日系ＢＰ社
6) “Gradle User Guide” Hans Dockter, Adam Murdoch 2007-2012
Hayashi Masatoshi,Sekiya Kazuchika, Sue Nobuhiro, Mochida Shinya（訳）
http://gradle.monochromeroad.com/docs/userguide/userguide.html
7) 「ビルドツールGradleスタートアップガイドの紹介」鈴木雅貴２０１３年
http://www.ntts.co.jp/publish/column/tec/java_03/index.html

Agileツール適合化分科会（ci ツール）

Recomendados

Recomendados

Más contenido relacionado

Similar a Agileツール適合化分科会（ci ツール）

Similar a Agileツール適合化分科会（ci ツール） (20)

Más de masanori kataoka

Más de masanori kataoka (11)

Agileツール適合化分科会（ci ツール）