DSLの使い道は継続的デリバリ～AntやMavenからGradleへ

JavaのビルドツールがAntやMavenからGradleへ少しずつ変化しようとしているように思える。
考えたことをラフなメモ書き。

【元ネタ】
IT検証ラボ - ビルドツールの移行性、MavenからGradleへの乗り換えは容易か：ITpro

ビルドシステムの選択肢 - Gradle 1.0 リリース

ビルド・リリース自動化への足掛かりとしてのGroovy・Gradle・Spock｜サイバーエージェント 公式エンジニアブログ

O'REILLY 「Building and Testing with Gradle」Kindleハイライトまとめ - Togetter

Antはビルド作業をTaskで定義してパイプのようにつなげるようにビルドスクリプトを書く。
XMLゆえに長文になりがちだが、書きやすい。

Mavenはライブラリの依存関係も考慮して、大規模なシステムの構築として使える。
Mavenのビルドした成果物の構造はとても奥が深く優れているが、EJBのように複雑すぎる。

今やプログラミング言語の実験場がJavaからRubyへ移ったように、Rubyのビルドツールは、Ruby自身で書かれたrakeでとても書きやすい。
また、RubyではRSpecやCucumberのように、テスト駆動(TDD)から振るまい駆動(BDD)へ、テスト駆動の考え方も進化している。
それに対してJavaのビルドツールはあまり進歩がなかったように思う。

だが、Groovyを使ったビルドツールGradleは、rakeのように、ビルドスクリプトを書けるのが特徴みたい。
また、JUnitでテストプログラムを書く場合、モックオブジェクトやDI、リフレクションなどを使う時も多く、結構書くのが面倒なのだが、Groovyでテストプログラムを書く方がもっとシンプルなようだ。
しかも、テストプログラムが受け入れテストケースの文章になるように、振るまい駆動(BDD)で書くこともできるらしい。

ビルドスクリプトという言語スタイルは、Cのmake以来、その重要性は大きいにも関わらず、今までさほど注目されて来なかった歴史があると思う。
XPはテスト駆動や継続的インテグレーションのプラクティスを提唱することによって、ビルドスクリプトの重要性を再認識させた点が素晴らしいのではないか、と思っている。

rakeやGradleは、継続的デリバリを実現する有効なツールなのだろう。
そして、継続的デプロイ、継続的デリバリへビルド管理が進化した場合、ビルドスクリプトで表現できる範囲をもっと広げたいものだ。
それらビルドスクリプトは、Jenkinsという強力なビルド管理ツールと連携させれば、単なるリリース作業だけでなく、メトリクス収集やバッチジョブ制御などにも使えるだろう。

これらの技術も今後着目してみる。