構成管理(バージョン管理)とは何か?履歴という考え方を学ぶ

目安時間:約 9分

システム開発において、構成管理(バージョン管理)はとても重要です。

 

構成管理を正しく行うことで、品質(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

http://subversion.apache.org/

 

・Git

https://git-scm.com/

 

スポンサーリンク

 


カテゴリ:構成管理 

この記事に関連する記事一覧

ITエンジニアからコーチ・コンサル・カウンセラー・セラピストなどで起業してみませんか?
<管理人からのお知らせ>

ITエンジニアからコーチ、コンサル、カウンセラー、セラピストなどの起業家に転身している方が増えています。

管理人は、現在ネット集客コンサルタントとして活動しています。

ITエンジニアとしての強みを生かし、ネット集客システムを構築しながら、起業家に転身してみませんか?

Webから自動的にお客様(クライアント)を獲得し、安定的に稼げる方法をメルマガでお伝えしています。

興味があれば、下のメルマガ登録用バナーからメルマガ登録してください。

人気記事
プロフィール

こんにちは、管理人のあっきーです。

SE・プログラマになって30年の現役戦士です。

私が、30年のシステム開発経験で培ってきた困ったときの乗り越え方を教えます。

但し、対処法ではなく、私がお伝えするのは「思考法」です。

困ったときにこうすればよいという「行動」を教えても、その人にあうのかどうかはわかりません。ですから、「考え方」をお伝えするのです。

詳しいプロフィールは、
こちら。

最近の投稿
アーカイブ
カテゴリー
広告
ブログランキング参加しています。

ページの先頭へ