システム開発において、構成管理(バージョン管理)はとても重要です。
構成管理を正しく行うことで、品質(Quality)、予算(Cost)、納期(Delivery)を達成させることにつながります。
仕様書、設計書、ソースなどの成果物に対して、構成管理をしていないプロジェクトは、様々なリスクを抱えます。
同一の設計書やソースを複数の人が同時に修正をしていた場合、競合が発生します。その場合、どちらかが上書きされてしまい、修正したものが消えてしまう可能性があります。また、最新版の設計書やソースがどれなのかわからなくなる可能性もあります。
このような状況では、とても、品質が保てるものではありません。
そこで、複数の人が同時に修正することを想定して、修正した順番に「履歴」としてバージョンを管理していく方法、考え方が、構成管理、いわゆるバージョン管理なのです。
ここでは、この構成管理(バージョン管理)の重要性や履歴という考え方について学んでください。
構成管理(バージョン管理)とは?
冒頭でも書きましたが、構成管理(バージョン管理)とは、仕様書や設計書、ソースなどの成果物を、修正した順番に履歴として残すことです。
履歴として残すということは、今現在の最新版になるまでの軌跡が分かるということです。
例えば、今現在の最新版のバージョンが5.0だとすると、1.0や2.0のバージョンの内容が分かるということです。
ですが、単純に軌跡を残すのであれば、ファイルサーバー上に日付やバージョン等のフォルダを作成し、そこに格納することで同様のことが実現できます。
では、なぜ、構成管理をする必要があるのでしょうか?
それは、システム開発は「複数の人で行う」からなのです。中には、一人の場合もありますが、ここでは省きます。あくまで、一般的なシステム開発として説明します。
ひとりで行うのであれば、自分だけが注意すればいいのです。
しかし、複数の人が行う場合は、構成管理という概念が必要になってきます。
それは、同じ設計書やソースを同じ人が行うとは限らないからです。
そして、逆に、同じ設計書やソースを複数の人が修正することがあるからなのです。
システム開発の現場では、長く続くシステムのバージョンアップなどで、同じソースを何度もツギハギのように修正していくことが多々あります。
そして、やっかいなことに、同じソース内に、別機能が含まれている場合もあります。
例えば、Aというソースに、B機能とC機能が存在していたとします。Dさんは、B機能を、Eさんは、C機能を担当します。そうすると、DさんもEさんもAというソースを同時に修正することになるのです。
お互い、修正したところを把握していればよいですが、まったく別チームの人だった場合、DさんはEさんを、EさんはDさんを知らないということも有り得るのです。とても、こわいことが想像できます。
ヘタをしたら、どちらかの修正したソースが消されてしまうかもしれないのです。そんなことがあっては絶対ならないはずです。分かりますね?
これらを回避するために、構成管理(バージョン管理)の役割があるのです。
構成管理(バージョン管理)の導入や運用はどうするのか
構成管理(バージョン管理)の重要性は理解していただいたかと思いますが、実際にどのように導入すればよいのでしょうか?
ここでは、細かく、導入手順等の説明は省きますが、その考え方について説明していきます。
構成管理を行う上で、必要になるのは、構成管理用のクライアントとサーバー、そしてツールになります。
構成管理用のツールは、以下の2種類があります。
- 集中型
- 分散型
集中型とは、1つのサーバーが全ての履歴を管理するようなイメージです。複数の開発者が設計書やソースなどの出し入れを、この1つのサーバーに命令し、バージョンを管理してもらうのです。
このサーバーのことを「リポジトリ」といいます。
ソースなどを出すことを「チェックアウト」、ソースなどを入れることを「コミット」と呼びます。
コミットされるたびに、バージョンが上がって行きます。また、異なるバージョンのソースを並行で管理することも可能です。それをブランチといいます。
この方式は、Subversion(サブバージョン)やCVSといったツールの方式になります。これらのツールは広く現場で採用されている構成管理ツールの一つです。
ですが、これらは、同一のソースを複数の人が修正するケースが多発するような場合には向いていません。
競合が発生しやすく、のちに、いったん、最初の人がコミットをかけ、次の人が、チェックアウト、修正、そしてマージという作業を行い、反映させる必要があり、注意を払う必要があるためです。
ですので、最近では、GitやMercurialといった、分散型のツールが広まり、今では、人気はSubversionを超えています。
例えば、Gitでは、サーバーだけではなく、クライアント側、つまり自分のパソコン側にもリポジトリを設けています。ですので、同じソースを複数の人が修正していても、自分のパソコンのリポジトリに反映されていきます。
そして、最終的にサーバー側のリポジトリにコミットする際に、後からコミットした人のソースに対して、最初にコミットされていたソースがマージされます。
上書きされて消されることなく、きちんと両方の修正内容が反映されます。
ざっくりと、構成管理ツールについての説明をしましたが、実際には、どのように成果物を管理していくのかを計画し、ツールを導入する流れになるかと思います。
どちらのツールを採用するかは、プロジェクトによると思いますが、あまり競合が発生しないようなプロジェクトであれば、Subversionがおすすめです。運用が簡単であることが理由です。
ただし、競合多く発生しそうなプロジェクトでは、Gitがおすすめです。
迷った場合には、Gitにしておくと無難でしょう。
運用としては、設計書やソースの修正手順などもまとめておくように心がけてください。
せっかく、構成管理ツールを導入しても、面倒くさくて、使ってないなんてことは、論外ですから。
最後に、参考として、SubversionとGitのリンクを載せておきますので、参考までにどうぞ。
・Subversion
・Git
カテゴリ:構成管理