知らないと現場で困るバージョン管理システムの基礎知識：DevOps時代の開発者のための構成管理入門（3）（1/3 ページ）

「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする。今回は構成管理に不可欠ともいえるバージョン管理について、ブランチ機能を中心に紹介。SubversionからGitへの移行事例も。

[江口和宏, 山本竜三，株式会社ヌーラボ]

いまさら聞けない「バージョン管理」とは

　第3回目となる今回では、構成管理において「過去のある時点の状態をどのように復元するか」を実現するために不可欠ともいえるバージョン管理とバージョン管理システムについて紹介します。

「集中管理方式」と「分散管理方式」

　バージョン管理システムとは、ファイルに対して「誰が」「いつ」「何を変更したか」というような情報を記録することで、過去のある時点の状態を復元したり変更内容の差分を表示できるようにするシステムのことです。バージョン管理システムは大きく2つに分けると、「集中管理方式」「分散管理方式」があります。

　過去には集中管理方式の「CVS」「Subversion」が多く利用されていましたが、複数人での分散開発の容易さやパフォーマンスに優れた分散管理方式の「Git」「Mercurial」などがスタンダードになりつつあります。

Gitを中心に事例も交えてバージョン管理システムを解説

　本記事では、主にGitを使用した場合を例として進めますが、多くの概念は他のバージョン管理システムを使用した場合でも共通するのではないかと思います。

　筆者の所属するヌーラボでは、バージョン管理の入門者に向けのGitドキュメントとして「サルでも分かるGit入門」を公開しています。

なぜバージョン管理するのか

アジリティを高める

　前回の記事「ITS／BTSによるプロジェクト運営7つの勘所と手軽に使える5ツール」でも説明しましたが、バージョン管理の最も大きなメリットの1つが「アジリティを高める」ことです。

　バージョン管理を行っているソフトウェアでは、もし開発中にソフトウェアにバグを埋め込んでしまっても、問題の発生する以前の状態へ簡単に戻せます。

素早い開発が可能に

　また、ある環境でバグなどの問題が発生した場合には、過去にさかのぼって変更の差分を確認することで原因を分析したり、別に同じ環境を作って同じ問題が再現するかどうか調査できます。

　すると、ソフトウェアへの影響が大きな“変更”や試験的な機能の追加を安心して行えるので、結果として素早い開発が可能になります。

余計な情報でコードが肥大しない

　バージョン管理システムを使用すると、変更内容はバージョン管理システムに記録されるので、変更前の内容をコメントアウトしてコード中に残すようなことをする必要はありません。そのため、余計な情報でコードが肥大しがなくなるので、人が読みやすい状態を保てます。

何をバージョン管理するのか

　ソフトウェア開発の現場ではソースコードをはじめ、さまざまな成果物が作成されますが、どのようなものをバージョン管理すれば良いのでしょうか？

　それは、理想的にはある時点のソフトウェア・環境を構築するために必要なもの全てです。そうすることで、いつの時点のソフトウェアの環境でも再現できるようになります。

　具体的には以下のようなものが挙げられます。

• ソフトウェアのソースコード
• ビルドスクリプト
• データベースのスキーマ定義、マイグレーションの SQL、初期データ
• 環境構築用の設定ファイル・スクリプト

　逆に、次のようなバージョン管理する必要のないファイルや共有してはいけないファイルやバージョン管理システムでは管理しません。

• ソースコードをコンパイルしてできたバイナリファイル
• 秘密鍵ファイルなどの他人に見せてはいけないもの

ソフトウェアのソースコード→○

　まず、ソフトウェアのソースコードはソフトウェアを構成するものの中で、最も変更が加えられるものなので、バージョン管理をしない理由がありません。

ビルドスクリプト→○

　次のビルドスクリプトもソースコードをビルドするために必要なのでバージョン管理の対象になります。

バイナリファイル→×

　ソースコードをコンパイルしてできるバイナリファイルは、ソースコードをコンパイルすれば再現できるので特に理由がなければバージョン管理する必要はありません。

データベース→○

　次にデータベースです。データベースにソフトウェアのバージョンに対応したスキーマや初期データを構築するために必要です。

自動化スクリプト→○

　さらに、「Fabric」「Chef」「Vagrant」などの自動化ツールの登場により、仮想環境や物理環境などのインフラストラクチャの構築もスクリプトとして記述できるようになりました。

　これらの自動化スクリプトを用いることで、ソフトウェアを実行するインフラストラクチャもバージョン管理できます。

　ちなみに、Fabricは、Pythonでデプロイ・システム管理を行うためのライブラリです。ヌーラボでもデプロイに使用しています。ChefはRubyベースのコードで作業手順を記述できるサーバ構成管理ツールです。VagrantはコマンドラインからVirtualBoxやAmazon EC2などといった仮想マシンを構築できるツールです。

ブランチを中心に理解するバージョン管理システムを使ったソフトウェア開発

　ここからはソフトウェア開発において、どのようにバージョン管理システムを活用していけばよいのか、主に「ブランチ」機能を中心に紹介していきます。

「ブランチ」とは

　多くのバージョン管理システムでは、ブランチという仕組みが提供されています。バージョン管理システムでは「リビジョン」（コミット）という単位で変更内容を記録し、リビジョンのつながりによって履歴を管理しています。そこにブランチを使うと、その名が示す通りに履歴の流れを枝分かれさせることができます。

ブランチ

　ブランチによって枝分かれした履歴は、それぞれで行われた変更の影響を受けることなく進めることができます。そのため、機能追加やバグ修正などの複数の変更や複数人での開発を同時に、かつ安全に開発を進めることが可能です。枝分かれした履歴は、必要に応じてマージすることで双方の変更を1つにまとめられます。

　ブランチはマージしなければ他のブランチに対して影響を与えないので、プロトタイプ的な実装や実験的な変更も安心して試せます。最終的に、そのブランチで行った変更が必要ないと判断したならば、マージしないことで簡単に捨て去ることができるのです。

　また、前回の記事「ITS／BTSによるプロジェクト運営7つの勘所と手軽に使える5ツール」でも紹介したようにブランチ名にITS／BTSのチケット番号などを含めることで、さまざまな情報をブランチに対して結び付けることもできます。

　このように、使いこなすと非常に便利なブランチですが、万能ではありません。使い方を誤ると面倒な落とし穴にはまってしまう危険性もあります。