ぼく自身、git-flow を利用するのは始めてで、Maven 力も低い。 そういう人間がリリース時にどうしようかとか考えても仕方がないので、先人に頼るかーと思っていたら、ちょうどいいエントリがあった。
Why I Never Use the Maven Release Plugin - DZone Java
このエントリ、基本的には maven-release-plugin を dis るエントリなんだけど、dis だけでなく、じゃぁどうやって「リリース」という作業を実現するのかが述べられているのが良いと思う。 git-flow を利用する maven 環境のエンジニアが遍くこういうフローを使っているかは知らないけれど、ぼくが考えるよりもずっと精度が良いと思うので、メモがてらまとめてみる。
リリースフロー
- リリースすることを全員に伝え、必要なリソースを development ブランチに push してもらう
- development ブランチから release ブランチを切る
- development ブランチの POM のバージョンを、次バージョンに更新し、commit & push しておく。
- release ブランチの POM バージョンを CR (Candidate Release) のバージョン (ただし、SNAPSHOT)に更新し commit & push。
- release ブランチでテストを実行し、PASS させる。
- release ブランチから Candidate Release のビルドを作成する
- release ブランチの POM バージョンを CR のバージョン (SNAPSHOT なし) に更新し、commit & push
- release ブランチで tag を切る
- の POM バージョンで再度更新し、commit & push
- 6-2. のタグで checkout
- deployment build を実行する
- deployment を QA 環境にデプロイする
- QA 環境で、テストを PASS させる。ここで出たバグは release ブランチで修正し、development ブランチに定期的に merge する。
- 実行手順は、バージョンが CR2, CR3 と上がっていく以外は 6. の通り
- 最終リリースを作成する
- 正式なリリースバージョンで POM のバージョンを更新する
- release ブランチのタグを切る
- release ブランチを master ブランチにマージする
- master ブランチを checkout する
- deployment build を実行する
- 本番リリースを開始する
git-flow を眺めるだけでは分からなかったけど、リリースフローはなかなか複雑なかんじになる。たいへんそう。 もうちょっと省力化したいけど、そうすると maven-release-plugin の再発明になって、エントリの著者に dis られそう。