確か、日経システム構築の今月号（２００５年１２月）に、ＣＶＳを使って、ドキュメント管理とソース管理、システムの自動生成テストを行い、オフシェア（中国利用）で開発した例が載っていたと思います。
ですが、そこでは、単に成功事例だけで、一般的に、どういう問題が起こり、どういう対策ができるか？なぜ、そういう手法をとったのかについては、かかれていなかった気がします。
そこでウィリアムのいたずらが、今日はまず、ＣＶＳによる構成管理の問題点と、その対応策について（この点に注意すれば、けっこうおおきな開発でも使えそうという話）を書きます。
まず、ＣＶＳによる集中型の構成管理（１箇所をＣＶＳサーバーにして、すべてそこに成果物をおき、管理する方法）は、そこにも指摘されていたように、オフショアでは問題ありますし、そうでなくても難しいと思います。
そこに指摘されていたのは、中国の通信事情でした。
これは、中国の一般的なソフトハウス（注：中国の場合、大学が直営？のソフトハウスを持っている場合があり、その場合は、事情が違うかもしれない）の場合、通信回線が（厳密に言うと）「遅くなることがある」ということです。
これについては、中国のＩＸについての事情があるかもしれません。
日本と違い、外国への通信をするためのＩＸは。。。（いわないでおこう。。壁に耳あり商事にメアリー：ちょっとちがう？調べれば分かる）。
（中略）
てなわけで、通信事情に、問題がある「場合がある」のですよ。
それに、日本でも、ある場所にサーバーをおいてソース管理するといった場合、わけもわかんないフリーの人や、大手競合会社が入ってきていいのか？という問題があります。
（最近のシステムでは、ＦＮＨＩの複数が部分的に受託するということがある）
ということで、自然と、分散型の構成管理になります。
この方法は、ある一定時間に、自動的あるいは手動的に、ネットワークあるいはフットワーク（だれかが持っていくということ、別にフットワークの配送に限ったわけでなく、一般名称）を使って送り、全体を構成管理するサーバー（ＣＶＳサーバーでも、なんでもいいんだけどね）に送ります。
このとき、構成管理の追加、変更の申請書があると、作業的に、実はバグ発生時のバージョン管理で楽なんですけど、そんなことは、ＯＳＳ信奉者には、「面倒になるだけだ」といって、受け入れられないことなんで、書いてもらえない気がします（といいつつも、この書類を、「やみくもに」書かされることもある。その場合は、この書類を十分に使いきれていない。つーか、なぜ書くのか分かっていないことも多かったりする。結合テスト以降のバグのときにつかう）。
この場合の問題は、多くは結合テスト以降で起こります（それ以前では、起こらない。また、中小規模では起こらない。開発場所がある程度多くないと起こらない）。
■問題１ （集中型でも、分散型でも起こります）
ある会社が、呼び出されるほうの”インターフェース（引数または返り値などの）の”修正を行ったとき、一部の会社は対応しているが、ほかの会社は対応していないため、コンパイルができなくなることがある。
この場合、バグフィックスを確認するためのテスト確認作業が（コンパイルができなくなるので）遅れる。
■問題２ ＣＶＳから、更新されたソースだけを入れ替えて、独自で、コンパイルしてテストされた場合に問題が起こる。
あるいは、jarファイルの一部だけを持ち帰ってテストされたときなどで。。
そうすると、バグが起こっても、どの状態のソースのときに、バグがおきたのか分からない
たとえば、ソースＡ，Ｂ，Ｃ、Ｄ，Ｅとあったとき、
１０：３０分にソースＢが
１０：５０分にソースＤが
１１：００分にソースＢ、Ｃが更新されたとする。
このとき、勝手に最新版をとってきて、テスターがテストしていいとしたとき、
（ありえないけど）
テスター甲は、１０：４５分にソースを落とし、１０：５５分に、ソースＥの箇所で起きたバグを発見し、１１：１０分に報告したとする。
その時点で、Ｅの担当が１１：１５分に、ソースを入れ替えて見ても、再現しなかった場合、何が原因なのか、わからない。（この場合、ソースＢのバグがＥに影響したもので、１１：００の修正版で直ってて、今のソースでは、自然治癒している可能性がある）。バグ票に、発見時間が書いてあったとしても、更新が頻繁に行われ、かつ、すべての時計の時刻が必ずしも正確でないという状況の場合は、意味がない。
→この問題は、実は起こらない。必ず対策が行われるので。
そして、このための対策として行われることのために、実はＣＶＳの利用は広まっていない。
■■ 対応策
●問題２についての対応策
・後者の対応として、ビルド番号（ないしはバージョン番号）をいれて、一定時刻にコンパイルするようにしています。
そして、バグ票には、かならずビルド番号をいれます。
テスト対象になるのは、このビルド番号を持っているオブジェクトのみです。
上記の例の場合、１０：３０、Ｂがいれたあと、一斉ビルドを行い、bild no 200511291145というものだったとしたら（めんどーなので、ＮＯを時刻とした）、バグ票にそうかかれるので、開発の人は、現在のバージョンで再現しない場合、このビルドＮＯのオブジェクトとソースを取り出して確認するので、問題箇所を再現できます。
ふつう、このような形で管理していると思います。
あの日経システム構築の場合も、この手法でしたよね。一定時間でのコンパイル。
だからこの問題は、起きません。
しかし、こうやってやる場合、そのコンパイル時間前までに、ソースをある場所にＦＴＰで送って（ＨＴＴＰやＨＴＴＰＳでアップロードでも、いいけど）、そのあとmakeでプログラムを実行して、ビルドしたオブジェクトを公開、ソースを退避させ、保存しておけばいいじゃん！っていうことになります。
そのとおりです。。
でもそうすると、ＣＶＳいらないです。
事実、ＣＶＳのような構成管理ルーツは使わないということも多いですよね。
ちなみに、このため、バグ票に、ビルド番号（ないしはバージョン番号）は絶対入れてね！
●問題１についての対応策
前者の問題は、現在、マネージャーレベルで、打ち合わせして、「いっせのせ！」で、ある日のバージョンに入れるということで対応していますが、連絡ミスなどの問題が発生することが多いです。
（なお、このためにも、バージョン（一定時間のビルド）という概念が必要になってきます）
なので、それへの抜本的な対策は、インターフェースを基本的に共通にして、新旧、どちらの引数でも送れるようにして、引数内にバージョンをいれ、そのバージョンを見て、それなりの処理をすればいいです。
この方法として、ハッシュマップや連想配列を使う方法については、前にブログに書きました。
ここ
なお、前のバージョンで使ったソースは、できるだけ消さないほうがいいです。
前に戻すこともけっこうありますので。。。
ただ、そーすると、みにくくなっちゃうんですよね。ソースが。
//DEL Ver1.0
//
//
//DELEND
とかが、いっぱいでてきちゃって。。
なので、メソッドレベルで、たとえば、
バージョン1.0なら、a_1_0,
バージョン1.1なら、a_1_1
というかんじで、バージョンごとにメソッドをつくっちゃって、こぴぺで対応するのも、いいかもお。。そー言う意味でも、コントローラーが必要だったりする。
●そのほかの構成管理の問題と対策
そのほかの問題として、デグレードと、それを起こさないための、リグレッションテスト（回帰テスト）の実行方法の問題があります。
これについては、テストの自動生成って言う話になるのですが、それについては、その日経システム構築の記事にもかいてあったし、まあ、ここのブログでも書いた気がする（どの記事かは忘れた）なので、今回は省略
思いついたところは、こんなかんじ。
結局、まとめると、日経システム構築の記事は、成功の秘訣がＣＶＳによる管理のように読めてしまうんだけど、ＣＶＳによる管理は、基本的には集中型に向いている（常時ネットワークが見れる）のであって、記事のように分散型にするのであれば、ＣＶＳでなくても、別にかまわない。
むしろ、あの記事での成功事例は、テストの自動生成と確認部分にあって、それを実現するには、インターフェースのミスマッチ（上記問題（１）のこと）を防ぐということで、そのインターフェースミスマッチを防がないと、オフシェア開発は難しいんだけど、そこの部分の対策については書いてなかったね。
つーような、オフシェアの話は、今度、気が向いたときに。。。
もう、長くなりすぎちゃったので。。
アクセス
トータル
ランキング
