これからが本番、検索エンジンから来た方は先に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のフックスクリプトですが

1. pre-receiveでpush前の状態をタグ付けする設定を追加
2. post-receiveでHudsonの複数ジョブをキックして起動。
   1. テスト結果を取得して全て成功したらタグを消してgit svn dcommitを実行
   2. 1つでも失敗していたらpre-receiveでタグ付けしたバージョンに戻してpushをなかった事にする。

とすることでいけそうです。Hudsonのジョブ実行結果を知る方法は複数あると@masanobuimaiさんに教えてもらったのがPlugins – hudson – Hudson Wikiのページです。プラグイン無しでもリモートAPIを使っても出来るのかもしれません。
自前でフックスクリプトを用意する必要がありますが、出来ないことはなさそうです。
post-receiveでのテストに多少の時間がかかることを踏まえ、Redmineで参照するリポジトリはGitではなくSubversionにするのが良さそうです。

あとはRedmineのメール経由のチケット登録機能を有効にして、HudsonのナイトリーテストでこけたらカスタマイズしたメールをRedmine指定のアドレスに送ればOKですね。上の絵には「静的解析とメトリクス集計」が入ってますが、これは内製ツールです。リポジトリを集中管理してもらえるとこういうこともやってもらいやすくなりますね。

上記構成に3月中に取り組む予定です。うまく行くといいんだけど。

会社の仕事を「Gitを中心に据えた開発ワークフロー」に変えたいなとこの週末ぼんやりと考えていたんですが、現状を整理して残しておくのも、あとで振り返った時も参考になるかもしれないと思って残しておきます。

開発しているものは画像処理ライブラリで、言語はC言語。プラットフォームはWindowsとLinux両方に対応していて、32bitと64bitどちらでも動くようにしたいのが前提。ほとんどのソースは共用出来るようにしています。開発者はWindowsを使ってVisualStudioで開発し、自動テストやリリース時はLinuxでMakefileを使ってビルドします。

バージョン管理は課で管理しているSubversionを使い、他のプロジェクトともリポジトリを共用しています。他に使っているツールはテスト自動化にHudsonとタスク管理と障害管理でRedmineがあります。Hudsonは2種類のテストを管理していて、コミットの度に動くビルドのテストとCUnitを使った単体テストと、毎晩複数枚の画像入力を処理するストレステストの実行を制御しています。Redmineはチケット駆動開発(TiDD)を意識し、コミットはチケットに関連付けるようにしています。あとは開発者の1人(自分です)がgit svnを使ってローカル開発をgitにしているぐらいです。

開発メンバは社内に2人、あとは社外の協力会社に手伝ってもらっています。両者の間にはネットワーク的に「超えられない壁」があり、リポジトリを参照させることができません。ということで双方でSubversionリポジトリを持ち、同期は定期的(1〜2週間おき)に差分ソースを送り合って手動で実行しています。

ここまでが現状の紹介、以下は上記フローによる問題点です。
問題１　双方でのソースの同期を取るのが大変
一週間から二週間に一度差分ファイルを送り合ってるけど、マージに時間がかかる上、複数の変更がごっちゃになっておくられてくるためレビューしたくても途中で断念してしまう。

問題2　単体テストが通らないコミットが履歴に残り消せない
ちょっとしたミスがあってビルドに失敗してもsvnの履歴が消せない。Windows上での単体テストはコミット前に確認するけどLinuxで毎回やるのが面倒になったり、32bitと64bitを全組み合わせでやるのは面倒だったりする。動くだろうと思ってコミットすると壊れていたりとか。
あとはgccでは警告をエラー扱いしているので、使われてない変数があるとかその程度のことでエラー扱いされてしまう。

問題3 闇コミット
RedmineでTiDDに近いことをしているが、闇コミットが結構ある。スタイル直しただけとか、変数名リファクタリングしたとか。複数プロジェクトでリポジトリを共用してるからチケットIDが無いコミットを弾くのが難しい

問題4 Redmine上でチケットとコミットの関連付けを直せない
テストで問題が見つかってもRedmineのチケットとコミットの関係を直すことが出来ない。間違ってるfixesが残ってしまい、何とも出来ない

問題5 HudsonでビルドにコケてもRedmineのチケットに自動登録されない
Hudsonでコミットごとの単体テストとは別にストレステストを含むナイトリーテストを設定しているが、テストに失敗した時にRedmineのチケットが自動登録されない

問題6 TortoiseSVNのパッチ機能が腐ってる
外注からパッチで差分を送ってもらうことも考えたが、TortoiseSVNの文字コード認識がおかしく、一度エディタで開いて文字コードを保存し直す必要があった。（ちなみにソースはUTF-8）

問題7 機能ブランチの管理が大変。
一度切るとなかなか戻ってこない。戻すにも準備がかなり必要になる。試しに作ったけどいらなかったブランチも扱いに困る。

問題だけ見ると「何でこんなフローにしたんだ」と自分でも思ってしまうけど、少しずつプラクティスを取り入れた結果うまく連携できてない現状になってしまった。近々Subversionのリポジトリを課管理から本部管理に移行するお仕事があるのでこれを機にこれまでの問題点を解消しようと思っています。

詳細は後半で → Subversion, Git, Redmine, Hudson – 今考えている連携 » tune web