More Related Content Similar to Agileツール適合化分科会(構成管理・ビルドツール) Similar to Agileツール適合化分科会(構成管理・ビルドツール) (20) More from masanori kataoka More from masanori kataoka (16) Agileツール適合化分科会(構成管理・ビルドツール)1. 1
Copyright (C) Masanori Kataoka All Rights Reserved.
ソフトウェア構成管理・ ビルドツール
2014年10月17日
片岡雅憲
2014/10/20
Agileツール適合化分科会(第2回)資料 2. 2
Copyright (C) Masanori Kataoka All Rights Reserved.
<内容>
1.ソフトウェア構成管理技術とは
2.バージョン管理から構成管理へ
3.構成管理・ビルドツールの歴史構成管理・ビルドツールの歴史
4.AntとIvy
5.Maven
6.新しい構成管理・ビルドツール
7.Gradle
8.構成管理・ビルドの自動化での留意事項化での留意事項
9.構成管理・ビルドツールのこれから
<参考文献> 3. 3
Copyright (C) Masanori Kataoka All Rights Reserved.
ソフトウェア構成管理技術は、ソフトウェアの開発に必要とされる
リソースを統合的に管理する技術である。
この技術は、次の技術から構成され、発展してきた。
1)ソフトウェアリソースを開発チームのメンバー間で共有し、その
変更履歴を管理する技術。また、この変更履歴とバージョンとの
関係を管理する技術。
2)ソフトウェアの開発プロセスおよびビルド(作成)プロセス、デプロイ
(提供)プロセスを自動化する技術。また、これらプロセス間を
POM(Project ObjectModel)モデルに基づき相互接続し、ワーク
フロー化する技術。
3)上記ワークフローを反復型プロセスに発展させ、それを自動化し
て、総合的に改善するCI(Continuous Integration)および
CD(Continuous Delivery)技術。 4. 4
Copyright (C) Masanori Kataoka All Rights Reserved.
2.バージョン管理から構成管理へ
ソフトウェア構成管理では管理対象をソースコードに限定せずに、ソ フトウェアに関連するあらゆるリソースに拡大して管理する。
1)ソースコードだけに限定せずに、開発対象ソフトウェアに関連する
あらゆるファイルに拡大する(バイナリコード、テストプログラム/デー
タ、環境情報、仕様情報他)。
2)また、これらのファイル間の相互依存関係を管理する。
3)プロジェクト間で共有する共有ソフトウェアファイルについて、その
共有関係を管理する。また、外部から導入するソフトウェアについて
も、管理の対象とする。
4)ビルドとは、ソースコードを始めとする関連情報をまとめ上げ、
動作可能なソフトウェアを構築する一連のプロセスである。ビルド
ツールは、上記1)~3)を支援する。 5. 5
Copyright (C) Masanori Kataoka All Rights Reserved.
構成管理・ビルドツールの主要な流れは次のように発展してきた。
1)make: UNIXのコマンドとしてビルド機能を実現。したがって、OSに
依存する。複雑なソフトウェアに対しては、複数回のコマンドを実行
する必要がある。
2)Ant: コマンドの代わりに、Java,XMLで構造及びプロセスを記述す
る。したがって、クロスプラットフォームで利用が可能である。
3)Maven1:ビルド機能に限定せずにPOM(Project Object Model)
の考え方に基づき、ビルド、テスト、ドキュメンテーション、デプロイ
等を含めたプロジェクトのライフサイクル全体を管理。構成管理シス
テムとしての機能を持つ。
4)Maven2:Maven1の機能を継承しつつ、機能拡張、操作性向上、
性能向上の面から改良。複数プロジェクトを取り扱うことが出来る。
2005年に初出荷。
5)Maven3: Maven2と互換性を持つ。性能面、内部構造面で改良。
2010年に初出荷。
3.構成管理・ビルドツールの歴史 6. 6
Copyright (C) Masanori Kataoka All Rights Reserved.
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:ディレクトリを作成する
4.AntとIvy 7. 7
Copyright (C) Masanori Kataoka All Rights Reserved.
4.2 Ivy
Antと共によく使われるツールとしてApache Ivyがある。
Ivyは、ライブラリーの依存関係の管理に特化したツールである。Ivy
では、依存関係をビルドスクリプトに直接記述する代わりに、専用の ファイルであるivy.xml記述する。具体的には、<info>タグでモジュー ル名を記述し、<dependency>タグでこのモジュールが依存するライブ ラリー名称を記述する。
このように、モジュールの依存関係を宣言しておけば、後はAntビルド ファイルの任意の場所で<ivy:retreave>タグを記述することで、任意の ディレクトリー配下に依存する(推移的な関連も含めて)jarファイルを自 動的にダウンロードすることが出来る。
Ivyは、次節に述べるMavenの多様な機能群のうちから依存性管理 の部分だけを切り出して特化したツールと言える。Mavenがあまりにも 複雑で荷が重いと感じる開発者に愛用されている。Springフレーム ワークにおいてもAnt + Ivy を活用している。
4.AntとIvy 8. 8
Copyright (C) Masanori Kataoka All Rights Reserved.
5.Maven
5.1Mavenの特徴
1)POM(Project Object Model)の考え方に基づき、ソフトウェア・
プロジェクトのライフサイクル全体を標準化し、管理する。
具体的にはpom.xmlによりプロジェクト情報を管理する。
2)プロジェクトに関する標準のディレクトリ構成を持ち、その作成を容
易化すると共に、理解し易いものにしている。Antにおいて必要とさ
れる長たらしいXML記述から解放される。
3)Mavenは、小さなコア部分と大量のプラグインから構成されていて、
このプラグインやライブラリは必要に応じて自動的にダウンロードさ
れる。したがって、Mavenを使うにはネット環境が必要である。
(Mavenを初めて起動するときには、これらプラグインやライブラ
リーをネット経由でダウンロードするためにかなりの起動時間が
かかる。) 9. 9
Copyright (C) Masanori Kataoka All Rights Reserved.
5.Maven
5.1Mavenの特徴(続き)
4)プロジェクトの作成からコンパイル、テスト、パッケージング、
デプロイ(公開、配布)等のタスクについての統一したビルドプロセ
スを提供していて、これらに伴う繰り返し作業を容易化している。
また、プロジェクトおよびその成果物に関するレポート作成機能も
提供している。Mavenコマンドの例を以下に示す。
―mvn archetype:create プロジェクトの作成
―mvn compile コンパイル
―mvn test ユニットテスト
―mvn javadoc:javadoc Javadocの作成
―mvn site サイトの作成
-mvn package JARファイルの作成(パッケージング)
―mvn install ローカルリポジトリへのインストール
―mvn deploy リモートリポジトリへの配備
―mvn clean プロジェクトのクリーン(削除) 10. 10
Copyright (C) Masanori Kataoka All Rights Reserved.
5.2Mavenのアーキテクチャ
Mavenは、POMの考え方により、図5.1に示すようにライフサイクル 全体を管理する。
プロジェクトの作成
コンパイル
テスト
パッケージング
インストール
デプロイ
(公開、配布)
ドキュメンテーション(サイ トの作成、Javadocの作成)
リモートリポジトリ
ローカル
リポジトリ
ライブラリ
プラグイン
5.Maven
図5.1 POMの考え方によるライフサイクル管理(参考文献1)) 11. 11
Copyright (C) Masanori Kataoka All Rights Reserved.
5.Maven
5.3Mavenによるプロジェクトの定義:次の情報を定義する
―id
―name
―organization
―package
―description
―repository
―mailingLists
―developers
―contributors
―licenses
―dependencies :依存関係のある要素を記述し、自動インストール
―build
―properties
―any element 12. 12
Copyright (C) Masanori Kataoka All Rights Reserved.
5.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. 13
Copyright (C) Masanori Kataoka All Rights Reserved.
5.Maven
5.5Mavenの課題
Mavenは、プロジェクト構成管理ツールとして優れた機能を提供し、 技術をリードしてきたが、次のような課題を抱えている。
1)Mavenが提供する標準プロジェクト構成、POM構成、プロセス
構成と異なることをしようとすると改造が困難である。
(逆に、Mavenはそれだけ「標準化を徹底しようとしている」とも言え
る)
2)カスタマイズをする場合に、記述言語がXMLであるため記述が難 しい。(作業が確定してしまえば、XMLを意識する必要がない)
3)機能の多くがプラグインで実現されていてネットからダウンローす る仕掛けだが、その品質が安定しない(不良が多い、デグレードが 頻発する、設定パラメータが誤りやすい)ことがあった。すなわち、 Mavenは仕掛けが大がかりであるためにすべてを正しく設定する ために手間がかかる。また、間違いに対して親切でない。逆に、こ の困難を超えた後は、多くのメリットが得られる。 14. 14
Copyright (C) Masanori Kataoka All Rights Reserved.
6.新しい構成管理・ビルドツール
Ant, Maven の持つ課題を解決するべく、新しい構成管理・ビルド ツールが開発されてきている。
1)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. 15
Copyright (C) Masanori Kataoka All Rights Reserved.
6.新しい構成管理・ビルドツール
2)Buildr
Buildrの開発者Assaf Arkin氏は、Mavenの不安定さを改善する
目的でBuildrを開発した。Buildrは内部でRakeを使っていて、Rake
の機能は全て使えるようにしてある。
また、Buildrは、Maven2と同じ記述法(Convention)で、その機能を
実現している。これにより、カスタマイズの容易性が大幅に改善され
ている。そして、性能的にもMavenよりも優れている。
(Mavenの方でも、2010年にMaven2と互換性を持ち、性能的に
改善されたMaven3が出荷された。)
3)Gradle
Gradle 1.0は2012年6月に公開された新しいOSSである。記述
言語はGroovyである。Mavenの機能をすべて包含し、かつ、はるか
に拡張性、柔軟性に優れていると評判である。GradleはMavenの難
しさを解決すると期待されている。(詳細は,次の7.を参照) 16. 16
Copyright (C) Masanori Kataoka All Rights Reserved.
7.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. 17
Copyright (C) Masanori Kataoka All Rights Reserved.
7.Gradle
7.2 Gradleタスク
Gradleの作業単位はタスクと呼ばれており、標準的なタスクとして
表7.1に示すものが用意されている。
表7.1 Gradleの標準タスク(1)
タスク名称
説明
assemble
コンパイルを実行しJAR、WAR、ZIP、TARファイルなどを作る
build
assemble後にテストを実行する
buildDependents
そのプロジェクト“が”依存するプロジェクトを含めbuildを実行する
classes
メインクラスをassembleする
clean
成果物(buildディレクトリ配下)を削除する
compileJava
プロダクトのコンパイルを行う
compileTestJava
テストコードをコンパイルする
jar
メインクラスを含むJarファイルを作成する
processResources
プロダクトのリソースをクラスディレクトリにコピーする
processTestResources
テストリソースをテストクラスディレクトリにコピーする 18. 18
Copyright (C) Masanori Kataoka All Rights Reserved.
7.Gradle
7.2 Gradleタスク(続き)
表7.1 Gradleの標準タスク(2)
タスク名称
説明
testClasses
テストクラスをassembleする
uploadArchives
成果物をアップロードする
check
testを含む検証タスクを実行する
test
ユニットテストを実行する
javadoc
Javadocを生成する
dependencies
プロジェクトが利用するライブラリを表示する
help
ヘルプメッセージを表示する
projects
サブプロジェクトを表示する
properties
プロジェクトのプロパティを表示する
tasks
実行可能なタスクを表示する 19. 19
Copyright (C) Masanori Kataoka All Rights Reserved.
7.Gradle
7.3 Gradleタスクの相互依存関係
表7.1に示した主なGradleタスクの相互依存関係を図7.1に示す。こ のような依存関係に基づき、gradle build を実行すると、必要なタスク が次々に実行され、ビルドが完了する。
図7.1 Gradleタスクの相互依存関係(参考文献3)) 20. 20
Copyright (C) Masanori Kataoka All Rights Reserved.
構成管理・ビルドを自動化するに当たり、下記に留意する必要がある。
1)コマンド1つでビルドを実行する。
2)複数環境へのデプロイに対応する。
3)ビルドスクリプトをIDE(開発支援環境)から分離する
(IDE非依存にする)。
4)ソフトウェア資産を集中管理する
(全ての資産をPOMリポジトリ配下で管理する)。
5)一貫したディレクトリ構造を作る。
6)失敗し易いビルドプロセスから始める
(例えば、変更したソースコードのコンパイルから始める)。
7)構成管理・ビルドの自動化は手間のかかる仕事であるが、一旦
プロジェクトとしてそれを確立してしまえば、極めて効果が大きい。
8)ビルド・構成管理専用マシンを用意し、使用する
(ビルドマシンは他の目的で使わせない)。
8.構成管理・ビルドの自動化での留意事項 21. 21
Copyright (C) Masanori Kataoka All Rights Reserved.
最後に、本稿をまとめると次のようになる。
1)makeに始まり、Ant, Mavenと発展してきて、構成管理・ビルドツー
ルの基礎が固められた。Ant, Mavenは今なお主要なツールであり、
デファクトスタンダードである。
2)Ant, MavenはXMLベースであることから、プラットフォーム非依存で
はあるが記述が煩雑であり、カスタマイズがやりにくいとの問題が
あった。
3)Rake, Buildr は、この問題を解決すべくXMLをRubyで置き換えて、
記述性とカスタマイズの容易性を改善した。しかしながら、これらの
ツールはRubyプロジェクトでは、デファクトスタンダードになったも
のの、その外では普及しなかった。
4)新しいGradleでは、記述言語をGroovyとすることにより、これを解
決しようとしている。Groovyは、Rubyと同様の動的スクリプト言語
であり、また、Javaとの親和性も高い。カスタマイズの容易性を売り
物にしていて、今後の普及が期待されている。
9.構成管理・ビルドツールのこれから 22. 22
Copyright (C) Masanori Kataoka All Rights Reserved.
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スタートアップガイドの紹介」鈴木雅貴2013年
http://www.ntts.co.jp/publish/column/tec/java_03/index.html