Maven2+Hudsonによる1clickリリース管理
現在関わっているとあるプロジェクトでは、maven-release-pluginを使用してリリースビルドを行っていました。maven-release-pluginを組み込んだプロジェクトをHudsonからキックすることで、リリース用のアーカイブを作成し、リポジトリにアップロードしていました。
先日、このリリース方式を少し見直したので備忘録としてここにまとめておきます。
新方式の内容
- 新方式では、maven-release-pluginを使用しないやり方にしてしまいました。
- 具体的には、Hudsonから「clean deploy scm:tag」を実行するというシンプルなやり方にしました。
- リリースを行うバージョン番号は、pom.xmlに記述するのではなく、HudsonのParameterized Buildを使ってビルド時に変数として渡してあげる方式にしました。
maven-release-pluginを止めた理由
- なんと言っても、はまりどころが多すぎます。Mavenそのものが難しいというのもありますが。。。
- 過去日記に書いていますが、以下の問題に遭遇しています。
- また、maven-release-pluginの場合、pom.xmlをプラグインの機能で編集してコミットする処理があります。この処理の途中でエラーとなった場合に、元に戻してやり直すことが面倒。手動で元に戻す必要があるので、Hudsonから1clickでリリースしようとするには相性が悪い。
- その他、maven-release-pluginによるrelease:performでは、内部でMavenをもう1つ実行してビルドを行うようになっているので、ここで思わぬエラーに遭遇することがあります。
- また、これもHudsonと相性がいまいちな話ですが、ビルドされたartifactはデフォルトではHudsonに認識されません(ファイル指紋の記録などが行われない)。多分、release:perform内で起動されたもう1つのMavenプロセスはHudsonに認識されていないと思われます。
新方式のメリット
- シンプル
- 「clean deploy scm:tag」と実行しているだけなので、普段のSNAPSHOTビルドとほとんど変わらないビルドになります。これなら問題が起きにくいはず。
- Hudsonとちゃんと連携できる
- maven-release-pluginでのビルドと異なり、デフォルトでファイル指紋の記録も行われますし、成果物も保存されます。
- また、META-INF/MANIFEST.MFにHudsonの環境(ビルド番号やSVNリビジョン、日付など)を埋め込むことが簡単にできるというのもメリットですね。Hudsonの環境変数についてはhttp://d.hatena.ne.jp/kaorun55/20090210/1234274938で紹介されてます。
まずは3つくらいのプロジェクトをこの方式に変更してみました。しばらく様子を見て、問題なければ他のプロジェクトもこの方式にしようと思います。
具体的なpom.xmlの書き方とか、Hudsonの設定については追々書こうと思います。
