開発に欠かせない「バージョン管理システム」とは

こんにちは！R&Dのチャンウクです。

いきなりですが、みなさんは誰かとチームを組んで制作を行った経験はありますか？
もし行ったことがあるなら、その際「あれ？この箇所は誰が作業したんだろう？」「こうなる前はどうなっていたんだっけ？」などと、思ったことがあるはずです。
実はWEBアプリケーション開発において、こういったことは日常茶飯事。

なんでもかんでもソースにコメントを残してもコードの行数が増えるだけですし、簡単に解決してくれるサービスがあったら、とても助かりますよね。

というわけで、今回は開発者のそんな悩みを解決してくれるバージョン管理システムについて紹介いたします。

バージョン管理システムとは？

ここで出てくる「バージョン」は、みなさんが思っている一般的なあのバージョンでおそらく間違いありません。
でも「バージョンを管理する」ことのイメージがパッと浮かばないと思います。

ソフトウェアエンジニアリングにおいて「バージョンを管理する」というのは、ソースコードの修正履歴に一定規則のバージョンを与え、そのバージョンを参照しながら、詳細の閲覧および比較するなどの一連の活動を意味しています。

日々結果物が多数の人により更新される制作現場では、こういったバージョン管理が業務で浸透していれば、もしもの場合でも時間をかけずに解決することが可能です。
もはや導入をしないことがあり得ないといったところでしょう。

そして、バージョン管理をサポートしてくれるソフトウェアを、バージョン管理システムと呼びます。

バージョン管理システムの種類

バージョン管理システムは、対象になるファイルのバージョン情報を管理する「場所」によって、ローカル型、集中型、分散型に区分します。
それぞれどんな違いがあるのか、見てみましょう。

ローカル型

バージョン管理の一番基本的な形で、作業者のパソコンのローカルでバージョン区分をする方式。フォルダー名に日付をつけたり、修正中、最終版などの文字列を入れたりするのがローカル型です。

WordやExcelなどのオフィスツールや流行のIDE（統合開発環境）でも、このローカル型バージョン管理システムが導入されており、作業者のミスを予防してくれています。

▲Wordのこの表示、見たことがある方も多いのでは

しかし、ローカル型はバージョン情報が作業者のローカルだけに存在しているので、ひとつのプロジェクトを多人数で制作するのには不向きです。

集中型

集中型は、ローカル型が持っている短所を解決するために考案されました。

▲集中型バージョン管理システムの仕組み
引用元：https://git-scm.com/book/ja/v2/

バージョンを管理するための中央サーバを構築し、そこにひとつのリポジトリを用意して運用する方式です。
各作業者はそれぞれ中央サーバのリポジトリにアクセスして、自分のローカルにバージョンをダウンロード（check out）。作業者のローカルで変更したバージョンをまた中央サーバに送って保存（commit）。お互いの作業が共有できるように構成されています。
つまり、決められた場所で最新のデータを共有しあう形。

この方式は、中央サーバ上で今誰がどんな作業をしているか確認ができるうえ、特定フォルダーに対するアクセスに制限をかけるなどの管理も一括で行えるので、多くの人が共同で作業する環境に適しています。

また、各作業者のローカルはあくまでコピーであり、中央のリポジトリだけを管理すれば良いため、メンテナンス面でも楽ですね。

集中型バージョン管理システムで有名なのは、バージョン管理システムのCVS（1986）や、今も多くの現場で使われているSubversion（1999）があります。

ここまで見ると、集中型を完璧なシステムだと思うかもしれませんが、実は致命的な問題を持っています。
集中型バージョン管理システムには、ネットワークが構築されている中央サーバを常に起動しておく必要があります。
中央サーバに問題が発生した場合、問題解決まで仕事が進まなくなることと、最悪の場合には全てのバージョンやデータを失う危険性も…。（あくまでも最悪の場合ですが）

分散型

分散型バージョン管理システムは、簡単に言うと中央サーバの役割をするサーバが同じ形で色々なところに分散されていて、集中型が持っている短所を補完した形式です。

▲分散型バージョン管理システムの仕組み
引用元：https://git-scm.com/book/ja/v2/

制作時に作業者のローカルにメインリポジトリの一番新しいバージョン情報だけをダウンロードする（checkout）のではなく、全てのバージョン情報を持っているリポジトリ自体をローカルにもってきて（clone）、ひとつの完璧なサーバとして動くようになります。

このようにファイルの場所が分散されているため、メインリポジトリに問題が発生しても作業者には影響がないことと、逆にローカルのリポジトリを使ったメインリポジトリの復元も可能。
必要であればメインリポジトリを経由せず、複数の作業者がお互いにバージョン情報を共有（Push、Pull）することもできます。

とても独立的であり、相互補完的な分散情報管理機能で、分散型バージョン管理システムは全世界の多くの開発者が同時に協業を行うのに最適の作業方式といえるでしょう。

分散型で有名なのはMercurial（2005）とGit（2005）。
ここ数年の主流は分散型のGitです。世界で最もメジャーなソースコードシェアサービスである「Github」では、その名の通りGitが使われています。

R&D事業部でのバージョン管理

R&Dではこれまで、集中型のSubversion、分散型のMercurialなど、メリットとデメリットを実際に体験しながら、バージョン管理ソフトウェアを試してきました。
そんなわたしたちが、バージョン管理システムをどのように利用しているのかを紹介していきたいと思います。

より安全かつ効率的な環境を求めて

いくつかのバージョン管理ソフトウェアを使ってみて、そのどれもが事業部内で使うには最適とはいえず、別のシステムに移行することを検討しはじめました。
自分達の業務にあったバージョン管理システムは無いか調査し、2016年に導入したのがGitです。

1. 主流のシステムである
2. Agileの導入に伴ってブランチ運用が容易である
3. 中間作業物を負担なく保存できる
4. オフライン開発が可能
5. 大規模なプロジェクトでも効果的に取り扱い可能

Gitは、これらの条件に当てはまるR&Dにピッタリのシステムだったのです。
上記以外にも、Gitの長所や機能は沢山あります。
Gitについてもっと知りたい方は、Gitの公式サイトgit-scm.comで、gitの教科書と呼ばれるprogitの日本語翻訳版を公開していますので、目を通してみてください。

R&Dでは、Gitを使用する際は視覚的に操作ができるSourceTreeを利用しています。ただ、時にはエクスプローラーからファイルを探したり、修正履歴を確認したりすることもあるので、TortoiseGitというソフトウェアも並行して利用。
また、Git運用の手法として紹介されているGit-Flowも採用しています。

▲こんな感じで運用してます

またまだGitの使い方を試行錯誤中。
新たに着手するプロジェクトで必ずGitを使用しながら、R&DならではのGitの使い方を定義しているところです。

将来的には
★R&D流のGit運用手法確立
★イシュートラッキングのためのGithubやGitlabの導入
★過去違うバージョン管理システムで開発したソフトウェアをGitへ移行
を目標にしています！

ITの世界は日進月歩。さらなる最適化を目指して頑張ります！

▲「やるぞ～！」

気合いいっぱいのR&Dメンバー、シヨンさん。
開発環境が進化していくのが楽しくてしょうがないですね！

さいごに

今回、ソースコードの管理方法としてバージョン管理システムを紹介しました。
ソースコードは「会社の資産」。わたしたちには、それをうまく管理・運用していくことが求められています。

今回のブログで紹介したもの以外にも、バージョン管理システムは数多く存在します。
機能は少しずつ違いますが、それぞれの良いところ、悪いところがあるため、もし使用を検討している場合には現況に合っているものを選んでみてください。

今まで苦労していた管理が、システムの導入によって様変わりすること間違いなし。
きっとプロジェクト成功に一歩近づくはずです。
そして、R&Dの開発プロジェクトも、バージョン管理システムを活用しながら、どんどん形にしていきます！

以上、R&Dのチャンウクがお送りいたしました。次回もお楽しみに！