«前の日記(2010-04-03 (土)) 最新 次の日記(2010-04-16 (金))»  

まちゅダイアリー


2010-04-06 (火)

「申請書を書いて上司の判子もらわないと svn commit すらできない」場合もある

今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました - SiroKuro Pageを読んだ。

専任のSubversionオペレータなる人がいるらしく、受理された申請書と変更ファイル(を入れたUSBメモリ)をSubversionオペレータさんに手渡すと、あとはオペレータの人が代わりにコミットしてくれるみたいですよ

申請書やUSBメモリといった方法はともかく、気持ちは分からなくもないなぁ。

コミット時のチェックが必要になる場合

まず、20人程度でメンバーがそれなりのスキルを持つチームなら、もちろんこんな方法は必要ない。 全員がコミットできるようにして、コミット時のルールを統一しておけば十分回るだろう。

でも、1人が全体を把握できないほど人数が増えてきてソースコードの規模も大きくなると、自由にコミットできる環境では問題が増えてくる。 例えば、誰かが黙ってバグを修正しようとして、他の機能が動かなくなるような変更を加えちゃったり、「svn commit *」と入力して本来コミットすべきでないテストコードまでコミットしちゃったり。 バージョン管理システムだから後から戻せる…と思うけど、コミットログに「foo.rbを修正」と書かれるような状態だったりして、膨大なコミットから問題の箇所を特定するのは大変だったりする。

オープンソースのプロジェクトでも「コミット権」があるように、必ずしも誰もがコミットできる環境がベストじゃない。 それに、良くも悪くも最近は「承認」に基づく変更管理が求められるようになっている。

分散SCMだけでは解決策にならない

「分散SCMを使えばいい」というコメントを見かけたけど、問題はそこじゃない。 「Gitでローカルで管理」することは有効だけど、マスターのリポジトリへコミットするときには申請書を書いて専任オペレータへソースを渡さないといけないことは何も変わらない。 せいぜい、ソースコードの受け渡し方法として、USBメモリの代わりに専任オペレータによる git pull を使えるくらいか。

ちょっと話がそれるけど、前に似たような状況に遭遇したときには、自前で別のSubversionリポジトリを立てて管理していた。

コミット対象を適正にチェックできているかが大切

もちろん、EXCELシートの申請書や上司の判子や専任のSubversionオペレータという対策がベストではない。 上司は何に基づいてコミットを許可しているのか。専任のオペレータは申請書に書かれた修正内容とUSBメモリの内容が同じことをチェックしているのか。

この辺はnullpo.printStackTrace();に同意。

システムを理解している現場の担当者がオペレータを兼任して、その責任でコミットするというならまだ分かる。しかし、判子を押す上司はコードの妥当性も正当性も判断できない。一体、何を承認しているんだろう、何のために存在してるんだろう。

仕組みを作っても目的どおりに働かなければ意味が無い。 そして、EXCEL申請書やUSBメモリといった手段は、目的に対して重すぎるように思う。

バージョン管理システムは構成管理の一部でしかない

冒頭の話に戻って、 Subversion がいびつな形で使われているのは、バージョン管理システムだけで構成管理を実施しているから。 Subversion や Git などのバージョン管理システムはソースコードの履歴を管理してくれるけど、それらの変更が適切にルールに則って実施されているかまでは管理してくれない。 その足りない部分がEXCEL申請書やUSBメモリといった非効率な手段になっちゃっているのかと。

このチームに必要なのはバグ管理システム (BTS) じゃないかな

ここが一番言いたかったところ。

この話の問題は上司の判子が必要なことではなく、判子を押す手段が非効率であること。 ソースコードのコミットに承認が必要であれば、承認プロセスを含めてシステム化することが大切。 Trac や Redmine や Mantis なんかのバグ管理システムを使うのが解決策なんじゃないかな。

  1. 申請書(チケット)を作成する
  2. 上司がチケットを承認する
  3. チケット番号とともにソースコードをコミットする

よくわかんないコミットをなくす手段としての「チケット無しのコミット禁止! (No ticket, No commit)」という話は、2007年にチケット駆動開発のプレゼンでも話した。

まとめ

  • コミット内容のチェックは大切
  • バージョン管理システムだけでは構成管理できない
  • BTSと組み合わせると幸せになれるかも

おわりに

今回の話は、やりたいことは間違っていないけど、やろうとしている手段が非効率なんだと思った。 願わくば、手段を決める人たちに読んでもらえると嬉しいなぁ…。 久しぶりに長い日記を書いたので、思ったよりも時間がかかったよ。

Tags: memo
本日のツッコミ(全1件) [ツッコミを入れる]
SiroKuro (2010-04-24 (土) 12:22)

EXCEL と Trac の2重管理ですよ。