エンタープライズ分野での分散バージョン管理システム

原文(投稿日：2012/05/17)へのリンク

ほとんどすべての主要なオープンソースプロジェクトは分散バージョンコントロールシステムを使っている。エンタープライズ分野もこれに続くだろうか。

紹介

バージョンコントロール(ソフトウエア構成管理(SCM)とも言う。両者はまったく同じではないが、とても似ていると言える)の世界は2004年から変わっていない。バージョンコントロールはありふれたものになってしまい、導入することが目的になり、どの製品を導入するかは問われなくなった。

エンタープライズ分野では、バージョン管理機能を搭載したALMパッケージ(アプリケーションライフサイクル管理)がプロジェクトに重要な価値を提供していた。トレンドはマネジメント指向、プロセス駆動、制御中心の発想だった。

しかし、このような状況は完全にひっくり返った。

新しいバージョン管理システムが必要になったリナックスカーネルの開発者達はTorvaldsにソリューションを求めた。そこで生まれたのがGitだ。Gitはハッカー指向のツールで、Linux Kernelのソースの素早い変更と共同的な開発を実現した。

これを機に、バージョン管理はありふれたものではなくて生産性向上のエンジンになった。革命が始まったのだ。

分散とは何か

簡単に言えば、分散バージョン管理システム(DVCS)はプロジェクトのリポジトリを中央リポジトリから各開発者のマシンに移す。

下の図1は従来の"中央リポジトリによるバージョン管理"を示している。リポジトリをホストするひとつの中央サーバがあり、開発者は変更を反映したり、変更を検索したりするためにこのサーバに接続する。各開発者はひとつ以上の"ワーキングコピー"を持つ。

(クリックして拡大)

図1. 中央リポジトリによるバージョン管理

図2は分散バージョン管理の仕組みを表している。各開発者は自身のマシンにリポジトリを持ち、他の開発者へ変更をプッシュしたり、他の開発者の変更を自分のリポジトリに反映したりする。

(クリックして拡大)

図2 分散バージョン管理

"中央リポジトリ"はない。中央サーバもない。各開発者は完全に独立して作業できる。ネットワークの遅延にも制限されない。

なぜ中央サーバがないのか

Linux Kernelの開発者は図1よりも図3に近いかたちで分散バージョンコントロールを利用している。開発者は世界中に散らばっており、異なる企業で開発し、あるいは在宅で開発しながら、インターネットを経由してひとつの同じプロジェクトに貢献している。

(クリックして拡大)

図3 インターネット経由のバージョン管理

2005年当時、インターネットの接続問題やサービスがダウンしたりすることで、で開発者の作業が遅れることは少なくなかった。驚くべきことに、2012年でも状況は同じだ。開発者は待たされるのが嫌いだ。ストレスが溜まり、生産性が低減する。開発が終わる前に巨大なデータを送信するために作業が遅くなってしまうのは開発者の生産性にとって致命的だ。

従って、オープンソースの世界で中央サーバに接続する必要がなくなったのは大きな進展だった。

• 開発者はローカルリポジトリで変更を素早くチェックできる。
• 中央サーバへの依存がなくなった。プロジェクトのコントリビュータのリポジトリにはプロジェクトの"クローン"が含まれている。このリポジトリが完全に壊れることはない。
• 開発者は実験的な開発ができる。変更の影響範囲を自分のリポジトリ内にとどめることができる。開発者がその変更を共有するべきだと感じたときにのみ共有すればいい。それまでの間はローカルのリポジトリで変更を管理すればいい。

ひとつのリポジトリがすべてを制御する

しかし結局のところ、どんなに分散開発をしているオープンソースプロジェクトでも(Linux Kernelでも)なんらかの中心的なリポジトリが必ず存在する。

DVCSの技術を使うことで、開発者はひとつの中心と繋がりながら開発する方式から純粋な"ピアツーピア"方式へ移行できる。しかし、実際には"良いバージョン"として使うために"マスターコピー"が必要だ。.

Linux Kernelの場合、Linus自身がコントリビュータからの変更を受け付けるための"マスターコピー"を管理している。Linusが認めた変更はメインのソースの一部となり、それが開発者用のクローンとなる。図4参照。

(クリックして拡大)

図4. マスタリポジトリを作ってもいい

ワークフローの変化

中央リポジトリが分散化される流れの中で開発者の働き方も大きく変わった。図5参照。

(クリックして拡大)

図5　中央リポジトリと分散リポジトリのワークフロー

中央リポジトリを相手にする場合、典型的な作業は次の通りだ。ます、変更をリポジトリにチェックインして他のユーザが加えた新しい変更を探す。

分散化されたリポジトリの場合、ネットワークを介さないローカルリポジトリ相手なのでチェックインと更新は素早く頻繁に行われる。マスタリポジトリに変更を"提供"するにはプッシュを行う。マスタリポジトリの変更を調べるのはプルと呼ばれる操作だ。

また、チェックインは"同期"処理だが、プッシュとプルはブロックされない処理なので生産性には影響しない。

エンタープライズ分野で利用する場合、何に気をつけるべきか

DVCSの利点は中央サーバを排することでインターネットの潜在的な遅延に影響を受けずに開発ができることだ。では、エンタープライズ分野にはどのような利点がもたらされるだろうか。

ほとんどのエンタープライズ分野の開発者は"私はバージョン管理サーバに1GbpのLANでつないでいるから、接続は高速だし、バージョン管理処理もサーバが強力なので問題ない"と考えるだろう。確かにこの考えは正しい。

しかし、上述したような状況は常に現実と適合するとは限らない。少なくともエンタープライズ分やの開発チームの多くには当てはまらない。なぜなら、

• 地理的に異なる場所で協力して働くという働き方はますます一般的になる。大企業だけでなく、30人程度の開発チームでも異なる都市や国や大陸にいながら一緒に開発することもあり得る。数十年前ならSFの世界だったが、今では現実だ。
• 企業はは人材を見つけるのに苦労している。そして大抵の場合、企業のある場所にいる最良の開発者を雇う。また、自宅勤務も企業が直面している課題のひとつだ。
• 別の場所にいるアウトソースチームには内部のチームの必要な物事を共有しつつ、プロジェクトをしっかり管理するために、リポジトリへのアクセスポリシーを厳格にする必要がある。

このような状況の中でDVCSに何ができるだろうか。図6のように開発チームのメンバーが異なる場所に分散している場合を考えよう。ます、中央バージョン管理サーバがある第1の場所がある。普通は企業がある場所だ。開発者は高速なネットワークでアクセスできるので、この中央リポジトリ相手の作業は問題ない。

次に2番目の場所がある。これは多くの開発者がいる場所で、VPNを使ってインターネット経由で中央バージョン管理サーバがある場所にアクセスする。この第2の場所のローカルネットワークが第1の場所よりも高速だったとしても、開発者はバージョン管理の処理のラウンドトリップに時間がかかるためイライラしてしまう。

さらに、自宅で働く開発者がいる。自宅のネットワーク接続は不安定で信頼できない。

第2の場所と自宅の場合、中央リポジトリに接続することが原因で生産性とモチベーションが下がってしまう。

(クリックして拡大)

図6. 分散しているチームが中央リポジトリを使う。ひとつの場所だけが幸せ

分散バージョン管理を使えば図7のようにすべての人が幸せになれる。この図が示しているのは、各開発者のマシンにひとつのリポジトリを立てるという純粋なDVCSの使い方ではなく、各場所にリポジトリを立てる方法だ。これは分散マルチサイトとして知られている。また、ネットワーク経由でリポジトリにアクセスしなければなない問題は純粋なDVCSの使い方で解決できる。

(クリックして拡大)

図7. マルチサイトを使った分散開発チーム。みんなが幸せ

上述の場合を解決するにはいくつかのやり方がある。

マルチサイトは既に発明されていなかったか

その通り。90年代半ばには、大規模でマルチサイトの開発環境に対処するための予算がたくさんあるエンタープライズ分野の開発では高価なソリューションが使われていた。現在でも使われているが、DVCSにシェアを奪われつつある。その理由は、

• とても高価である
• セットアップやメンテナンスが難しい
• 古い技術を使っており、性能が悪い
• 同時ひとつのサイトだけがブランチを変更できるというマスターシップのような仕組みが"分散"を制約する

DVCSは古いマルチサイトのソリューションのような制約はない。

プロキシサーバはDVCSではない

"良さそうなものがすべて分散化されているのはない"ということを念頭に置くのは重要だ。

DVCSと分散開発はバズワードになっている。開発者のなかで流行っているので、従来の中央管理ソリューションを提供しているベンダは宿題を片付けずに流行に乗ろうとしている。

分散の意味は、ネットワークを切断してもローカルのリポジトリ(あるいはローカルサイトのリポジトリ)を使って作業を続けられるということだということを念頭に置く必要がある。この場合の作業とは、チェックイン、チェックアウト、ブランチ作成、マージなどバージョン管理に関わるすべての処理だ。

"プロキシ"を実装してデータをキャッシュして中央リポジトリにアクセスしなくてすむようにするのは"偽の分散"でありDVCSではない。このやり方はある場面では役に立つかもしれないが、ブランチ作成やチェックインには役に立たない。

ミスリーディングなマーケティングには注意が必要だ。本物のDVCSは2005以降に作られた少数のオープンソースソフトウエアと商用製品だけだ。

DVCSの更なる価値

これまでネットワークトポロジに関連する利点とこの利点が日々のバージョン管理の操作に多くの恩恵をもたらすことを説明した。

しかし、これはDVCSの"D"の部分の利点に過ぎない。

ローカルにリポジトリを持てるということだけで分散バージョン管理システムが次世代のソフトウエア開発の波になるのではない。他にも多くの利点がある。

• DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30分もかかっていた巨大なコードベースのブランチが２秒で済むようになり、マージも信頼できるようになった。

分散バージョン管理の本当の利点はブランチとマージを使って平行開発を推し進めることができる点にある。フィーチャーブランチ、タスクブランチ、リリースブランチというよく知られたブランチの切り方などを使えばとても優れた開発手法になる。この手法は前世代のSCMが適切なブランチやマージができなかったために忘れられていたものだ。

エンタープライズ分野でのDVCS導入の課題

各開発者のマシンにリポジトリを持つ場合、いくつかの疑問が生じる。

• セキュリティ: 開発者一人一人がリポジトリの完全な複製を持ってしまうのはセキュリティ上問題ないのか。
• 監査能力: ソースコードへのアクセスを追跡することはできるか。
• ポリシーの強制: オープンソースプロジェクトのために作られたDVCSはエンタープライズ分野で求められるセキュリティや方法論やコンプライアンス上のポリシーを強制できるか。
• 性能: 新しいDVCSは全世代のバージョン管理よりも高速だと言われているが、30万から150万ファイルを単一のワーキングコピーとして効率的に扱えるか。
• 巨大なファイル: 航空産業やエレクトロニクス産業、ゲーム業界などで使われている巨大なファイルを扱えるか。

これらの疑問は、オープンソースのDVCSをカスタマイズしてLDAPやアクティブディレクトリと統合するようにしたり、アクセス制御リストと連携し、巨大なバイナリファイルや部分複製を扱える新しい商用DVCSを利用することで解決されている。

DVCSの本当の価値を覚えておくのが重要だ。

エンタープライズ向けのDVCSを評価するときに考慮する点は、

結論

エンタープライズ分野へのDVCSの導入は間違いなく進む。早く導入すれば開発手法が最適化できるので競合相手より優位に立てるだろう。

また、DVCSの開発者はエンタープライズ分野のニーズに注力しなければならない。オープンソースプロジェクトのニーズよりも地味なニーズだが、このようなニーズを取り込むことでエンタープライズ分野の開発者のDVCS導入を支援できるだろう。

著者紹介

Pablo Santos氏はCodice Softwareの創業者であり社長。Codice Softwareを設立して2005年にPlastic SCMを発表する前、Pabloは車両制御ソフトウエア開発で研究開発エンジニアとして働き(GMV、スペイン)、その後、デジタルテレビのソフトウエアスタック開発(Sony、ベルギー)に携わりました。その後、プロジェクトマネジメント(GCC、スペイン)に従事してERPパッケージの刷新を推し進めました。その間、PabloはSCMの専門家になりコンサルタントとして働きながらイベントのスピーカーを務めました。2005年、Codice Softwareを創業しエンジニアリングからマーケティング、事業開発、広報や営業を行っています。

Francisco Monteverde氏が同社に参画するとPabloはCEOを辞め、主席エンジニアとしての役割に注力しつつ、引き続き、マーケティングや営業にも携わっています。同社のブログやイベントのスピーカー、技術雑誌への記事執筆を通じて技術の普及を推し進めています。2004年、地域コンピューティングエンジニア協会の副部長に就任し、2008年に部長になりました。また、ブルゴス大学の准教授を務め、若手のエンジニアにアジャイルやソフトウエア構成管理などのプロジェクトマネジメントを教えています。

Pabloは2000年にコンピューティングエンジニアリングの修士を取得(バリャドリッド大学、スペイン)しています。Pabloはソフトウエア開発に強い情熱を持っていますが、コーディングや設計を行っていないときは、バイクでのツーリングを楽しんでいます。