Mavenで開発ライフサイクルを制御する

Mavenを使う時があり、「Apache Maven 2.0入門 Java・オープンソース・ビルドツール 」を参考にした。

Mavenを実際に使ってみて、概念や経験を整理してみる。

【１】Mavenとはビルドツールの標準テンプレートである

　MavenはJavaのビルドツールである。
　Antも同様だが、Mavenの特徴は汎用ビルドツールのテンプレート版みたいなもの。

　Mavenには下記の主要な概念、仕組みがある。

1-1.アーティファクト

　Mavenによって作られるプロジェクトの成果物を指す。
　一般には、JAR、WAR、EARファイルなどのコンポーネント。
　他に、JavaDoc、JUnitテストレポート、DJUnitレポート(カバレッジのレポート)も含まれる。
　
1-2.POM（Project Object Model）

　ビルドするための情報(メタデータの構造)が定義されたファイルのこと。
　普通は、pom.xmlというファイル名で作られる。
　Mavenは、pom.xmlに書かれた依存ファイル、成果物の定義を参照して、リリース用モジュールをビルドする。
　Antのbuild.xmlに相当する重要なファイル。
　
　この中で重要なタグ情報や仕組みは、下記である。

1-2-1.artifactID
　成果物のファイル名を指す。

1-2-2.groupID
　アーティファクトを作成した組織のID。
　Javaで言うパッケージ空間に相当する。

1-2-3.dependency
　アーティファクトを作るために必要な依存ライブラリを定義する。
　普通は、WebフレームワークのJARファイルやJacartaCommonライブラリが定義される。

1-2-4.version
　アーティファクト(ビルドしたモジュールや依存ライブラリ等)のバージョンを指す。
　グループID、アーティファクトID、バージョンによって、モジュールやライブラリは一意に識別され、かつ作られる。
　ビルド時は、このバージョンが最も重要な意味を持つ。

1-3.依存関係の解決
　Mavenは、依存ライブラリのグループID、URL、バージョンを指定しておくと、ネット上からダウンロードして関連付けてくれる。
　他に、開発時に共有ライブラリを自作して、依存関係を定義することも出来る。
　この仕組みのおかげで「マルチプロジェクト」という概念も実現される。

　Mavenは最終的に、「artifactId-version-拡張子」(例：app-1.0.1.jar)という形のリリースモジュールを作るために存在すると言い切ってよい。
　
【２】Mavenは、ソフトウェア・ファクトリー・ツールである

　IBMの記事「EclipseでMavenを生かす」にMavenの特徴が非常に洗練されて紹介されている。

Mavenは、末端ながらソフトウェア・ファクトリー・ツール・ファミリーに属するものです

ソフトウェア・ファクトリーは、次の3つの概念を中心に構成されています。

１・スキーマ。
　アプリケーションを構成する様々な成果物の構造と、それらの相互動作を記述するメタデータを提供します。
２・1つ以上のテンプレート。
　スターター・キットと、アプリケーション構築に必要なもの全てを提供します。
３・拡張可能開発環境（extensible development environment）。
　コンポーネントの設定、カスタム化、組み立てに使われます。

Mavenの基本的な目標というのは、ビルド・プロセスを標準化することであり、またCBTD（code-build-test-deploy）のサイクルに品質と再現性をもたらすことです

　上記の通り、開発ライフサイクルとは、下記の流れになる。
　Mavenは、ビルド～リリースの作業を自動化してくれる。

1.コーディング
↓
2.ビルド
↓
3.テスト
↓
4.デプロイ(リリース)

　ソフトウェアファクトリーはMSが提唱している概念の一つ。
　不勉強なのでソフトウェアファクトリーを完全に理解していないけれど、Mavenがやろうとしていることは、ソフトウェア製造工場の作業の理想形なのだろう。

【３】Maven以前のビルドプロセスを振り返ってみる

　ソフトウェアの歴史は、プログラミングだけでなくビルドの歴史でもある。
　古くはアセンブラからC、C++に至るまで、ビルド作業は最も重要な作業の一つ。
　リリースしてシステムを動かすために必須だから、プログラミングよりもはるかに大事かもしれない。
　
　Javaの歴史もビルド作業の変遷という視点から眺めることが出来る。
　
3-1.僕が初めてJavaプログラムを書いた時、サーバーへJSPやpropertiesのようなテキストファイル、Classのようなバイナリファイルを、手作業でディレクトリに配置していた。
　当然、Classファイルは100個以上にのぼることもあり、リリース作業手順書を詳細に作る必要があった。

　他には、JSPは初めて実行すると初めてコンパイルされるため、表示に時間がかかる状況があり、わざわざJSPだけをリコンパイルするツールも数年前まであった。

　また、リリース後には必ずWebSphereやWebLogic、Tomcatを再起動しなくてはならない。
　つまり、リリース作業が10分間と言えどもシステムが止まってしまう。
　その間、お客の業務は止まるのだから、限られた時間でしかリリースできない。
　そのためにアナウンスが必要だったり、非常に手間がかかる。
　だから、リリース作業には細心の注意が必要だった。

3-2.じきに、JARファイルやWARファイルでソースを固めて、手作業でアップロードするようになった。

　この利点は、アプリケーションサーバーを再起動した時に、勝手にデプロイ(配置)してくれること。
　でも、以前デプロイしたモジュールに上書きされない時があるので、手作業で以前のデプロイモジュールを削除することをしていた。
　
3-3.それから、Antを使ってビルドするようになった。
　build.xmlにビルドに必要な作業情報を全て書き込めば、勝手にコンパイルしてくれる。
　しかも、「ant clean」のコマンドを使えば、過去にコンパイルしたモジュールも削除して、リコンパイルできる。
　classファイルを手作業でアップロードしていた頃に比べると雲泥の差があった。
　
　でも、Webシステムが大規模化して依存ライブラリが増えるに従い、バージョン管理が非常に難しくなってきた。
　古いライブラリをバージョンアップしたいのに、一度動かしたシステムの依存ライブラリをバージョンアップして動作しなくなったらどうするのか？
　また、色々な環境(開発テスト環境、受入テスト環境、本番環境)ごとにbuild.xmlを作り、ソースコードを管理するのはまだまだ手作業の部分が多く、危険が多い。

【４】Mavenによるバージョン管理で「要件から仕様化するプロセス」を制御する

　Mavenは、ビルド作業のテンプレートとも言える。
　ビルド作業の決まりごとを守れば、設定を極力減らすことができる。
　ビルド作業でも、「Convention over Configulation」という概念が出てくる！

　とりわけ僕がMavenを使ってみて最も威力があると感じたことは、「バージョン管理」。
　
　オープンソースのアプリケーションに「開発(リリース)履歴」があるけれど、その内容を強力に管理できる。
　
　管理者の視点から見ると、バージョンと機能を1対1に紐づけることが可能になる。
　つまり、pom.xmlにリリースする機能ごとにバージョンを付けることで、デグレを防げるだけでなく、新規開発と運用保守のモジュールを平行して開発するのが以前よりもはるかに容易になった。
　
　仕様さえ固められれば、「この新しい機能をいつリリースするのか？」の場合はバージョンを1個増やした新規バージョン、「このバグはどのバージョンで直すか？」の場合はマイナーバージョンアップで管理すればいい。
　いつでも以前のバージョンに戻すことが出来る。

【５】Mavenは開発プロセスのフレームワーク(テンプレート)になりうるか？

　Mavenによるバージョン管理で初めて、CMMに出てくる構成管理や要件管理をイメージできたように思う。
　仕様さえ固めれば、ビルドしたモジュールを機能単位に制御できる。

　また、実際にMavenを使うと、JAR(WAR)というコンポーネントが単なる物理ファイルだけでなく、人や作業を含む１プロジェクトの成果物の概念まで昇華される印象を持った。
　というのも、開発者と成果物は1対1にマッピングできるから(N対1、1対Nもあるが)。

　自分が作ったモジュールにバージョンを付けるという意味は、自分がその成果物の最終責任を負うことを意味する。
　つまり、「何を修正したのか」という機能内容がバージョンに含まれていて、そのコンポーネントの品質と仕様、他コンポーネントへの依存関係も、その人が全て把握していることになる。
　その意味では、pom.xmlにバージョンを付ける事ができる人は、非常に大きな権限と責任を持つことになる。

　このようにして、コンポーネントと開発者がリンクされることで、コンポーネントの依存関係に従って、UMLの配置図がプロジェクト組織の依存関係とマッピングできる。
　つまり、共有ライブラリよりも画面に近いサブシステムの方が多くの依存関係を持つ。
　共有ライブラリのバージョンが上がると、画面に近いサブシステムもバージョンアップせざるを得なくなること。

　Mavenを使うと、自社の開発プロセスを標準化できる可能性がある。
　
　とはいえ、Mavenを使いこなせたレベルとは言えず、以前よりも開発がスムーズになったわけでもない。
　でも、Mavenを使って、以前のプロジェクトと大きく異なると感じたことは二つ。
　
　一つは、以前よりももっと大規模なシステム(モジュール)を作れるようになったこと。
　もう一つは、開発プロセスのボトルネックが、プログラミング工程ではなく、要件から仕様へ落とす設計やプロジェクト管理の工程に移ってきたこと。
　
　MSでは、開発者やテスト担当者よりもビルド担当者の方が大きな権限を持つと聞いた。
　Mavenによるビルド作業はまだ研究の余地があるように思う。