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

1Copyright (C) Masanori Kataoka All Rights Reserved.

CI(Continuous Integration)ツール

２０１４年１２月３日

片岡雅憲

2014/12/51

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

http://gihyo.jp/dev/feature/01/Hudson/0001~0005

http://gradle.monochromeroad.com/docs/userguide/userguide.html

http://www.ntts.co.jp/publish/column/tec/java_03/index.html

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

Documents