Perforce から Git に移行する理由

ワークフロー

付加的な機能はさておき、基本的に SCM はコラボレーションに関するツールです。つまり、開発者のチームが共有のソフトウェア ファイル セットで作業できるようにするものです。Git はシンプルで計算量の少ないブランチングを提供するため、各種の便利なワークフローを利用できます。タスク ブランチング、Git Flow、リポジトリのフォーク – 強力なコード レビューおよびコラボレーション ツールにより、オープン ソースから専門的な開発まで、あらゆるタイプのチーム向けの迅速で簡単なワークフローが用意されています。

Git は企業の境界を越えて容易にコラボレーションすることも可能で、機能横断型開発での共通要件です。Git の共有リポジトリに物理的なネットワークアクセスができなくても、Git patch やバンドルツールを使用してデータ共有を簡単に行えます。

これに対して Perforce では、ファイルごとにブランチ作成レコードを維持します。Git の場合はコミットベースです。これは何を意味するのでしょうか。まず、ブランチを作成するたびに Perforce データベースに非常に多くのメタデータを作成します。これは大規模なデプロイメントでパフォーマンスの問題の原因になり、多くの Perforce 管理者はブランチ作成を制限することになります。

このことについて少し考えみましょう。新しいフィーチャーを試すためにタスク ブランチを作成しようとするたびに、許可を求める必要があります。タスク ブランチを作成できない場合は、不安定なコードをマスター ブランチにチェックインするか、"完成" するまでコミットを待つしかありません。タスク ブランチで CI/CD を行って進行中の未完成作業を詳細に追跡できるというメリットが失われます。最終的には、開発者が生産性の低いワークフローに耐えるか、Git を併用し、Git で行った作業を手動でマージして Perforce に戻すことになり、生産性が低下します。

Perforce ブランチは高価であることに加え、ほとんどの開発者が好むタイプのワークフローには向いていません。Perforce ブランチは共有されるため、定期的にリベースするプライベート タスク ブランチのようなものはありません。また、Perforce のマージ アルゴリズムは非常に複雑で、名前が変更されたファイルや属性が変更されたファイルをマージする方法について書かれた記事が多数存在します。

Perforce サーバー間の共有コードについてはどうでしょうか。共通の履歴がなくても共有 tar ファイルに戻ります。Perforce のデータモデルはソフトウェアの履歴を単一サーバーに対して一意であるとみなしますが、Git ではどこにでも履歴を複製し、共有することができます。

マインドシェアとコミュニティ

商用版の競合相手は別にして、Git が Mercurial などの優れたライバルに勝ったのはなぜでしょうか。もちろん、気運というものがあり、Git は気運に乗っています。Git は、Linux カーネルプロジェクトにおける分散型開発の課題を解決するために Linus Torvalds によって作成され、現在では Linux、Android、OpenStack など、ほとんどの重要なオープンソースプロジェクトの標準 SCM ツールになっています。Git は新しい技術に敏感な人なら誰でも使用しています。マネージャーを雇う予定があるなら、新人のエンジニアは追加研修をしなくても Git を使いこなすことができ、また、Git を使用して作業することを希望すると考えていいでしょう。

もちろん、Git を支える活発なオープンソースコミュニティから得られる利益もすべてあなたのものです。Git は現実の世界の問題を解決するために急速に進化しており、Git LFS などの主要な新機能が続々と登場しています。修正したいバグがあれば、Git プロジェクトに自分自身のコードを提供できます。一企業からロードマップに従って製品化するよう強制されることもなければ、開発ペースを設定されることもありません。利用可能な Git クライアントプログラムの範囲をご覧ください。複数の強力なデスクトップ GUI、Windows エクスプローラとの統合、あらゆる IDE および開発ツールのプラグインがあります。

GUI および開発者ツール

最初の頃、Git は GUI やツールへの対応が不十分でした。これは視覚的なインターフェイスを介して Git リポジトリと対話したいユーザーにとって障害となっていました。ゲームアーティストなどの非技術系のコラボレーターは、特に参加したくても手が出せませんでした。Perforce の Windows エクスプローラープラグインはこのようなユーザーから高い評価を得ました。

しかし、ありがたいことに、それは過去の話です。Sourcetree のような GUI はポイント & クリックのエクスペリエンスを提供し、Git には多数のシェル統合があります。Bitbucket は、コード レビュー、マージおよびプル リクエスト、フォーク、オンライン コード閲覧、その他多数のコラボレーション ツールを提供しています。実際、データ サイエンティストからクリエイティブ エージェンシーまであらゆる人々が、Git と Bitbucket が実現するオープンなコラボレーションを活用するコミュニティを作っています。

ゲーム開発者は特別

ところで、膨大なデータセットを扱うゲーム開発者やリサーチャーのようないくつかのコミュニティが流行に飛びつくことを阻んだものは何でしょうか。つまるところ、それはデータのタイプとプロジェクト組織の複雑さです。

バイナリファイル

ゲーム開発者、特にアーティストは、素材やオーディオ アセットのような大きなバイナリ オブジェクトを扱う必要があります。データ サイエンティストは、数十億ものイベント サンプルで構成される膨大なデータ セットを持っている可能性があります。

これは Git に２つの問題をもたらします。

• これらのファイルはマージできません。集中型のロック機構は便利で、Perforce が提供しています。(ただし、集中型サーバーでもロック機構を提供するのは単一のブランチに対してのみであることに注意してください。したがって、この機能を使用すると、非常に制限されたワークフローを持つことになります。)
• これらのファイルは、リポジトリのサイズが大きくなるにつれて Git の速度低下を引き起こします。

リポジトリ サイズの問題の大部分は Git LFS によって解決されます。Git LFS は、Git が大きなファイルを処理しながら、実際のファイル ストレージを他の場所に委任できるようにする拡張機能です。

ファイルロッキングの問題は、２つの領域で詳細に調べられています。ソフトウェア設定管理の観点から、Git LFS はロードマップでのファイルロッキングにおいて優れています。Git LFS では、作業しているブランチに関係なく、ユーザーが最新のバージョンで作業できるようにアルゴリズムを使用して複数のブランチ間のバイナリファイルのロッキングを調整します。これにより、大規模なバイナリファイルで作業しているユーザーはワークフローを分岐することができます。ここが単一ブランチのロッキングモデルを採用している Perforce と異なる点です。

調整の問題としてファイのロックを考えることも有効です。マージできない共有資産で作業を開始しようとしている場合、すべての利害関係者にどのようにしてその知識を広めればいいでしょうか。ここでも、プルリクエストやリアルタイムのチームコラボレーションを使用する最新のワークフローが本領を発揮します。Hipchat を使用して自分の意図を素早く伝えたり、特定のファイルで進行が遅れている作業があるかどうかを確認したりできます。

ビッグデータの時代において大容量ファイルを扱う問題がどのように展開していくのか考えてみるのも面白いでしょう。Big Data 分析のジョブをテストするためには、数テラバイトのサイズのデータセットが必要になるかもしれません。SCM システムのことは忘れてください。このプロジェクトはビッグデータに対応したファイルシステムでテストされ、実行されます。ここで必要なのは、より複雑なパイプラインと HDFS または S3 に存在する成果物を編成できる CI/CD システムです。これが次のトピックです。

大規模プロジェクト

ゲーム開発は、ゲームエンジン、UI、スタティックアート、ビデオレンダリングなど、複数のモジュールやコンポーネントがあるソフトウェアプロジェクトの典型例です。一体型集中リポジトリとしての Perforce は、これらのモジュールをすべて単一のサーバーでホストすることが可能で、ユーザーは自分の作業領域に取り込むパーツを選択できます。

しかし、この利点は現在ほとんど価値がありません。Bitbucket のような最新の Git システムを使用すれば、サブモジュールやサブツリーなどの Git マルチ モジュール ツールをもっと簡単に管理できます。さらに重要なのは、Android のような大規模なプロジェクトでは、より高度な構成ツールを使用して複雑なプロジェクトを管理する方法が示されていることです。これらの教訓の多くは、Bamboo や Bitbucket Pipelines などの最新の CI/CD ツールに取り入れられており、複雑な継続的インテグレーション ワークフローのオーケストレーション、プロジェクト間の依存関係のモデル化、およびプロジェクト間のアーティファクトの管理を行うことができます。

この傾向は、1 つのジョブを非常にうまく遂行するツールを構築するという Git (および*nix) の理念に大きく従っています。継続的インテグレーションと継続的なデリバリー (CI/CD) はそれ自体がプラクティスであり、ビルドとリリースのワークフローを理解するためのツールを提供しています。また、モノリシック プロジェクトではなく、小さな自己完結型のマイクロサービスの使用を目指す最新のソフトウェア開発のベスト プラクティスにも適合しています。

次のステップ

Perforce から Git への移行には、明確に気運のようなものがあります。また、Git と最新の CI/CD ツールは最大規模の、最も複雑な開発努力に対応できる態勢にあります。実際、Perforce は Git Fusion というツールさえ作成しました。これは、Perforce の中央リポジトリを部分的に Git リポジトリとして取り出すことができます。

Git Fusion は集中 SCM システム上に Git を重ねようという崇高な試みでしたが、残念ながらまったく容易なことではありません。使用モデルを混合しようとすると、一つのシステムのデータービューが非常に簡単に壊れる可能性があります。使用モデルを混合しない場合、商用の集中バックエンドを Git の背後に配置する価値があまりありません。このようなトレンドは、実は逆方向に向かっています。役立っていた集中化 SCM の最後のいくつかの残りの部分をどのように Git に配置すればいいでしょうか。

ソフトウェアやゲームの開発に Perforce を使用している場合、Git への移行方法について悩んでいるのではないでしょうか。どうやって移行するのか? 費用をかけて切り替える価値はあるのか? 次の記事では、まさにそのことについて説明します。