SlideShare a Scribd company logo
1 of 22
Download to read offline
1 
Copyright (C) Masanori Kataoka All Rights Reserved. 
ソフトウェア構成管理・ ビルドツール 
2014年10月17日 
片岡雅憲 
2014/10/20 
Agileツール適合化分科会(第2回)資料
2 
Copyright (C) Masanori Kataoka All Rights Reserved. 
<内容> 
1.ソフトウェア構成管理技術とは 
2.バージョン管理から構成管理へ 
3.構成管理・ビルドツールの歴史構成管理・ビルドツールの歴史 
4.AntとIvy 
5.Maven 
6.新しい構成管理・ビルドツール 
7.Gradle 
8.構成管理・ビルドの自動化での留意事項化での留意事項 
9.構成管理・ビルドツールのこれから 
<参考文献>
3 
Copyright (C) Masanori Kataoka All Rights Reserved. 
ソフトウェア構成管理技術は、ソフトウェアの開発に必要とされる 
リソースを統合的に管理する技術である。 
この技術は、次の技術から構成され、発展してきた。 
1)ソフトウェアリソースを開発チームのメンバー間で共有し、その 
変更履歴を管理する技術。また、この変更履歴とバージョンとの 
関係を管理する技術。 
2)ソフトウェアの開発プロセスおよびビルド(作成)プロセス、デプロイ 
(提供)プロセスを自動化する技術。また、これらプロセス間を 
POM(Project ObjectModel)モデルに基づき相互接続し、ワーク 
フロー化する技術。 
3)上記ワークフローを反復型プロセスに発展させ、それを自動化し 
て、総合的に改善するCI(Continuous Integration)および 
CD(Continuous Delivery)技術。
4 
Copyright (C) Masanori Kataoka All Rights Reserved. 
2.バージョン管理から構成管理へ 
ソフトウェア構成管理では管理対象をソースコードに限定せずに、ソ フトウェアに関連するあらゆるリソースに拡大して管理する。 
1)ソースコードだけに限定せずに、開発対象ソフトウェアに関連する 
あらゆるファイルに拡大する(バイナリコード、テストプログラム/デー 
タ、環境情報、仕様情報他)。 
2)また、これらのファイル間の相互依存関係を管理する。 
3)プロジェクト間で共有する共有ソフトウェアファイルについて、その 
共有関係を管理する。また、外部から導入するソフトウェアについて 
も、管理の対象とする。 
4)ビルドとは、ソースコードを始めとする関連情報をまとめ上げ、 
動作可能なソフトウェアを構築する一連のプロセスである。ビルド 
ツールは、上記1)~3)を支援する。
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 
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 
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 
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 
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 
Copyright (C) Masanori Kataoka All Rights Reserved. 
5.2Mavenのアーキテクチャ 
Mavenは、POMの考え方により、図5.1に示すようにライフサイクル 全体を管理する。 
プロジェクトの作成 
コンパイル 
テスト 
パッケージング 
インストール 
デプロイ 
(公開、配布) 
ドキュメンテーション(サイ トの作成、Javadocの作成) 
リモートリポジトリ 
ローカル 
リポジトリ 
ライブラリ 
プラグイン 
5.Maven 
図5.1 POMの考え方によるライフサイクル管理(参考文献1))
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 
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 
Copyright (C) Masanori Kataoka All Rights Reserved. 
5.Maven 
5.5Mavenの課題 
Mavenは、プロジェクト構成管理ツールとして優れた機能を提供し、 技術をリードしてきたが、次のような課題を抱えている。 
1)Mavenが提供する標準プロジェクト構成、POM構成、プロセス 
構成と異なることをしようとすると改造が困難である。 
(逆に、Mavenはそれだけ「標準化を徹底しようとしている」とも言え 
る) 
2)カスタマイズをする場合に、記述言語がXMLであるため記述が難 しい。(作業が確定してしまえば、XMLを意識する必要がない) 
3)機能の多くがプラグインで実現されていてネットからダウンローす る仕掛けだが、その品質が安定しない(不良が多い、デグレードが 頻発する、設定パラメータが誤りやすい)ことがあった。すなわち、 Mavenは仕掛けが大がかりであるためにすべてを正しく設定する ために手間がかかる。また、間違いに対して親切でない。逆に、こ の困難を超えた後は、多くのメリットが得られる。
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 
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 
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 
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 
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 
Copyright (C) Masanori Kataoka All Rights Reserved. 
7.Gradle 
7.3 Gradleタスクの相互依存関係 
表7.1に示した主なGradleタスクの相互依存関係を図7.1に示す。こ のような依存関係に基づき、gradle build を実行すると、必要なタスク が次々に実行され、ビルドが完了する。 
図7.1 Gradleタスクの相互依存関係(参考文献3))
20 
Copyright (C) Masanori Kataoka All Rights Reserved. 
構成管理・ビルドを自動化するに当たり、下記に留意する必要がある。 
1)コマンド1つでビルドを実行する。 
2)複数環境へのデプロイに対応する。 
3)ビルドスクリプトをIDE(開発支援環境)から分離する 
(IDE非依存にする)。 
4)ソフトウェア資産を集中管理する 
(全ての資産をPOMリポジトリ配下で管理する)。 
5)一貫したディレクトリ構造を作る。 
6)失敗し易いビルドプロセスから始める 
(例えば、変更したソースコードのコンパイルから始める)。 
7)構成管理・ビルドの自動化は手間のかかる仕事であるが、一旦 
プロジェクトとしてそれを確立してしまえば、極めて効果が大きい。 
8)ビルド・構成管理専用マシンを用意し、使用する 
(ビルドマシンは他の目的で使わせない)。 
8.構成管理・ビルドの自動化での留意事項
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 
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

More Related Content

What's hot

JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOpsJAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps智治 長沢
 
【QCon】 Get Clean, Stay Clean 価値を向上し続けるための秘訣 #QConTokyo
【QCon】 Get Clean, Stay Clean 価値を向上し続けるための秘訣 #QConTokyo 【QCon】 Get Clean, Stay Clean 価値を向上し続けるための秘訣 #QConTokyo
【QCon】 Get Clean, Stay Clean 価値を向上し続けるための秘訣 #QConTokyo 智治 長沢
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 智治 長沢
 
Agile Development at Salesforce
Agile Development at SalesforceAgile Development at Salesforce
Agile Development at SalesforceRyoji Osawa
 
とあるメーカーのRedmine活用事例
とあるメーカーのRedmine活用事例とあるメーカーのRedmine活用事例
とあるメーカーのRedmine活用事例agileware_jp
 
[DO12] ナビタイムジャパン CTO 菊池氏が語る IT リーダのための開発を加速させる DevOps の実践例
[DO12] ナビタイムジャパン CTO 菊池氏が語る IT リーダのための開発を加速させる DevOps の実践例[DO12] ナビタイムジャパン CTO 菊池氏が語る IT リーダのための開発を加速させる DevOps の実践例
[DO12] ナビタイムジャパン CTO 菊池氏が語る IT リーダのための開発を加速させる DevOps の実践例de:code 2017
 
高信頼性を確保するソフトウェア開発手法と実践 -組込み製品の潜在的価値を今以上に高めるために-
高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-
高信頼性を確保するソフトウェア開発手法と実践 -組込み製品の潜在的価値を今以上に高めるために-Yoshio SAKAI
 
監視ってなんだっけ?
監視ってなんだっけ?監視ってなんだっけ?
監視ってなんだっけ?Ryotaro Kobayashi
 
ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用ESM SEC
 
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違いなぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違いYoichi Tamamaki
 
【14-D-4】デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣
【14-D-4】デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣【14-D-4】デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣
【14-D-4】デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣智治 長沢
 
アジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現するアジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現するMakoto SAKAI
 
【#osh2014】これからのつながる開発環境とその秘訣 (仮)
【#osh2014】これからのつながる開発環境とその秘訣 (仮)【#osh2014】これからのつながる開発環境とその秘訣 (仮)
【#osh2014】これからのつながる開発環境とその秘訣 (仮)智治 長沢
 
定量的プロジェクト管理ツール概要 Lt 20110730
定量的プロジェクト管理ツール概要 Lt 20110730定量的プロジェクト管理ツール概要 Lt 20110730
定量的プロジェクト管理ツール概要 Lt 20110730hiroetoh
 
パフォーマンス管理最前線 米国大規模システムにおける最新トレンド
パフォーマンス管理最前線 米国大規模システムにおける最新トレンドパフォーマンス管理最前線 米国大規模システムにおける最新トレンド
パフォーマンス管理最前線 米国大規模システムにおける最新トレンド日本Javaユーザーグループ
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用ESM SEC
 
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013智治 長沢
 
アジャイルクオリティの探求
アジャイルクオリティの探求アジャイルクオリティの探求
アジャイルクオリティの探求atsushi nagata
 
日本で DevOps を ロケットスタートする方法
日本で DevOps を  ロケットスタートする方法日本で DevOps を  ロケットスタートする方法
日本で DevOps を ロケットスタートする方法Puppet
 
アジャイル開発の進め方
アジャイル開発の進め方アジャイル開発の進め方
アジャイル開発の進め方ESM SEC
 

What's hot (20)

JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOpsJAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
 
【QCon】 Get Clean, Stay Clean 価値を向上し続けるための秘訣 #QConTokyo
【QCon】 Get Clean, Stay Clean 価値を向上し続けるための秘訣 #QConTokyo 【QCon】 Get Clean, Stay Clean 価値を向上し続けるための秘訣 #QConTokyo
【QCon】 Get Clean, Stay Clean 価値を向上し続けるための秘訣 #QConTokyo
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
 
Agile Development at Salesforce
Agile Development at SalesforceAgile Development at Salesforce
Agile Development at Salesforce
 
とあるメーカーのRedmine活用事例
とあるメーカーのRedmine活用事例とあるメーカーのRedmine活用事例
とあるメーカーのRedmine活用事例
 
[DO12] ナビタイムジャパン CTO 菊池氏が語る IT リーダのための開発を加速させる DevOps の実践例
[DO12] ナビタイムジャパン CTO 菊池氏が語る IT リーダのための開発を加速させる DevOps の実践例[DO12] ナビタイムジャパン CTO 菊池氏が語る IT リーダのための開発を加速させる DevOps の実践例
[DO12] ナビタイムジャパン CTO 菊池氏が語る IT リーダのための開発を加速させる DevOps の実践例
 
高信頼性を確保するソフトウェア開発手法と実践 -組込み製品の潜在的価値を今以上に高めるために-
高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-
高信頼性を確保するソフトウェア開発手法と実践 -組込み製品の潜在的価値を今以上に高めるために-
 
監視ってなんだっけ?
監視ってなんだっけ?監視ってなんだっけ?
監視ってなんだっけ?
 
ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用
 
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違いなぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
 
【14-D-4】デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣
【14-D-4】デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣【14-D-4】デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣
【14-D-4】デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣
 
アジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現するアジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現する
 
【#osh2014】これからのつながる開発環境とその秘訣 (仮)
【#osh2014】これからのつながる開発環境とその秘訣 (仮)【#osh2014】これからのつながる開発環境とその秘訣 (仮)
【#osh2014】これからのつながる開発環境とその秘訣 (仮)
 
定量的プロジェクト管理ツール概要 Lt 20110730
定量的プロジェクト管理ツール概要 Lt 20110730定量的プロジェクト管理ツール概要 Lt 20110730
定量的プロジェクト管理ツール概要 Lt 20110730
 
パフォーマンス管理最前線 米国大規模システムにおける最新トレンド
パフォーマンス管理最前線 米国大規模システムにおける最新トレンドパフォーマンス管理最前線 米国大規模システムにおける最新トレンド
パフォーマンス管理最前線 米国大規模システムにおける最新トレンド
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
 
アジャイルクオリティの探求
アジャイルクオリティの探求アジャイルクオリティの探求
アジャイルクオリティの探求
 
日本で DevOps を ロケットスタートする方法
日本で DevOps を  ロケットスタートする方法日本で DevOps を  ロケットスタートする方法
日本で DevOps を ロケットスタートする方法
 
アジャイル開発の進め方
アジャイル開発の進め方アジャイル開発の進め方
アジャイル開発の進め方
 

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

Gws 20120521 gradle
Gws 20120521 gradleGws 20120521 gradle
Gws 20120521 gradleNobuhiro Sue
 
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイルVisual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイルAkira Inoue
 
Empower Every App, Every Developer ~ 統合開発プラットフォーム Visual Studio の進化 ~
Empower Every App, Every Developer ~ 統合開発プラットフォーム Visual Studio の進化 ~Empower Every App, Every Developer ~ 統合開発プラットフォーム Visual Studio の進化 ~
Empower Every App, Every Developer ~ 統合開発プラットフォーム Visual Studio の進化 ~Akira Inoue
 
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...Shinji Takao
 
クロスプラットフォーム開発入門
クロスプラットフォーム開発入門クロスプラットフォーム開発入門
クロスプラットフォーム開発入門minazou67
 
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイルVisual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイルAkira Inoue
 
.NET Coreから概観する.NETのOSSへの取り組み
.NET Coreから概観する.NETのOSSへの取り組み.NET Coreから概観する.NETのOSSへの取り組み
.NET Coreから概観する.NETのOSSへの取り組みKouji Matsui
 
Groovy base gradle_20130309
Groovy base gradle_20130309Groovy base gradle_20130309
Groovy base gradle_20130309Nobuhiro Sue
 
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説Daisuke Nishino
 
はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入Yu Nobuoka
 
OSSを利用したプロジェクト管理
OSSを利用したプロジェクト管理OSSを利用したプロジェクト管理
OSSを利用したプロジェクト管理Tadashi Miyazato
 
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018Uemura Yuichi
 
Linux & Mac OS でも動く! ~ オープンソース & クロスプラットフォーム .NET の歩き方 ~
Linux & Mac OS でも動く! ~ オープンソース & クロスプラットフォーム .NET の歩き方 ~Linux & Mac OS でも動く! ~ オープンソース & クロスプラットフォーム .NET の歩き方 ~
Linux & Mac OS でも動く! ~ オープンソース & クロスプラットフォーム .NET の歩き方 ~Akira Inoue
 
[Modern Cloud Day Tokyo 2019] Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOra...
[Modern Cloud Day Tokyo 2019] Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOra...[Modern Cloud Day Tokyo 2019] Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOra...
[Modern Cloud Day Tokyo 2019] Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOra...オラクルエンジニア通信
 
ソフトバンクにおける Java による クラウドネイティブの実現
ソフトバンクにおける Java による クラウドネイティブの実現ソフトバンクにおける Java による クラウドネイティブの実現
ソフトバンクにおける Java による クラウドネイティブの実現Shigeru Tatsuta
 

Similar to Agileツール適合化分科会(構成管理・ビルドツール) (20)

Gws 20120521 gradle
Gws 20120521 gradleGws 20120521 gradle
Gws 20120521 gradle
 
Gradle handson
Gradle handsonGradle handson
Gradle handson
 
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイルVisual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
 
Empower Every App, Every Developer ~ 統合開発プラットフォーム Visual Studio の進化 ~
Empower Every App, Every Developer ~ 統合開発プラットフォーム Visual Studio の進化 ~Empower Every App, Every Developer ~ 統合開発プラットフォーム Visual Studio の進化 ~
Empower Every App, Every Developer ~ 統合開発プラットフォーム Visual Studio の進化 ~
 
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
 
クロスプラットフォーム開発入門
クロスプラットフォーム開発入門クロスプラットフォーム開発入門
クロスプラットフォーム開発入門
 
Devsumi2008
Devsumi2008Devsumi2008
Devsumi2008
 
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイルVisual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル
 
.NET Coreから概観する.NETのOSSへの取り組み
.NET Coreから概観する.NETのOSSへの取り組み.NET Coreから概観する.NETのOSSへの取り組み
.NET Coreから概観する.NETのOSSへの取り組み
 
Groovy base gradle_20130309
Groovy base gradle_20130309Groovy base gradle_20130309
Groovy base gradle_20130309
 
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
 
はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入
 
OSSを利用したプロジェクト管理
OSSを利用したプロジェクト管理OSSを利用したプロジェクト管理
OSSを利用したプロジェクト管理
 
20021007
2002100720021007
20021007
 
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
 
Linux & Mac OS でも動く! ~ オープンソース & クロスプラットフォーム .NET の歩き方 ~
Linux & Mac OS でも動く! ~ オープンソース & クロスプラットフォーム .NET の歩き方 ~Linux & Mac OS でも動く! ~ オープンソース & クロスプラットフォーム .NET の歩き方 ~
Linux & Mac OS でも動く! ~ オープンソース & クロスプラットフォーム .NET の歩き方 ~
 
[Modern Cloud Day Tokyo 2019] Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOra...
[Modern Cloud Day Tokyo 2019] Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOra...[Modern Cloud Day Tokyo 2019] Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOra...
[Modern Cloud Day Tokyo 2019] Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOra...
 
Jenkins と groovy
Jenkins と groovyJenkins と groovy
Jenkins と groovy
 
ソフトバンクにおける Java による クラウドネイティブの実現
ソフトバンクにおける Java による クラウドネイティブの実現ソフトバンクにおける Java による クラウドネイティブの実現
ソフトバンクにおける Java による クラウドネイティブの実現
 
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。 【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
 

More from masanori kataoka

Agileツール適合化分科会(第8回)議事録
Agileツール適合化分科会(第8回)議事録Agileツール適合化分科会(第8回)議事録
Agileツール適合化分科会(第8回)議事録masanori kataoka
 
Agileツール適合化分科会(tddとbdd)
Agileツール適合化分科会(tddとbdd)Agileツール適合化分科会(tddとbdd)
Agileツール適合化分科会(tddとbdd)masanori kataoka
 
Agileツール適合化分科会(第7回)議事録
Agileツール適合化分科会(第7回)議事録Agileツール適合化分科会(第7回)議事録
Agileツール適合化分科会(第7回)議事録masanori kataoka
 
Agileツール適合化分科会(dev opsツール)
Agileツール適合化分科会(dev opsツール)Agileツール適合化分科会(dev opsツール)
Agileツール適合化分科会(dev opsツール)masanori kataoka
 
Agileツール適合化分科会(第6回)議事録
Agileツール適合化分科会(第6回)議事録Agileツール適合化分科会(第6回)議事録
Agileツール適合化分科会(第6回)議事録masanori kataoka
 
Agileツール適合化分科会(gitとgit hub)
Agileツール適合化分科会(gitとgit hub)Agileツール適合化分科会(gitとgit hub)
Agileツール適合化分科会(gitとgit hub)masanori kataoka
 
Agileツール適合化分科会(第5回)議事録
Agileツール適合化分科会(第5回)議事録Agileツール適合化分科会(第5回)議事録
Agileツール適合化分科会(第5回)議事録masanori kataoka
 
Agileツール適合化分科会(issue tracking system)
Agileツール適合化分科会(issue tracking system)Agileツール適合化分科会(issue tracking system)
Agileツール適合化分科会(issue tracking system)masanori kataoka
 
Agileツール適合化分科会(第4回)議事録(改訂版)
Agileツール適合化分科会(第4回)議事録(改訂版)Agileツール適合化分科会(第4回)議事録(改訂版)
Agileツール適合化分科会(第4回)議事録(改訂版)masanori kataoka
 
Agileツール適合化分科会(第4回)議事録
Agileツール適合化分科会(第4回)議事録Agileツール適合化分科会(第4回)議事録
Agileツール適合化分科会(第4回)議事録masanori kataoka
 
Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)masanori kataoka
 
Agileツール適合化分科会(第3回)議事録
Agileツール適合化分科会(第3回)議事録Agileツール適合化分科会(第3回)議事録
Agileツール適合化分科会(第3回)議事録masanori kataoka
 
Agileツール適合化分科会(ci ツール)
Agileツール適合化分科会(ci ツール)Agileツール適合化分科会(ci ツール)
Agileツール適合化分科会(ci ツール)masanori kataoka
 
Agileツール適合化分科会(第2回)議事録
Agileツール適合化分科会(第2回)議事録Agileツール適合化分科会(第2回)議事録
Agileツール適合化分科会(第2回)議事録masanori kataoka
 
Agileツール適合化分科会(第1回)議事録
Agileツール適合化分科会(第1回)議事録Agileツール適合化分科会(第1回)議事録
Agileツール適合化分科会(第1回)議事録masanori kataoka
 
Agileツール適合化分科会(変更管理・バージョン管理)
Agileツール適合化分科会(変更管理・バージョン管理)Agileツール適合化分科会(変更管理・バージョン管理)
Agileツール適合化分科会(変更管理・バージョン管理)masanori kataoka
 

More from masanori kataoka (16)

Agileツール適合化分科会(第8回)議事録
Agileツール適合化分科会(第8回)議事録Agileツール適合化分科会(第8回)議事録
Agileツール適合化分科会(第8回)議事録
 
Agileツール適合化分科会(tddとbdd)
Agileツール適合化分科会(tddとbdd)Agileツール適合化分科会(tddとbdd)
Agileツール適合化分科会(tddとbdd)
 
Agileツール適合化分科会(第7回)議事録
Agileツール適合化分科会(第7回)議事録Agileツール適合化分科会(第7回)議事録
Agileツール適合化分科会(第7回)議事録
 
Agileツール適合化分科会(dev opsツール)
Agileツール適合化分科会(dev opsツール)Agileツール適合化分科会(dev opsツール)
Agileツール適合化分科会(dev opsツール)
 
Agileツール適合化分科会(第6回)議事録
Agileツール適合化分科会(第6回)議事録Agileツール適合化分科会(第6回)議事録
Agileツール適合化分科会(第6回)議事録
 
Agileツール適合化分科会(gitとgit hub)
Agileツール適合化分科会(gitとgit hub)Agileツール適合化分科会(gitとgit hub)
Agileツール適合化分科会(gitとgit hub)
 
Agileツール適合化分科会(第5回)議事録
Agileツール適合化分科会(第5回)議事録Agileツール適合化分科会(第5回)議事録
Agileツール適合化分科会(第5回)議事録
 
Agileツール適合化分科会(issue tracking system)
Agileツール適合化分科会(issue tracking system)Agileツール適合化分科会(issue tracking system)
Agileツール適合化分科会(issue tracking system)
 
Agileツール適合化分科会(第4回)議事録(改訂版)
Agileツール適合化分科会(第4回)議事録(改訂版)Agileツール適合化分科会(第4回)議事録(改訂版)
Agileツール適合化分科会(第4回)議事録(改訂版)
 
Agileツール適合化分科会(第4回)議事録
Agileツール適合化分科会(第4回)議事録Agileツール適合化分科会(第4回)議事録
Agileツール適合化分科会(第4回)議事録
 
Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)
 
Agileツール適合化分科会(第3回)議事録
Agileツール適合化分科会(第3回)議事録Agileツール適合化分科会(第3回)議事録
Agileツール適合化分科会(第3回)議事録
 
Agileツール適合化分科会(ci ツール)
Agileツール適合化分科会(ci ツール)Agileツール適合化分科会(ci ツール)
Agileツール適合化分科会(ci ツール)
 
Agileツール適合化分科会(第2回)議事録
Agileツール適合化分科会(第2回)議事録Agileツール適合化分科会(第2回)議事録
Agileツール適合化分科会(第2回)議事録
 
Agileツール適合化分科会(第1回)議事録
Agileツール適合化分科会(第1回)議事録Agileツール適合化分科会(第1回)議事録
Agileツール適合化分科会(第1回)議事録
 
Agileツール適合化分科会(変更管理・バージョン管理)
Agileツール適合化分科会(変更管理・バージョン管理)Agileツール適合化分科会(変更管理・バージョン管理)
Agileツール適合化分科会(変更管理・バージョン管理)
 

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