構成管理手段が作業手順を定義している

1月 14th, 2010 by tune Leave a reply »

今更な話なんですが・・・

ソフトウェアの構成管理をするのは今時当たり前ですが、構成管理システム(バージョン管理システム)の使い方は千差万別です。今でもローカルフォルダに置いてあるとか、ネットワーク上の共有フォルダに置いてあるとか、外注先のローカルフォルダに置いてあるとか、ひどい例を探していくといくらでも考えられます。うちの一昨年の新人曰く「フォルダを作ってフルバージョンを残しておくこと」なんて新人犬種で教わってきたらしいので、ひどい世の中です。

新しい順に分類すると

  • 分散型バージョン管理:Git / Mercurial / Bazaar
  • 集中型バージョン管理:Subversion / Perforce
  • 集中型の旧世代:CVS / Visual Source Safe
  • 古代:フォルダを分ける、共有フォルダに置くとか。

といった形でしょうか。

そして、どうしていつまでも古いやり方を踏襲する人がいるのかという話です。勉強する時間が無いとか、やり方が分からないとか、組織で決められているとかいろいろ理由があるとおもうのですが、「使っている構成管理ツールにあわせて作業手順を決めているから、より優れたツールがもたらすメリットを説明されても何を問題としているのかわからない」という発想がふと浮かびました。

フォルダ管理の人は、一人でしか開発してないから複数人で共有する時の話をしてもピンとこない。もしくは構成管理も含めて外注しているからたまに来る納品物を共有フォルダに置いておくだけで十分なんでしょう。

CVSの人はソフトウェアのバージョンは1.X.Yみたいに増えていくものと信じ込んでいて、複数ファイルをまとめて管理するなんて発想はないんでしょう。VSSの人はファイルをいじるときは一人が長期間ロックするものだという前提があるんでしょう。

Subversionの人はブランチは大きな機能を追加するときにたまに使うものだと思ってるんでしょう。

構成管理ツールと言うのは単に機能を提供するだけではなくて、ソフトウェアの手順を暗黙的に決めてしまいます。逆に考えると、新しいツールを使うときは新しいやり方を最大限活かせるように作業手順を作りなおさないとダメでしょうね。

入門Gitを読んでいて感じたことが、ようやく自分の中で咀嚼できた気がします。

Advertisement

Comments are closed.