Agileツール適合化分科会（構成管理・ビルドツール）

1
Copyright (C) Masanori Kataoka All Rights Reserved.
ソフトウェア構成管理・ビルドツール
２０１４年１０月１７日
片岡雅憲
2014/10/20
Agileツール適合化分科会（第２回）資料

2
＜内容＞
１．ソフトウェア構成管理技術とは
２．バージョン管理から構成管理へ
３．構成管理・ビルドツールの歴史構成管理・ビルドツールの歴史
４．AntとIvy
５．Maven
６．新しい構成管理・ビルドツール
７．Gradle
８．構成管理・ビルドの自動化での留意事項化での留意事項
９．構成管理・ビルドツールのこれから
＜参考文献＞

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

4
２．バージョン管理から構成管理へ
ソフトウェア構成管理では管理対象をソースコードに限定せずに、ソフトウェアに関連するあらゆるリソースに拡大して管理する。
１）ソースコードだけに限定せずに、開発対象ソフトウェアに関連する
あらゆるファイルに拡大する（バイナリコード、テストプログラム/デー
タ、環境情報、仕様情報他）。
２）また、これらのファイル間の相互依存関係を管理する。
３）プロジェクト間で共有する共有ソフトウェアファイルについて、その
共有関係を管理する。また、外部から導入するソフトウェアについて
も、管理の対象とする。
４）ビルドとは、ソースコードを始めとする関連情報をまとめ上げ、
動作可能なソフトウェアを構築する一連のプロセスである。ビルド
ツールは、上記１）～３）を支援する。

5
構成管理・ビルドツールの主要な流れは次のように発展してきた。
１）make: UNIXのコマンドとしてビルド機能を実現。したがって、ＯＳに
依存する。複雑なソフトウェアに対しては、複数回のコマンドを実行
する必要がある。
２）Ant: コマンドの代わりに、Java,XMLで構造及びプロセスを記述す
る。したがって、クロスプラットフォームで利用が可能である。
３）Maven1:ビルド機能に限定せずにPOM(Project Object Model)
の考え方に基づき、ビルド、テスト、ドキュメンテーション、デプロイ
等を含めたプロジェクトのライフサイクル全体を管理。構成管理シス
テムとしての機能を持つ。
４）Maven2:Maven1の機能を継承しつつ、機能拡張、操作性向上、
性能向上の面から改良。複数プロジェクトを取り扱うことが出来る。
２００５年に初出荷。
５）Maven3: Maven2と互換性を持つ。性能面、内部構造面で改良。
２０１０年に初出荷。
３．構成管理・ビルドツールの歴史

6
4.1 Ant
Antは、XMLでビルド（ソフトウェア構築）のルールを記述するビルドツールである。このため、OS など特定の環境に依存しにくいことを特徴としている。
Antでは、タスクと呼ばれる何種類ものXML要素をビルドファイル(デフォルトではbuild.xml) 上に記述してビルドのルールを作る。主なAnt タスクの例は次の通りである。
―javac：Javaソースコードをコンパイルする
―javadoc：JavaソースコードからJavadocドキュメントを生成する
―java：Javaプログラムを実行する
—junit：JUnitを使ってJavaプログラムをテストする
―junitreport：junitで出力した結果を用いてレポートを生成する
―copy：ファイルをコピーする
―delete：ディレクトリやファイルなどを削除する
―mkdir：ディレクトリを作成する
４．AntとIvy

7
4.2 Ivy
Antと共によく使われるツールとしてApache Ivyがある。
Ivyは、ライブラリーの依存関係の管理に特化したツールである。Ivy
では、依存関係をビルドスクリプトに直接記述する代わりに、専用のファイルであるivy.xml記述する。具体的には、<info>タグでモジュール名を記述し、<dependency>タグでこのモジュールが依存するライブラリー名称を記述する。
このように、モジュールの依存関係を宣言しておけば、後はAntビルドファイルの任意の場所で<ivy:retreave>タグを記述することで、任意のディレクトリー配下に依存する（推移的な関連も含めて）jarファイルを自動的にダウンロードすることが出来る。
Ivyは、次節に述べるMavenの多様な機能群のうちから依存性管理の部分だけを切り出して特化したツールと言える。Mavenがあまりにも複雑で荷が重いと感じる開発者に愛用されている。SpringフレームワークにおいてもAnt + Ivy を活用している。
４．AntとIvy

8
５．Maven
5.1Mavenの特徴
１）POM(Project Object Model)の考え方に基づき、ソフトウェア・
プロジェクトのライフサイクル全体を標準化し、管理する。
具体的にはpom.xmlによりプロジェクト情報を管理する。
２）プロジェクトに関する標準のディレクトリ構成を持ち、その作成を容
易化すると共に、理解し易いものにしている。Antにおいて必要とさ
れる長たらしいXML記述から解放される。
３）Mavenは、小さなコア部分と大量のプラグインから構成されていて、
このプラグインやライブラリは必要に応じて自動的にダウンロードさ
れる。したがって、Mavenを使うにはネット環境が必要である。
（Mavenを初めて起動するときには、これらプラグインやライブラ
リーをネット経由でダウンロードするためにかなりの起動時間が
かかる。）

9
５．Maven
5.1Mavenの特徴（続き）
４）プロジェクトの作成からコンパイル、テスト、パッケージング、
デプロイ（公開、配布）等のタスクについての統一したビルドプロセ
スを提供していて、これらに伴う繰り返し作業を容易化している。
また、プロジェクトおよびその成果物に関するレポート作成機能も
提供している。Mavenコマンドの例を以下に示す。
―mvn archetype:create プロジェクトの作成
―mvn compile コンパイル
―mvn test ユニットテスト
―mvn javadoc:javadoc Javadocの作成
―mvn site サイトの作成
－mvn package JARファイルの作成（パッケージング）
―mvn install ローカルリポジトリへのインストール
―mvn deploy リモートリポジトリへの配備
―mvn clean プロジェクトのクリーン（削除）

10
5.2Mavenのアーキテクチャ
Mavenは、POMの考え方により、図5.1に示すようにライフサイクル全体を管理する。
プロジェクトの作成
コンパイル
テスト
パッケージング
インストール
デプロイ
（公開、配布）
ドキュメンテーション（サイトの作成、Javadocの作成）
リモートリポジトリ
ローカル
リポジトリ
ライブラリ
プラグイン
５．Maven
図5.1 POMの考え方によるライフサイクル管理（参考文献１））

11
５．Maven
5.3Mavenによるプロジェクトの定義：次の情報を定義する
―id
―name
―organization
―package
―description
―repository
―mailingLists
―developers
―contributors
―licenses
―dependencies ：依存関係のある要素を記述し、自動インストール
―build
―properties
―any element

12
５．Maven
5.4Mavenの標準ディレクトリの構成
―src/main/java 作成するアプリケーション、ライブラリのソース
―src/main/resources 作成するアプリケーション、ライブラリの
リソース
―src/main/filters リソースに適用するフィルタ
―src/main/assembly アセンブリ記述子、配布用ファイル(zipや
tar.gz等）の作成に関する情報である
―src/config 設定ファイル
―src/main/webapp Webアプリケーションに必要なソース
―src/test/java テスト用のソースコード
―src/test/resources テスト用のリソース
―src/test/filters テスト用のリソースに適用するフィルタ
―src/site サイトの作成に必要なファイル
―LICENSE.text プロジェクトのライセンスを記述したファイル
―README.text プロジェクトの説明を記述したファイル

13
５．Maven
5.5Mavenの課題
Mavenは、プロジェクト構成管理ツールとして優れた機能を提供し、技術をリードしてきたが、次のような課題を抱えている。
１）Mavenが提供する標準プロジェクト構成、POM構成、プロセス
構成と異なることをしようとすると改造が困難である。
（逆に、Mavenはそれだけ「標準化を徹底しようとしている」とも言え
る）
２）カスタマイズをする場合に、記述言語がXMLであるため記述が難しい。（作業が確定してしまえば、XMLを意識する必要がない）
３）機能の多くがプラグインで実現されていてネットからダウンローする仕掛けだが、その品質が安定しない（不良が多い、デグレードが頻発する、設定パラメータが誤りやすい）ことがあった。すなわち、 Mavenは仕掛けが大がかりであるためにすべてを正しく設定するために手間がかかる。また、間違いに対して親切でない。逆に、この困難を超えた後は、多くのメリットが得られる。

14
Ant, Maven の持つ課題を解決するべく、新しい構成管理・ビルドツールが開発されてきている。
１）Rake:
Antは、MakeのコマンドをXMLで置き換えることにより、ビルドスク
リプトの記述し易さと記述能力を大幅に改善した。しかし、XMLの
記述自体は、決してやさしいものではない。
Rakeは、XMLをRubyで置き換え、記述能力と記述し易さを大きく
改善した。Antが外部DSL(Domain Specific Language)であるのに
対して、Rakeは内部DSLである。したがって、必要とされるカスタマ
イズをRubyを使って自然に、かつRakeと矛盾することなく行うことが
出来る。今後、急速に普及するものと思われる。
Rakeの最初の作者は、Jim Weirichである。Rubyを用いたプロジェ
クトでは、Rakeが標準的なビルドツールとして使われている。Ruby
以外のプロジェクトでもRakeは活用できるが、あまり普及していない。

15
２）Buildr
Buildrの開発者Assaf Arkin氏は、Mavenの不安定さを改善する
目的でBuildrを開発した。Buildrは内部でRakeを使っていて、Rake
の機能は全て使えるようにしてある。
また、Buildrは、Maven2と同じ記述法（Convention)で、その機能を
実現している。これにより、カスタマイズの容易性が大幅に改善され
ている。そして、性能的にもMavenよりも優れている。
(Mavenの方でも、２０１０年にMaven2と互換性を持ち、性能的に
改善されたMaven3が出荷された。）
３）Gradle
Gradle 1.0は２０１２年６月に公開された新しいOSSである。記述
言語はGroovyである。Mavenの機能をすべて包含し、かつ、はるか
に拡張性、柔軟性に優れていると評判である。GradleはMavenの難
しさを解決すると期待されている。（詳細は,次の７．を参照）

16
７．Gradle
7.1 Gradleの特徴
Gradleは、スクリプト言語Groovyを用いてビルドスクリプトを記述するビルドツールである。Gradleには、次のような特徴を持っている。
①JavaVM上で動作する
②Mavenと同様にPOM(Project Object Model)に基づき、プロジェク
トのライフサイクル全体をカバーしている
③ビルドスクリプトをGroovyのDSL(Domain Specific Language)で
簡潔に記述することができる。また、DSLで記述が困難な部分は、
Groovyを用いて、カスタマイズが出来る。Groovy自身は、Javaの
知識があれば簡単に習得できる。(Groovy≒Java + Ruby)
④多様な関連ツールと連携するためのプラグインで用意されている
⑤Mavenのリポジトリを利用することができる。また、Antの資産を
そのまま活用することが出来る。
上述したように、GradleはMavenを超える機能を持ちながら、それを
カスタマイズする場合にはMavenよりも柔軟に対応出来る。

17
７．Gradle
7.2 Gradleタスク
Gradleの作業単位はタスクと呼ばれており、標準的なタスクとして
表7.1に示すものが用意されている。
表7.1 Gradleの標準タスク（１）
タスク名称
説明
assemble
コンパイルを実行しJAR、WAR、ZIP、TARファイルなどを作る
build
assemble後にテストを実行する
buildDependents
そのプロジェクト“が”依存するプロジェクトを含めbuildを実行する
classes
メインクラスをassembleする
clean
成果物(buildディレクトリ配下)を削除する
compileJava
プロダクトのコンパイルを行う
compileTestJava
テストコードをコンパイルする
jar
メインクラスを含むJarファイルを作成する
processResources
プロダクトのリソースをクラスディレクトリにコピーする
processTestResources
テストリソースをテストクラスディレクトリにコピーする

18
７．Gradle
7.2 Gradleタスク（続き）
表7.1 Gradleの標準タスク（２）
タスク名称
説明
testClasses
テストクラスをassembleする
uploadArchives
成果物をアップロードする
check
testを含む検証タスクを実行する
test
ユニットテストを実行する
javadoc
Javadocを生成する
dependencies
プロジェクトが利用するライブラリを表示する
help
ヘルプメッセージを表示する
projects
サブプロジェクトを表示する
properties
プロジェクトのプロパティを表示する
tasks
実行可能なタスクを表示する

19
７．Gradle
7.3 Gradleタスクの相互依存関係
表7.1に示した主なGradleタスクの相互依存関係を図7.1に示す。このような依存関係に基づき、gradle build を実行すると、必要なタスクが次々に実行され、ビルドが完了する。
図7.1 Gradleタスクの相互依存関係（参考文献３））

20
構成管理・ビルドを自動化するに当たり、下記に留意する必要がある。
１）コマンド１つでビルドを実行する。
２）複数環境へのデプロイに対応する。
３）ビルドスクリプトをＩＤＥ（開発支援環境）から分離する
（ＩＤＥ非依存にする）。
４）ソフトウェア資産を集中管理する
（全ての資産をPOMリポジトリ配下で管理する）。
５）一貫したディレクトリ構造を作る。
６）失敗し易いビルドプロセスから始める
（例えば、変更したソースコードのコンパイルから始める）。
７）構成管理・ビルドの自動化は手間のかかる仕事であるが、一旦
プロジェクトとしてそれを確立してしまえば、極めて効果が大きい。
８）ビルド・構成管理専用マシンを用意し、使用する
（ビルドマシンは他の目的で使わせない）。
８．構成管理・ビルドの自動化での留意事項

21
最後に、本稿をまとめると次のようになる。
１）makeに始まり、Ant, Mavenと発展してきて、構成管理・ビルドツー
ルの基礎が固められた。Ant, Mavenは今なお主要なツールであり、
デファクトスタンダードである。
２）Ant, MavenはXMLベースであることから、プラットフォーム非依存で
はあるが記述が煩雑であり、カスタマイズがやりにくいとの問題が
あった。
３）Rake, Buildr は、この問題を解決すべくXMLをRubyで置き換えて、
記述性とカスタマイズの容易性を改善した。しかしながら、これらの
ツールはRubyプロジェクトでは、デファクトスタンダードになったも
のの、その外では普及しなかった。
４）新しいGradleでは、記述言語をGroovyとすることにより、これを解
決しようとしている。Groovyは、Rubyと同様の動的スクリプト言語
であり、また、Javaとの親和性も高い。カスタマイズの容易性を売り
物にしていて、今後の普及が期待されている。
９．構成管理・ビルドツールのこれから

22
1)「2. Maven入門TECHSCORE」 www.techscore.com/tech/Java/ApacheJakarta/Maven/2
2)“Gradle User Guide” Hans Dockter, Adam Murdoch2007-2012
Hayashi Masatoshi,Sekiya Kazuchika, Sue Nobuhiro, Mochida Shinya（訳）
http://gradle.monochromeroad.com/docs/userguide/userguide.html
3)「ビルドツールGradleスタートアップガイドの紹介」鈴木雅貴２０１３年
http://www.ntts.co.jp/publish/column/tec/java_03/index.html

Agileツール適合化分科会（構成管理・ビルドツール）

More Related Content

What's hot

Similar to Agileツール適合化分科会（構成管理・ビルドツール）

More from masanori kataoka

Agileツール適合化分科会（構成管理・ビルドツール）