これからが本番、検索エンジンから来た方は先にSubversion, Git, Redmine, Hudson – 現状の連携 » tune webを読むことをおすすめします。上記が週末考えていた「こういう連携なら今の問題点を解消できるかな」と思えるフローです。「こうしたほうがいいよ」とかコメントありましたらお待ちしています。
1番のポイントはバージョン管理システムとしてGitを中心に据えました。社内はSubversionで統一するという規則があるので残すとして、開発チーム内ではgit svnを使ってGit化し、Subversionを直接触らないようにします。協力会社はSubversion縛りが無いのでGitで統一してもらいます。これまでは差分ファイルを送り合っていましたが、Gitを使えばパッチをうまく作り、修正単位でパッチファイルをやり取りすることが出来るでしょう。これまでは複数の修正がまとめて送られてきてましたが、パッチ単位ならレビューもやりやすく、「こうした方がいい」とか「こうして欲しい」というやりとりもやりやすくなります。
リポジトリがプロジェクト専用になるので、フックスクリプトも仕掛けやすくなります。現状は「空メッセージのコミットは禁止」程度の緩めのものですが、コミットメッセージに Issue ID を含むことを強制させる Git のフックスクリプトを書きました｜SNS構築の手嶋屋を参考にすればRedmineのチケットが無いコミットは禁止できます。これで闇コミットがなくなるはず。
さらにGitを使えば「歴史を書き換えて」テストが通らないコミットをなかった事にも出来るはずです。コミット前にテストをする機能がTeamCityにはありますが、Hudsonにはありません。[#HUDSON-1682] Pre-tested commit feature – Hudson JIRAとして要望が挙げられていますが実現はまだ先になるでしょう。HudsonのGit Pluginのページにpushされた変更をテストして、成功したらmaster/stableにマージする設定手順がありましたが、リリースブランチを持ったときにも同じように出来るかは不明です。
というのをtwitterにつぶやいていたところ、@bleisさんと@masanobuimaiさんから情報をもらえました。Gitのフックスクリプトですが
- pre-receiveでpush前の状態をタグ付けする設定を追加
- post-receiveでHudsonの複数ジョブをキックして起動。
- テスト結果を取得して全て成功したらタグを消してgit svn dcommitを実行
- 1つでも失敗していたらpre-receiveでタグ付けしたバージョンに戻してpushをなかった事にする。
とすることでいけそうです。Hudsonのジョブ実行結果を知る方法は複数あると@masanobuimaiさんに教えてもらったのがPlugins – hudson – Hudson Wikiのページです。プラグイン無しでもリモートAPIを使っても出来るのかもしれません。
自前でフックスクリプトを用意する必要がありますが、出来ないことはなさそうです。
post-receiveでのテストに多少の時間がかかることを踏まえ、Redmineで参照するリポジトリはGitではなくSubversionにするのが良さそうです。
あとはRedmineのメール経由のチケット登録機能を有効にして、HudsonのナイトリーテストでこけたらカスタマイズしたメールをRedmine指定のアドレスに送ればOKですね。上の絵には「静的解析とメトリクス集計」が入ってますが、これは内製ツールです。リポジトリを集中管理してもらえるとこういうこともやってもらいやすくなりますね。
上記構成に3月中に取り組む予定です。うまく行くといいんだけど。
.gif "ラベリング処理のイメージ図")
