運用中のソフトウェアでもバージョン管理システムをSVNからGitにすべき理由
運用しているソフトウェアのバージョン管理システムを変更するには、開発責任者や間接的に影響の出るステークホルダーへの説明が必要です。ただ、バージョン管理システムというツールの性質上、変更するメリットや必要性についてはなかなか理解されません。
私自身、SVNというバージョン管理システムを使用しているソフトウェア開発に携わっていますが、長らくその問題点については気づいていませんでした。
しかし、平行して複数の機能を開発した時に、バージョン管理にかかるコストが爆発的に膨らみ、SVNを使い続けるリスクを身を持って感じました。そこで、この記事ではSVNやVSSといった前時代のバージョン管理システムを使い続けるリスクとその解決方法についてご紹介します。
バージョン管理システムとは
バージョン管理システムは、ソフトウェア開発に必要な最重要ツールのひとつです。バージョン管理システムという言葉を初めて聞いた人や、よく知らない人は、以下のページに概要や必要性がわかりやすくまとまっているので読んでみてください。
（上記ページより抜粋）バージョン管理システム(VCS)を使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を見直したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。
現在、新しいソフトウェア開発の現場では、Gitというバージョン管理システムを使うことがスタンダードになっています。少し前は、Subversion（SVNと呼ぶのが一般的）やVSSというバージョン管理システムが主流でした。
バージョン管理システムを正しく使う
バージョン管理システムをただ使うだけでは、複雑化・大規模化するソフトウェア開発を安全かつ速く進めていくことはできません。
例えば、以下のような変更履歴のあるファイルを想像してください。
// あるファイルの変更履歴
1. いいねボタンを押すと投稿に「いいね」できる
2. いいねボタンを押すと投稿に「いいね」できる（バグ修正）
3. iPhone5だけうまくいかなかったので修正
4. いいねボタンを長押しすると、6種類のリアクションを選べるようにした
5. iPhone5だけうまくいかなかったので修正
6. バグ修正
7. いいねボタンにハートアイコンをつけたファイルを以前の状態に戻せるといっても、いつ、どんな変更を行ったかを誰が見てもわかりやすくしておかなければ意味がありません。同じファイルでも以下のようになっているとだいぶわかりやすいですね。
// わかりやすい変更履歴の例
1. いいねボタンの新規作成
2. [機能追加]いいねボタンを長押しすると、6種類のリアクションを選べる
3. [緊急対応]いいねボタンをクリックした時に他の人にいいねしてしまうバグを修正
4. [機能追加]いいねボタンにハートアイコンをつける実は、この程度の変更履歴であれば、最初の例でも、それぞれの詳細な変更内容を目で追っていけばなんとかなるかもしれません。ただ、長年開発を続けていると変更履歴が1万を超えることはよくあります。1万個、目で追うのは現実的ではないですね。
誰が見てもわかりやすい変更履歴になるように心がける。これがバージョン管理システムを使ううえで最も重要なことだと私は考えています。
とはいえ、最初から見やすい変更履歴になるように開発を進めることは現実的ではありません。最初からバグのないプログラムをかける人間はいないでしょう。
しかし、もしもある程度バグを修正し終わったタイミングで変更履歴を整理できれば、誰でも心がけ次第で綺麗な変更履歴を作ることができそうです。少し先出しになりますがGitは、後から変更履歴を整理することができます。
SVNの問題点
これまでにバージョン管理システムの概要と正しい使い方について説明しました。バージョン管理システムは、ファイルの変更履歴を残すためのツールで、変更履歴をわかりやすくすることが重要でした。ただ、最初からわかりやすい変更履歴にすることは難しいので、後から整理するのが現実的なアプローチでした。ここまで読むと、なんとなくSVNの問題点がわかってきたかもしれません。
SVNの問題点、それは、変更履歴を後から整理することができないということです。SVNは「集中バージョン管理システム」とも呼ばれ変更履歴の改変は不可能な作りになっています。
なぜ改変できないのかを知るために、簡単に集中バージョン管理システムの仕組みの説明をします。集中バージョン管理システムは、バージョン管理したすべてのファイルを保存している1つのサーバ（概念図のCentral VCS Server）と、そこからファイルをコピーして編集する複数のクライアント（概念図のComputerA, ComputerB）で構成されます。クライアントがファイルを変更し、バージョン管理システムに登録すると、直ちにサーバに変更内容が書き込まれます。その後、別のクライアントがサーバから最新版のファイルを取得すると先ほどの変更が反映されます。もう少し詳しく知りたい人は、以下のページなどを参照するとよいと思います。
この方法では、開発が進めば進むほど変更履歴が混沌とし、問題が発生した時に変更履歴を追うことが難しくなっていきます。
だからGitが必要
この問題を解決するためにGitが必要です。Gitは「分散バージョン管理システム」とも呼ばれ、変更履歴をある程度、改変することが可能です。
分散バージョン管理システムは、集中バージョン管理システムに比べて少し複雑ですが、簡単に仕組みを説明します。分散バージョン管理システムは、バージョン管理したファイルをすべて保存したサーバ（概念図のServer Computer）とサーバの内容をまるっとコピーしたクライアント（概念図のComputerA, ComputerB）で構成されます。集中バージョン管理システムでは、クライアントはファイルのみをコピーしていましたが、分散バージョン管理では変更履歴を含めてすべてコピーします。クライアントがファイルを変更しバージョン管理システムに登録しても、サーバ側とは一切やり取りを行いません。クライアント内のコピーしたバージョン管理システムにのみ変更内容を書き込みます。こうすることで後から変更履歴を整理し、任意のタイミングでファイルと変更履歴をまとめてサーバに書き込むことが可能になっています。詳しく知りたい人は、Gitの公式ドキュメントを読むと理解が深まるでしょう。
移行リスクやコストについて
ここまでご説明しておきながら、まだ実際に移行したことがないので正確なことはわかっていません。この記事で上司を説得し、移行できた際に改めてお伝えします。
