Perforce から Git に 移行する理由

Git はソフトウェア開発者にとって優れた SCM ソリューションです。Git への関心は 2005 年の最初のリリースから着実に高まってきました。今日では、独立系開発者から大規模エンタープライズまで、あらゆる規模のプロのチームに人気があるだけでなく、Android や Linux カーネルなどの重要なオープンソースプロジェクトでも評判です。

Yet Perforce, a commercial centralized SCM system, still resonates with game developers and other subsets of software developers. Why is that? In order to understand this lingering appeal, we’ll have to review some of the reasons why Git surpassed Perforce and other centralized SCM systems for general development, and see why the game development industry has been slower to switch.

Git が世界を席巻した理由

Take a step back to 1995. Your two options for SCM are CVS and ClearCase. CVS is free and, feature-wise, worth every penny. ClearCase is incredibly expensive but powerful: it can handle real merges (up to a 64-way merge!), global development teams, and software projects with multiple modules.

ここで Perforce の登場です。無料ではありませんが、ClearCase よりもはるかに安価です。ClearCase ほど強力ではありませんが、比較的短時間でジョブを完了できます。これこそ商用 SCM 製品が成功するためのコツです。実際、ClearCase が徐々に姿を消し、Subversion が沈滞していき、数年前に Perforce が広く採用される機運が熟したように思われました。

Fast-forward to the present. Git is now the top SCM tool for software developers. What happened?

分散スピード

Git は分散化されます。各開発者はローカル側にコードリポジトリの全履歴を持っています。このため、最初のリポジトリ複製では速度がやや遅くなります (スマートミラーリングを使用している場合を除く) が、その後の commit、blame、diff、merge および log などの操作は格段に速くなります。

Perforce, for the most part, requires a connection to the server in order to even see the history of changes. And that single central server becomes a bottleneck as teams and projects get bigger. Commands like viewing history (p4 changes), creating a tag (p4 label or p4 tag), making a branch (p4 integ), or even making a file writable in your workspace (p4 edit) require write access to the server – which is an obvious bottleneck when thousands of users are accessing that server.

費用

Perforce は価格を公表しなくなりましたが、ユーザー 1人あたりの購入額は数百ドルの範囲で、年次更新にはその金額の何割かの費用がかかることで知られています。大規模なチームの場合、その大規模な中央サーバー用に非常に高価なハードウェアも必要になる可能性があります。

Git 自体はオープンソースであり、完全に無料です。Bitbucket Server には技術サポートとオンプレミスのインストールが付帯しますが、費用は Perforce と比較するとごくわずかです。

50 名の開発者がいるチームを考えてみましょう。Bitbucket の費用は年間 $600 ですが、これに対して Perforce は数万ドルになります。これは、多くの勤勉なハッカーたちに無料のランチをご馳走できるほどの金額です。

ワークフロー

Putting aside all the bells and whistles, fundamentally an SCM tool is about collaboration: letting a team of developers work on a shared set of software files. Git offers simple and computationally inexpensive branching, which opens up the door to a variety of cool workflows. Task branching, Git Flow, forked repositories – there’s a fast and easy workflow for any type of team from open source to professional development, aided by powerful code review and collaboration tools.

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

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

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

Besides being expensive, Perforce branches aren’t conducive to the type of workflow most developers prefer. Perforce branches are shared, so there is no such thing as a private task branch with periodic rebasing. And Perforce’s merge algorithms are overly complicated, with entire articles written about how to merge files that were renamed or had their attributes modified.

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 エクスプローラープラグインはこのようなユーザーから高い評価を得ました。

But thankfully those days are past. GUIs like SourceTree offer a point-and-click experience and there are a multitude of shell integrations for Git. Bitbucket provides code review, merge and pull requests, forking, online code browsing, and a plethora of other collaboration tools. Indeed, everyone from data scientists to creative agencies are organizing communities that make use of the open collaboration that Git and Bitbucket make possible.

ゲーム開発者は特別

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

バイナリファイル

Game developers, particularly artists, need to work with large binary objects like textures and audio assets. Data scientists may have massive data sets comprising billions of event samples.

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

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

  • これらのファイルは、リポジトリのサイズが大きくなるにつれて Git の速度低下を引き起こします。

The repository size problem is largely addressed by Git LFS, an extension that lets Git handle large files while delegating the actual file storage elsewhere.

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

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

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

大規模プロジェクト

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

However, this advantage is largely moot now. Modern Git systems like Bitbucket provide easier management of Git multi-module tools like submodules and subtrees. And more importantly, large projects like Android have shown how to manage a complex project using higher level composition tools. Many of these lessons have been pulled into modern CI/CD tools like Bamboo and Bitbucket Pipelines, which can orchestrate complex continuous integration workflows, model the dependencies between projects, and manage artifacts between projects.

This trend largely follows the Git (and *nix) philosophy of building a tool that does a single job very well. Continuous integration and continuous delivery (CI/CD) is a practice of its own, with tools that are dedicated to understanding build and release workflow. It also aligns with modern software development best practices, which aim to use small self-contained microservices rather than monolithic projects.

次のステップ

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

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

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

Git を学習する準備はできていますか?

この対話式チュートリアルを利用しましょう。

今すぐ始める