要約
- Perforce は、大規模なソース、ゲームアセット、ハードウェア設計の変更を信頼できる受け入れ済み状態に導く能力によって評価されるべきであり、単にリポジトリの規模を示す大まかな主張によってではない。
- P4 が最も強みを発揮するのは、バイナリアセット、排他ロック、チェンジリスト、ストリーム、レビュー、アクセス権、ビルド統合、リカバリーの規律が日々の調整コストを下げるチームである。
- 商業的なリスクは、Perforce が Git のマージの苦痛を、ライセンス費用、専門管理者、移行の摩擦、ストレージ計画、ロックインに置き換え得る点にあり、購入者は運用負担全体を測定しない限り、それに気づかない。
- 公開ドキュメントと顧客事例は受け入れ済み変更のテーゼを裏付けるが、本記事のために実際のリポジトリテストは行われておらず、性能、サポート、購入者固有の経済性は条件付きである。
受け入れられた変更こそが問題の単位である
Perforce に関する実際的な問いは、リポジトリが大量のコンテンツを保持できるかどうかではない。リポジトリは巨大でありながら、ひどく運営され得る。ゲームデポはテラバイト規模のアートを抱えつつ、アーティストをロック待ちにし、デザイナーにはどのマップリビジョンが最新か不明にし、プログラマーは古い統合ブランチと闘い、ビルドチームはサブミット前に拒否されるべきだった作業を再ビルドし得る。半導体リポジトリは数百万のファイルを含みながら、IP ブロックやシミュレーションアーティファクト、制約ファイルがレビュー可能な来歴なしに移動した瞬間に機能不全に陥り得る。難しい問いはより狭い：チームは提案された変更を、他者が信頼できる形で受け入れ済みにできるか？
その受け入れ済み状態にはいくつかの部分がある。変更されたファイルは、正しいファイルタイプ、適切なアクセス制御の下で、正しいファイルでなければならない。変更は、無関係な編集の山に消えるのではなく、意味のある説明、レビュー、課題、ビルド結果に紐付いていなければならない。バイナリファイルは、マージ不可能な並行編集によって黙って上書きされてはならない。大規模なワークスペース同期は、貢献者が最新状態を取得するのを怖がらない程度に予測可能でなければならない。ブランチやストリームのルールは、人々が変更の所属先を知ることができる程度に明確でなければならない。もし変更が間違っていた場合、チームはそれを見つけ、元に戻し、以前の状態を復元し、あるいは復元が危険な理由を説明できなければならない。
Perforce の P4 製品ファミリーは、この種の状態管理を中心に構築されている。サーバーはファイルとメタデータの中央記録を保持する。チェンジリストは作業のトランザクション的な単位を提供する。ファイルロックは、他のユーザーが選択したファイルに対して競合する変更をサブミットするのを防ぐことができる。ストリームはチームに制御されたブランチモデルを提供する。P4V は非コマンドラインユーザーに視覚的クライアントを提供する。P4 Code Review（旧 Helix Swarm）は、レビューを P4 チェンジリストに結びつける。P4 DAM はアーティストや他のコンテンツユーザーに、資産を見つけ、レビューし、再利用するためのウェブ向け手段を提供する。これらの製品の目的は、単にデポを満杯にすることではない。目的は、次の受け入れ済み変更をより曖昧さの少ないものにすることである。
これが、Git が支配するソフトウェア世界においても Perforce が商業的に関連性を保つ理由である。Git は多くのコード中心のチームにとって優れている。分散ブランチ、安価なローカルコミット、大規模なエコシステムサポート、クラウドコラボレーションが、現代の開発におけるデフォルトの出発点となっている。しかし、Git の強みは、プロジェクトがマージ不可能なバイナリ、大規模な生成アセット、高度な監査要件、中央集権的なビルド依存関係で満たされている場合、運用コストに転じ得る。Git Large File Storage、Git ホスティングの制御、アーティファクトストア、デジタルアセットシステムはその問題の一部に対処できる。しかし、それらは必ずしも、アーティスト、エンジニア、ビルドマネージャー、コンプライアンスレビュアーが同じように体験する一つの受け入れ済み状態を作り出すわけではない。
したがって、本記事は Perforce を、受け入れ済みリポジトリ変更のための制御システムとして扱う。リポジトリの規模は重要だが、それはその制御システムにかかる負荷としてのみ重要である。購入者は「Perforce は我々のファイルを保存できるか？」と問うべきではない。「Perforce は、コード、クラウドストレージ、ファイル共有、アセットデータベース、ビルドスクリプトの現在の組み合わせよりも、次の受け入れ済み変更を安く、明確に、安全に、そして回復可能にできるか？」と問うべきである。
中央集権的状態は、チームが共有の真実を必要とする場合にのみ利点となる
P4 の中央集権的設計はしばしば Git の分散モデルとの対比で提示される。その対比は現実だが、自動的に良いか悪いかではない。中央集権的状態は、不一致のコストが高い場合に価値がある。大規模スタジオは、2 人の環境アーティストが重いシーンアセットの互換性のないバージョンを無意識にコミットすることを望まない。ハードウェア設計チームは、ある技術者が関連設計ファイルの古いビューを使用している間に、他のグループが既に管理リビジョンを移動させていることを望まない。規制対象のソフトウェアチームは、出荷されたコードと部分的にしか一致しないローカル履歴、文書化されていないアーティファクト共有、課題コメントにリリース証拠が散在することを望まない。
このような状況では、中央集権的状態は不確実性を減らすことができる。サーバーは、どのリビジョンがヘッドか、どのファイルがオープンされているか、どのロックがアクティブか、どのチェンジリストがサブミットされたか、どのユーザーとワークスペースがそれをサブミットしたか、どのストリームに影響したか、どのパーミッションが適用されたかを知っている。それ自体がプロセスを良くするわけではない。中央サーバーはボトルネックになり得る。誤設定され得る。故障し得る。遅い経路に過剰なトラフィックを強制し得る。しかしチームが「今、何が受け入れられているのか？」という共有の答えを必要とする場合、中央集権化は Perforce にレビュー、ビルド、パーミッション、ロック、リカバリーを取り付ける自然な場所を与える。
受け入れ済み変更のレンズは、Perforce が純粋なコード作業以外でしばしば強みを発揮する理由も説明する。ソースファイルはテキスト形式が構造を露出するため、通常はマージできる。バイナリファイルは通常できない。ツールがバイナリまたは半バイナリ形式の差分を生成できる場合でも、マージは意味的に安全でない可能性がある。テクスチャ、レベル、CAD エクスポート、シミュレーション結果、コンパイル済みアセットは、全体としてのみ意味を持つかもしれない。そのようなファイルにとって、ロックは現代的なコラボレーションの失敗ではない。それは並行編集が作業を無駄にするというシグナルである。
P4 のマーケティングは、ソースコード、3D アセット、スケール、ファイルロック、ストリーム、プロキシおよびエッジサーバー、監査ログ、統合、そしてゲーム、半導体、自動車業界での利用について多くを語る。その物語の信頼できるバージョンは、すべてのチームがすべてを中央集権化すべきだということではない。すでに中央集権的な真実を必要としているかのように振る舞いながら、それを複数のシステムから不器用に組み立てているチームがあるということである。コードは Git に、アートはクラウドドライブに、ビルド出力は別の場所に、設計パケットは共有フォルダに、リリース証拠はチケットに保管している。そうすると、受け入れ時に統合税が現れる。ビルド内のアセットがレビュー済みアセットと一致するか、アーティファクトストアのバイナリが更新前にロックされていたか、課題が正しいリビジョンでクローズされたか、ロールバックが変更を元に戻すことなのか、フォルダを復元することなのか、記憶から環境を再構築することなのか、誰も確信を持てない。
Perforce がその地位を得るのは、中央集権的状態が単なる好みではなく制御面である場合である。共有デポがコード、コンテンツ、および関連メタデータの真実の源であれば、チームは変更に一貫した受け入れ儀式を付加できる。チームが主にテキストコードを編集し、小さなリポジトリを持ち、クラウドネイティブの Git コントロールに依存し、ソースからクリーンにアーティファクトを再ビルドできる場合、中央集権化は価値よりも重みを加えるかもしれない。決定は、中央集権的か分散バージョン管理かという一般的な好みではなく、不一致のコストから始めるべきである。
チェンジリストは受け入れを明示するが、品質を保証しない
チェンジリストは Perforce の最も重要なアイデアの一つである。なぜなら、提案された変更を名前付きパッケージに変えるからである。Perforce のドキュメントは、サブミット済みおよび保留中のチェンジリストをバージョン管理された作業の単位として説明している。チェンジリストにはファイル、説明、ジョブ、メタデータを含めることができる。サブミット操作はアトミックであると説明されている：チェンジリストにリストされたすべてのファイルがデポに保存されるか、いずれも保存されない。これは受け入れが哲学的な状態ではないため重要である。クライアントワークスペースの作業から保存されたリポジトリ履歴への遷移である。
アトミック性は、変更が一緒に移動する必要があるために有用である。コード修正にはビルドスクリプトの調整とテストデータの更新が必要かもしれない。ゲームアセットの変更にはテクスチャ、マテリアル、シーンファイル、メタデータファイルが必要かもしれない。ハードウェア設計の変更には関連する設計ファイルと制約が必要かもしれない。これらの断片が別々に受け入れ済み状態に入ると、下流ユーザーは一時的に不整合なプロジェクトを見る可能性がある。一緒に入れば、レビューとリカバリーは一貫した単位に結びつけられる。
しかし、チェンジリストは品質保証ではない。大きすぎることがある。無関係な編集を混在させ得る。曖昧な説明を付与され得る。弱いレビューを通過し得る。後の統合を高コストにするストリームに対してサブミットされ得る。パイプラインで再ビルドされるべきで、バージョン管理されるべきでない生成ファイルを含み得る。技術的にはサブミット可能でありながら、運用上の悪い決定であり得る。Perforce はパッケージの定義を助けるが、良いパッケージがどのようなものかを定義するのは購入者である。
したがって、受け入れ済み変更のテストはチェンジリストの規律を調べるべきである。チームはレビュー可能なほど小さくチェンジリストを保っているか？バイナリアセットはそれらを意味あるものにするメタデータとグループ化されているか？課題参照は重要な箇所で必須か？ビルドとレビューのチェックは、損害がデポに入った後ではなく、受け入れ前に付加されているか？緊急サブミットは通常の計画作業と区別されているか？機密ファイルに限定的な可視性が必要な場合、制限付きチェンジリストが使用されているか？レビュアーは大規模なアーカイブをダウンロードせずに影響を理解するのに十分な情報を見ることができるか？
P4 Code Review は、レビュービューをチェンジリストとファイルに結びつけることでこのモデルを強化する。そのドキュメントは、テキストベースおよび画像ファイルの変更ファイル、メタデータ、コメント、レビュー状態、差分を表示できることを示している。また、重要な制限も明らかにしている：大規模なチェンジリストはレビュー表示に負荷をかけ、最近のドキュメントはメモリとブラウザの問題を防ぐためのデフォルトのチェンジリストファイル制限を説明している。これは有用な警告である。ツールはレビューをチェンジリストに結びつけられるが、チームが大規模なアセットのダンプを 5 ファイルのコード変更と同じようにレビュー可能として扱うなら、受け入れ済み状態は名目的であり、意味のあるものではなくなる。
商業的な含意は単純である。Perforce は受け入れを明示的にできる。受け入れが賢明かどうかを自ら決定することはできない。購入者は製品だけでなく、チェンジリストのサイズ、説明、レビュー範囲、ビルドゲーティング、ファイルタイプポリシー、例外処理に関するルールにも予算を計上すべきである。それらのルールが不在なら、Perforce は悪い決定を優れた忠実度で記録し得る。
バイナリアセットはロックを調整ポリシーに変える
ファイルロックは旧式と揶揄されやすい。現代のソフトウェアチームは並行作業、プルリクエスト、マージコンフリクト解決に慣れている。テキストソースコードにとって、その文化はしばしば正しい。開発者は別々のブランチで作業し、マージし、レビューし、コンフリクトを解決できる。時折のコンフリクトの社会的コストは、独立して作業する自由によって上回られる。
バイナリアセットは計算を変える。2 人が同じ大きなテクスチャ、モデル、レベル、ビデオ、ハードウェアアーティファクト、アプリケーションパッケージを編集した場合、負けた編集はマージできないかもしれない。コンフリクトは通常のテキストハンクではない。それは繰り返しの作業、不確かな視覚的回帰、破損した依存関係、またはチームが誰の時間を捨てるかを決める人間の調停プロセスを意味し得る。その文脈では、ロックは単なる技術的特徴ではない。それは調整ポリシーである：この種のファイルの編集に時間を費やす前に、それをサブミットする権利を予約するか、少なくともあなたの作業を他者に見えるようにする。
P4 はこのポリシーを複数の層でサポートする。コマンドリファレンスは、ロックしたユーザーがサブミットした時に他者がそれらのファイルに変更をサブミットできないように、開いたファイルをロックすること、およびロックを解除することを説明している。P4V はチェックアウト後のオプションのロックアクションを視覚クライアントユーザーに与える。P4 製品資料は、衝突を防ぐ方法として排他的ファイルロックを強調している。Perforce 自身の顧客事例は、ゲームやメディアの文脈でこの点に繰り返し立ち返っており、大規模なバイナリファイルとデザインアセットが日々の調整リスクを生み出している。
Git にはこの問題への応答がある。Git LFS は大きなファイルをポインタに置き換え、コンテンツを別に保存する。Git ホスティングプロバイダーは LFS プラン、ファイルサイズ制限、ストレージと帯域幅の課金を提供する。GitLab はバイナリファイルに対して特に価値があるとしてファイルロックを文書化しており、Git LFS プロジェクトはマージ不可能な状況につながる並行編集を抑制する方法としてロックを長らく認識してきた。これらは現実の代替策である。購入者は「Perforce」と「混沌」だけが選択肢であるふりをすべきではない。
比較は完全性と運用上の適合性についてである。Git LFS は Git 中心のワークフローを維持するが、ポインタ管理、LFS サーバー依存、プラン制限、移行手順、そしてしばしば別個のロック慣行を追加する。GitHub のドキュメントはまた、通常のリポジトリのファイルおよびサイズ制限が依然として計画上の考慮事項であり、LFS にはプランベースのファイル制限と課金動作があることを明らかにしている。多くのチームにとって、それは受け入れ可能である。一部のチーム、特にアート、コード、ツール、ビルド出力が単一の運用面を共有しなければならないチームにとっては、そのアドオン感が高コストになる。どのファイルが Git にあり、どれが LFS にあり、どれがアセットマネージャーにあり、どれがリリースアーティファクトストアにあり、どのシステムがロックに対して権威を持つのかを知らなければならない。
Perforce の利点は、ロックがチェンジリスト、パーミッション、ストリーム、レビュー、リカバリーと同じリポジトリ状態の内側に置けることである。欠点は、ロック競合が可視化され、時に痛みを伴うことである。重要なレベルファイルが別のタイムゾーンの誰かによってロックされている場合、チームは停滞し得る。ロックが忘れられた場合、管理者が解除しなければならない。ファイルタイプが誤って非排他的に設定された場合、並行編集が再発し得る。排他ロックがコミットエッジインフラストラクチャを経由しなければならない場合、Perforce 自身のドキュメントは、グローバル排他ロックがコミットサーバーとの通信を必要とし、レイテンシを招く可能性があると警告している。ロックは一種の調整作業を取り除くが、別の種類の調整作業を生み出す。購入者の仕事は、どちらが安価かを判断することである。
ファイルタイプとストレージポリシーが大規模ファイルの管理可能性を決める
大規模ファイル対応は、しばしば一つの機能であるかのように議論される。実際には、それはポリシーの集合である。システムはバイナリファイルを正しく識別し、コストを意識した方法でリビジョンを保存し、適切な速度で正しいファイルを転送し、ワークスペースの状態を理解可能に保ち、高価なコンテンツを偶発的な露出から保護し、ファイルが破損したり誤って受け入れられた場合の回復を許さなければならない。
Perforce はそのポリシーの一部をファイルタイプとタイプマップを通じて露出する。コマンドリファレンスは、新しく追加されたファイルがタイプマップテーブルに対して検査され、マッピングがない場合はバイナリ検出によって行われることを説明している。また、バイナリリビジョンは一般に圧縮付きで全体が保存されるのに対し、テキストは異なる保存動作を持つことも説明している。タイプマップコマンドは、管理者がファイルタイプをデポファイルパターンに結びつけることを可能にし、ファイルが追加時に意図されたタイプを割り当てられるようにする。これは低レベルに聞こえるが、受け入れ済みリポジトリ状態の中心である。ゲームスタジオがロック可能なバイナリファイルを追加時に適切に分類し損ねた場合、下流のロック、ストレージ、転送の前提はレビューが始まる前から誤っている。
同じ問題が生成ファイルや派生ファイルにも現れる。一部のアセットはソースアセットであり、バージョン管理されるべきである。一部はビルド出力であり、再生成されるべきである。一部は再ビルドが非現実的であるため保持しなければならない高価なアーティファクトである。一部はデポではなくパッケージレジストリやオブジェクトストアに属する。Perforce は多くの種類のコンテンツを保持できるが、「保持できる」は「保持すべき」と同じではない。あらゆる一時キャッシュ、中間レンダリング、ローカルビルド生成物、ダウンロードした依存関係を P4 に移動する購入者は、リポジトリをゴミ捨て場に変えかねない。受け入れ済み変更のレンズは、そのファイルが永続的なプロジェクト状態として受け入れられる必要があるかどうかを問う。
ストレージの経済性は、Perforce が Git だけでなく、クラウドオブジェクトストレージ、アーティファクトリポジトリ、デジタルアセット管理システムと競合するために重要である。クラウドバケットは大規模な不変アーカイブにとって安価かもしれない。パッケージレジストリはバージョン管理されたビルド生成物により適しているかもしれない。特化したアセットシステムは創造的なユーザーによる発見と承認により適しているかもしれない。P4 DAM はこの問題の一部に対する Perforce の答えである：それは P4 上に構築されたウェブベースのアセット層を追加し、貢献者がバージョン管理バックエンドを開発者専用ツールとして扱うことなく、資産を見つけ、レビューし、再利用し、共有できるようにする。これはクリエイティブチームにとって Perforce を強化するが、アセットモデルを設計する必要性も強化する。バックエンドリポジトリだけでは、視覚ライブラリが有用にはならない。
したがって、大規模バイナリの取り扱いには事前の受け入れ分類が必要である。どの拡張子がデフォルトで排他ロックか？どのファイルがテキスト、バイナリ、圧縮、生成、ベンダー供給、リリースクリティカルか？どのコンテンツが P4 に保存され、どれが参照され、どれが再生成されるべきか？どのファイルが請負業者、パートナー、アーティスト、エンジニア、ビルドシステムに見えるべきか？どのファイルがあまりに大きいため、レビューは生のダウンロードではなくサムネイル、メタデータ、ツール固有のプレビューを使用しなければならないか？これらの決定は魅力的ではないが、Perforce が摩擦を減らすか増やすかを決定する。
最も強い購入者は、ファイルタイプとストレージポリシーをリポジトリのハウスキーピングではなく、製品エンジニアリングとして扱う。移行前にルールを書き、代表的なアセットでテストし、例外を見えるようにする。弱い購入者はデポが既に汚染されるまで待ち、クリーンアップのコストが計画のコストよりも高かったことに気づく。
ストリームとレビューが、制御をスケールで使えるものにするか決める
バージョン管理は、人々が変更の所属先に答えられない時にスケールで失敗する。機能ブランチ、リリースブランチ、エンジンブランチ、コンテンツブランチ、ハードウェア設計ラインはすべて正当であり得る。問題はブランチの存在ではなく、共有された意味の喪失である。Perforce Streams は、ブランチとコードライン管理に構造を与えるために設計されている。製品資料はストリームを、基本的なブランチングを超えて反復可能なフレームワークを設定する方法として提示している。コマンドリファレンスはまた、ストリーム仕様が通常の変更プロセスを通じて編集・サブミットできることを示している。
これは受け入れ済み状態が一次元的でないために重要である。変更は開発ストリームには受け入れられても、リリースストリームには受け入れられないかもしれない。プラットフォームブランチには受け入れられても、ゲームブランチには受け入れられないかもしれない。ある車両プログラムには受け入れられても、別のものには受け入れられないかもしれない。ハードウェア設計のサンドボックスには受け入れられても、再利用可能な IP ベースラインには受け入れられないかもしれない。ストリームの規律なしに Perforce を採用する購入者は、結局、新しいシステムの中で混乱したブランチマップを抱えることになるかもしれない。
有用な問いは、ストリームが認知負荷を減らすかどうかである。新しい貢献者はどこから同期すべきか知っているか？ビルドランナーは、ナイトリー、マイルストーン、リリース候補にどのストリームが対応するか知っているか？統合担当者は変更がどの方向に流れるべきか知っているか？緊急修正は、無関係な作業を同じ経路に強制することなく追跡可能か？アーティストやデザイナーは、すべてのブランチルールを理解することなく同じプロジェクト構造で操作できるか？顧客や規制当局は、どの受け入れ済み変更がリリースに到達し、どれが開発中に留まったかを見ることができるか？
P4 Code Review は別の層を追加する。それはチェンジリストをレビュー可能なオブジェクトに変え、ファイル、メタデータ、コメント、レビュー状態を表示できる。これは重要である。レビューは技術的能力が運用上の信頼性になる場所だからである。ファイルはアトミックにサブミットでき、なお有害であり得る。レビューは、その変更が受け入れに値するかどうかを決定する人間および自動化されたフィルターである。レビューシステムは、レビュアーが実際のバイナリ状態が他の場所にある間に切り離されたパッチを判断していないように、リポジトリ状態に十分近くなければならない。
しかし、レビューには限界もある。P4 Code Review のファイル制限ドキュメントは、ツールにスケーリング境界があることを示す異常に有益なリマインダーである。何千ものファイルを含む変更は、レビューインターフェースを遅くしたり壊したりし得る。バイナリ大量の変更には、視覚プレビュー、ドメイン固有の差分ツール、またはネイティブアプリケーションでアセットを開けるレビュアーが必要かもしれない。ハードウェア設計の変更にはシミュレーションの証拠が必要かもしれない。セキュリティ上重要な変更には制限された可視性が必要かもしれない。Perforce は変更とフックを提供できるが、チームは作業の種類ごとにレビューが何を意味するかを定義しなければならない。
受け入れ済み変更のテストには、レビューのリハーサルを含めるべきである。代表的な変更を取り上げてみよう：コード編集とバイナリアセット、レベル修正、シェーダーパッケージ、ボードサポートファイル、自動車ソフトウェアキャリブレーション、または半導体設計更新。意図されたストリーム、ロック、レビュー、ビルド経路に通す。レビュアーが実際に何を見るか観察する。どれだけ待つか観察する。ラッパーファイルだけでなく、意味のあるアーティファクトにコメントできるか観察する。変更がクリーンに拒否できるか観察する。スケールするが意味のあるレビューをサポートできないリポジトリは、安全な受け入れシステムではない。
統合と自動化は、Perforce が毎日の信頼を勝ち取るか失うかの場である
リポジトリの受け入れはサブミットで終わらない。受け入れ済み変更は、ビルド、テスト、パッケージング、シミュレーション、デプロイメント、リリース、またはアーカイブプロセスによって消費されなければならない。Perforce の顧客事例はしばしばこの中間層を指摘する。Warhorse Studios は、P4 が TeamCity ビルドサーバーに供給し、グラフィックス準備の自動化に P4Python を使用していると述べた。Game Studio の事例は、Azure への移行と、ID およびクラウドインフラストラクチャとの統合を説明した。ECI Telecom は、複雑な開発環境におけるトレーサビリティ、監査証跡、ワークスペース管理を強調した。これらの事例はベンダー公開のものであり、独立したベンチマークとして扱うべきではないが、Perforce が位置づけられるべきタスクの種類を示している：単なるストレージではなく、反復的な運用上の受け入れである。
これは実装リスクが集中する場所でもある。ビルドシステムは正しいストリームとリビジョンを同期しなければならない。自動チェックは、近似的なものではなく、実際のチェンジリストまたはサブミット状態に対して実行されなければならない。レビューシステムは、変更が保留中か、シェルブされているか、昇格済みか、コミット済みかを知らなければならない。ID システムは、人とサービスアカウントをクリーンにマッピングしなければならない。パーミッションは、すべてのビルドプロセスをスーパーユーザーに変えることなく、自動化が必要なものを読み取ることを許可しなければならない。トリガーは、サーバーを停止させたり、脆弱なスクリプトの背後に失敗を隠したりすることなく、ポリシーを強制しなければならない。
Perforce はこれに対するメカニズムを提供する。サーバー管理ドキュメントは、サブミッションイベント前後に実行できるトリガーを説明しており、ファイル転送前の変更サブミットトリガーや、データベースへの成功したコミッション後の変更コミットトリガーを含む。また、トリガースクリプト内からデポにデータを書き込むコマンドが危険であり、再帰とロックを注意深く処理しなければならないと警告している。その警告は脚注ではない。それは主要な自動化リスクを捉えている：Perforce が受け入れ制御点になればなるほど、すべてのポリシーをサブミットに吊るす誘惑が増す。設計が不十分な自動化は、受け入れ済み変更システムを遅くて脆弱な官僚機構に変え得る。
良い自動化は選択的である。受け入れ前に真でなければならない条件をチェックする。証拠が必要な場所に証拠を記録する。拒否が安価な早期に変更を拒否する。別のビルドパイプラインがより安全に処理できる場合、リポジトリトランザクション内で重い作業を再実行することを避ける。貢献者に理解可能な失敗メッセージを与える。緊急用のバイパス経路を持ち、そのバイパス自体が監査可能である。
購入者はこれらの統合の保守コストを計上すべきである。P4 は一般的なツールと接続でき、API、クライアント、統合を備えている。しかし、エンタープライズグレードのリポジトリは移行後にプラグアンドプレイになることは稀である。誰かがタイプマップ、ストリーム、デポ、パーミッション、トリガー、ビルド認証情報、バックアップ検証、アーカイブ増加、プロキシやエッジトポロジー、クライアント設定、ユーザートレーニング、サポートエスカレーションを所有しなければならない。チームが調整作業を取り除くために Perforce を購入しながら、リポジトリ運用への資金提供を拒否するなら、調整作業は遅延と混乱として戻ってくる。
したがって、Perforce の最も強いケースは「すべてを自動化できる」ではない。「受け入れルールを明示的にし、反復可能に実行し、エンジニアリング運用の一部として維持できる」である。その区別は重要である。所有権のない自動化は失敗の別の源泉である。
グローバルチームには、単なる中央サーバーではなく、トポロジーとリカバリーが必要である
Perforce はグローバルに分散したチームとしばしば関連付けられる。P4 製品資料はプロキシとエッジサーバーを強調し、管理ドキュメントは、大規模またはグローバル分散チームのパフォーマンスとスケーラビリティを向上させるための分散サーバーモデルとしてコミットエッジアーキテクチャを説明している。これは重要な能力だが、中央集権的状態が物理的に単純でないことのリマインダーでもある。グローバルチームは依然としてレイテンシ、転送コスト、ロック調整、アーカイブ配置、バックアップ責任を負う。
受け入れ済み変更の問いは、分散トポロジーではより複雑になる。モントリオールのアーティストがファイルをロックした場合、東京のデザイナーは十分に早くロックを見ることができるか？エンジニアがエッジサーバーからサブミットした場合、アーカイブはいつコミットサーバーや他のユーザーに利用可能になるか？レビューがシェルブされたチェンジリストに依存する場合、それはレビューツールが見ることができるコミットサーバーに昇格されているか？エッジサーバーが固有のワークスペースと進行中作業データを持つ場合、必要に応じて別にバックアップされているか？Perforce のドキュメントは、排他ロックがグローバルであり、コミットサーバーとの通信を必要とし得ることを含め、これらの問題のいくつかを直接指摘している。
これは Perforce のケースを損なうものではない。それはケースをより運用志向にする。大規模ファイルチームは、単一の中央点がサーバーから遠い貢献者や重いコンテンツを移動するビルドプロセスにとって遅すぎる可能性があるからこそ、しばしば分散インフラストラクチャを必要とする。プロキシ、レプリカ、エッジサーバー、バックグラウンドアーカイブ転送はユーザー体験を改善できる。しかし、トポロジーは魔法ではない。キャパシティプランニング、ネットワーク設計、サービスユーザー、外部アドレス、バックアップ手順、運用監視が必要である。
リカバリーも同様に中心的である。Perforce のバックアップドキュメントは、バージョン管理されたファイルとデータベースメタデータを区別し、チェックポイント、ジャーナルローテーション、検証手順を強調している。これは一般的なディザスターリカバリーの文言ではない。P4 では、受け入れ済み状態はファイルアーカイブとメタデータの両方に存在する：ユーザー、保護、グループ、ストリーム、チェンジリスト、オープンファイル、ブランチマッピング、ラベルなど。メタデータが失われたり不整合になったりすると、リポジトリは信頼できる受け入れ済み状態の履歴なしにコンテンツを持つかもしれない。アーカイブが欠落または破損している場合、メタデータだけでは不十分である。来歴のために Perforce を採用する購入者は、リカバリーを製品の一部として扱わなければならない。後付けではない。
顧客事例はこれを様々な方法で強化している。Warhorse は P4 環境周辺で夜間チェックポイントとクラウドバックアップを説明した。Tarsier のベンダー公開事例は、ハードドライブの問題からのデータ破損後のバックアップとリカバリーの価値を説明した。Transurban の事例は、ロールバックとユーザーエラーに対する防御の一部としてチェックポイント作成とジャーナルを説明した。これらの報告は、すべての Perforce 展開が回復力を持つことの独立した証明ではない。しかし、真剣な Perforce ユーザーがしばしばバックアップ、ロールバック、リカバリーを第一級の利点として議論することになるのを示している。
購入者にとって、テストは実用的であるべきだ。バックアップからテスト環境に復元する。代表的な受け入れ済み変更が、バイナリファイルとメタデータを含めて回復できることを検証する。失敗したサブミットをテストする。孤立したロックをテストする。誤ったパーミッション変更をテストする。ストリームのミスをテストする。悪いチェンジリストからのロールバックをテストする。リポジトリはベンダーページがスケールすると言っているから信頼できるのではない。購入者が通常の故障をリハーサルし、英雄的な記憶なしに回復できる時に信頼できるのである。
Git の代替は現実であり、Perforce は総運用コストで勝たなければならない
Perforce は藁人形の Git と競合するのではない。成熟したエコシステムと競合する：GitHub、GitLab、Bitbucket、Git LFS、ブランチ保護、プルリクエスト、コードオーナー、アーティファクトレジストリ、リリース資産、クラウドストレージ、パッケージマネージャー、ゲームエンジン統合、サードパーティのアセット管理ツール。多くのチームにとって、そのエコシステムは安価で、馴染みがあり、人員配置が容易である。Perforce はその代替全体に対して自らを正当化しなければならず、単なる裸の Git に対してではない。
Git LFS は大規模ファイルに関する最も直接的な比較である。Git LFS プロジェクトは、大きなコンテンツをメインの Git リポジトリの外に保つポインタファイルを説明している。GitHub のドキュメントは、プランベースの LFS ファイル制限とポインタ動作を説明している。GitHub はまた、大規模リポジトリの健全性、通常のリポジトリにおける 100 MiB のファイルブロック、推奨リポジトリサイズについて警告している。GitLab のドキュメントは、Git がバイナリ変更をテキスト変更と同じように追跡できず、大規模ファイルへの繰り返し変更がリポジトリサイズを増加させることを説明している；またファイルロックについても文書化している。これらの情報源は、Git エコシステムが大規模ファイル問題を理解していることを示している。
Perforce が勝つのは、購入者のコストが単に「大規模ファイル」ではなく、「複数ロールによるアセット変更の受け入れ」である場合である。コードが Git に、アートが LFS に、レビューがプルリクエストに、バイナリロックがオプションであり、ビルドアーティファクトが他所にあり、プロデューサーが別のシステムで承認を追跡している場合、全体のプロセスは推論が困難になり得る。Perforce は、ソース、バイナリ状態、ロック、チェンジリスト、ストリーム、パーミッション、隣接するレビューツールを一つのリポジトリ制御面の下に置くことで運用モデルを簡素化できる。これは不整合のコストが高い場合に価値がある。
Perforce が負けるのは、購入者がその制御面を必要としないか、維持できない場合である。主にテキストコードを扱う小さなソフトウェアチームはほとんど利益を得られないかもしれない。ビルド出力が再現可能であり、大きな資産がオブジェクトストレージでより良く管理されるクラウドネイティブ企業は P4 を必要としないかもしれない。リポジトリ管理の規律を欠くスタジオは、ロック競合、ストリーム混乱、高価なサポート依存を経験し得る。既に成功している Git LFS とアセットレビューのセットアップを持つチームは、調整節約よりも移行リスクが大きいと感じるかもしれない。
商業的テストには、ライセンスコスト、管理要員、トレーニング、移行、統合、バックアップインフラストラクチャ、ストレージ成長、レビューツーリング、請負業者アクセス、サポート、クラウドホスティングオプション、撤退コストを含めるべきである。撤退コストは特別な注意に値する。Perforce はコード、アート、履歴、パーミッション、チェンジリスト、ラベル、ストリーム、プロセス前提の深いリポジトリになり得る。その深さはシステムが動作している間は有用である。それはまたロックインでもある。購入者は、商業的関係またはツール戦略が変化した場合に、履歴をエクスポートし、バイナリを移動し、来歴を保存し、ユーザーを再訓練するのに何が必要かを理解すべきである。
公正な結論は、Perforce が抽象的には高価か安価かではない。Perforce が経済的であるのは、それが取り除く受け入れ済み変更のコストが、それが追加するプラットフォームコストよりも大きい場合のみである。大規模バイナリアセット組織にとっては、それが真であり得る。通常のコードリポジトリにとっては、しばしばそうではない。
顧客証拠はパターンを支持するが、普遍的な性能主張ではない
Perforce の公的な顧客証拠は、注意深く読めば有用である。Warhorse Studios は Subversion と Mercurial からの移行、デジタル資産の統合、厳格なファイルロックの使用、自動ビルドへの供給を報告した。Game Studio は、Subversion と Git の同時使用の問題（マージ失敗やデータ不整合を含む）の後、Azure 上で Helix Core を実行することについて説明した。NVIDIA のケーススタディは、チップ設計と会社文書の変更管理の文脈に P4 を位置づけている。ECI Telecom は複雑な国際開発環境を説明し、監査証跡、ワークスペース管理、サポートを強調している。Amdocs は ClearCase からの移行について、履歴を保持しながらチームごとの移行を管理することに言及している。Halon と Tarsier は、Git や SVN の制限、アセット、可視性に関するメディアおよびゲーム開発の例を提供している。Transurban は大規模展開、ロールバック、ジャーナル/チェックポイントの価値を強調している。
これらの事例は受け入れ済み変更のテーゼと整合している。ランダムな推奨ではない。大規模バイナリファイルの管理、単一の真実源の維持、ビルドシステムとの統合、分散チームのサポート、監査可能性の保持、旧バージョン管理システムからの移行、ミスからの回復といった反復的な生産タスクの周りに集まっている。それらは Perforce が行うように意図された仕事である。
また限界もある。ほとんどはベンダー公開である。一部は古く、詳細が現在のインフラストラクチャ、製品名、価格設定、サポート境界を表していないかもしれない。一部は一般化できない特定の顧客環境を説明している。75 ユーザーと 3 TB のファイルを持つスタジオは、半導体企業、自動車サプライヤー、小さな独立系ゲームチームとは同じではない。Azure 上のクラウド展開は、すべての P4 Cloud や自己ホスト展開が同じパフォーマンス目標を満たす証明ではない。SVN や Mercurial からの改善の報告は、よく設計された Git LFS とアセット管理スタックに対する改善の証明ではない。
この区別は重要である。なぜなら購入者はしばしばケーススタディを誤用するからである。ロゴや劇的なメトリックを探して約束として扱う。より良い使い方はパターン認識である。公的証拠は、購入者が持つ種類の受け入れ済み変更問題に対して Perforce が使用されていることを示すか？もしそうなら、製品はもっともらしい。証拠は購入者のレイテンシ、ロック競合、ストレージコスト、ユーザー採用、ブランチモデル、サポート結果を証明するか？いいえ。それには依然として購入者が実行するテストが必要である。
Perforce 自身の規模主張についても同じことが言える。トップゲームおよび半導体企業での信頼や投資収益率に関する調査声明を含む。それらは市場での地位と顧客の認識を示す。デューデリジェンスを置き換えるものではない。購入者は自らのドメインでの現在の参照を求め、代表的なパイロットを実施し、実際の変更をシステムに通すコストを測定すべきである。市場採用は採用リスクを下げるが、実装リスクを取り除かない。
したがって、本記事の判断はプロモーション的ではなく中程度である。公的証拠は、Perforce が大規模バイナリおよび規制環境における受け入れ済みソースおよびアセット変更のための重大な制御面として支持する。すべてのチーム、すべてのリポジトリ、すべてのコストモデルに対して Perforce が代替案に勝つことを証明しない。
主な故障モードはエキゾチックではない
Perforce の既知の故障モードは危険なほど普通である：ロック競合、レプリケーション遅延、パーミッションミス、マージ失敗、バイナリアセット破損、ビルド統合の破綻、ブランチ混乱、監査ギャップ、ストレージコスト超過、移行の行き止まり。これらのいずれも劇的な製品故障を必要としない。通常の成長から出現し得る。
ロック競合は解決済みの問題として始まり、スケジューリング問題になり得る。重要なファイルが長時間ロックされていると、他の貢献者は待つか回避策を作成する。ロックが忘れられると、管理者が介入する。ロックが広すぎると生産性が下がる。狭すぎるとマージ不可能な競合が戻る。受け入れ済み変更プロセスは、ロック期間の期待、所有権の可視性、エスカレーション、クリーンアップを定義すべきである。
レプリケーションとエッジトポロジーはグローバルパフォーマンスを改善できるが、調整の詳細を追加する。サブミット、シェルブ、レビューがエッジサーバー、コミットサーバー、レビューツールに同じ状態を見ることに依存する場合、遅延と昇格ルールが重要になる。グローバルロックがコミットサーバー通信を必要とする場合、レイテンシが重要になる。エッジサーバーが固有のワークスペースと進行中作業データを保存する場合、バックアップの選択が重要になる。これらは管理可能な問題だが、運用モデルの一部として扱われる場合に限る。
パーミッションは両方向で失敗し得る。アクセスが少なすぎると作業をブロックし、ビルドを壊し、ユーザーをシャドーシステムに追いやる。アクセスが多すぎると機密 IP を露出したり、センシティブ領域での偶発的な変更を許したりする。Perforce の保護はユーザー、ホスト、デポロケーションによってコマンドを制御できるが、ルールは設計、レビュー、テストが必要である。コード、アート、設計データ、リリースアーティファクトを保持するリポジトリでのパーミッションミスは、狭いコードリポジトリでのミスよりも広範な影響を与え得る。
ブランチとストリームの混乱も一般的なリスクである。Perforce Streams は作業を構造化できるが、ストリームモデルが組織が実際にリリースする方法を反映している場合に限る。モデルが硬直的すぎると、チームはそれを回避する。緩すぎると統合が不明瞭になる。リリースブランチ、コンテンツブランチ、プラットフォームブランチが適切に命名・統治されていないと、受け入れ済み状態は共有ではなく局所的になる。
移行リスクはしばしば過小評価される。Git、SVN、ClearCase、ファイル共有、混合システムから Perforce への移行は単なるデータ転送ではない。習慣の変化である。アーティストはチェックアウトとロックを理解する必要があるかもしれない。開発者はローカルコミット習慣から中央サブミットの規律に適応する必要があるかもしれない。ビルドシステムは新しい同期ロジックを必要とする。履歴は不完全か、完全に保存するには高価すぎるかもしれない。課題、資産、プルリクエスト、アーティファクト間の既存のリンクは壊れるかもしれない。目標状態は良くなり得るが、移行自体にはコストがかかる。
教訓は、Perforce の故障は通常、社会技術的であることだ。製品は強力な制御を与える。悪いガバナンスはそれらの制御を遅延に変える。良いガバナンスはそれらを受け入れ済み状態の信頼性に変える。
購入者はストーリーを信じる前に受け入れ済み変更のリハーサルをすべきである
最も有用な Perforce 評価は、一般的な概念実証ではない。それは受け入れ済み変更のリハーサルである。購入者は実際の作業から代表的な変更を選ぶべきである：大きな Unreal や Unity のアセットと関連コード、VFX シーン更新、ハードウェア設計ファイルセット、自動車ソフトウェアキャリブレーション、生成アーティファクトを含むビルドシステム変更、またはトレーサビリティが必要な規制修正。目標は、提案された作業から信頼される受け入れ済み状態への経路を測定することである。
リハーサルはファイルが追加される前に始めるべきである。タイプマップは正しいか？ファイルは必要に応じてロック可能か？ワークスペースビューは貢献者が必要とするものだけを含むか？貢献者はチェックアウト、編集、ロック、シェルブ、レビュー、サブミット、リバートの方法を理解しているか？非開発者は、すべてのステップでリポジトリスペシャリストに依存することなく、P4V、P4 DAM、プラグイン、その他のクライアントのいずれか適切なツールを使用できるか？
次にレビューである。チェンジリストは適切なスコープを持つか？レビュアーはテキスト変更、画像変更、メタデータ、必要に応じてアセットプレビューを見ることができるか？レビューシステムはファイルの数とサイズを処理できるか？レビューは重要な課題、タスク、ビルド、承認証拠に接続されているか？変更が間違っている場合、レビュアーは孤立したロックや、古いシェルブ、不明確な次のステップを残さずに拒否できるか？
次に統合である。ビルドまたは検証プロセスは、正確な変更または受け入れ済みリビジョンで実行されるか？効率的に同期するか？バイナリ転送コストを処理するか？失敗を明確に報告するか？サービス認証情報は制限されているが十分か？サブミットトリガーが使用されている場合、サブミット経路内で重い作業を行うことなく、悪い入力を早期に拒否するか？ビルドがサブミット前ではなく後にパスする場合、明確なロールバックまたは前進修正ポリシーがあるか？
最後にリカバリーである。保留中の変更を元に戻す。受け入れ済み変更をテスト環境でアンドゥまたはバックアウトする。バックアップから復元する。放棄されたロックを解除する。パーミッションミスを修復する。変更をストリーム間で移動する。チームが一人の記憶に頼らずに何が起こったか説明できるか問う。答えがイエスなら、Perforce はファイルを保存する以上のことをしている。受け入れ済み状態を運用可能にしている。
リハーサルは代替案もテストすべきである。同じ変更を現在の Git LFS、クラウドストレージ、アセット管理プロセスに通す。人々が待つ時間、検索する時間、許可を求める時間、コンフリクトを解決する時間、ビルド状態を確認する時間、証拠を文書化する時間を含める。多くのツール決定は、調整コストが数えられた時に異なって見える。安価なライセンスは高価な人間の作業を隠し得る。より高価なプラットフォームは、繰り返される混乱を取り除くなら経済的であり得る。
Perforce は、現実的な制約の下でこのリハーサルに勝った場合にのみ勝つべきである。小さなデモリポジトリはほとんど何も証明しない。注意深く選ばれた受け入れ済み変更のリハーサルは、Perforce が実際に重要な作業を減らすかどうかを購入者に伝える。
評決：受け入れ済みアセット変更が高価な場所では強く、それ以外では条件付き
Perforce Software, Inc. は、一部のチームが単なるコードホスティングを必要としないために、バージョン管理において依然として信頼できる重要な地位を占めている。彼らはコード、バイナリアセット、設計データ、レビュー、パーミッション、ビルド統合、リカバリーのための受け入れ済みリポジトリ状態を必要とする。P4、P4V、P4 Code Review、P4 DAM、ストリーム、ロック、チェンジリスト、トリガー、プロキシ、エッジアーキテクチャ、リカバリーの実践は、うまく実装された場合にその問題への首尾一貫した答えを形成する。
最も適合するのは、大規模なバイナリまたは構造化設計の変更が頻繁であり、マージ失敗が高コストで、監査可能性が重要であり、複数のロールがプロジェクト状態を共有し、現在のツールチェーンが既に調整に過剰な人間の時間を費やしているチームである。ゲームスタジオ、バーチャルプロダクションチーム、半導体グループ、自動車ソフトウェア組織、その他の大規模アセット集中型エンジニアリンググループは、通常のソフトウェアチームよりも頻繁にそのプロファイルに適合する。彼らにとって、受け入れ済みアセット変更は深刻な運用問題であり、リポジトリの好みではない。
適合が弱いのは、主にテキストコードを書き、再現可能なビルドを持ち、Git ネイティブのレビューを効果的に使用し、アーティファクトを適切な外部システムに保存し、バイナリ調整にあまり苦しんでいないチームである。そのような購入者にとって、Perforce は間違った問題を解決する強力なシステムかもしれない。十分な相殺利益なしに管理、コスト、ロックインを持ち込み得る。
したがって Perforce の商業的な問いは「Git より優れているか？」ではない。「購入者の完全な代替案よりも受け入れ済み変更を安く安全にするか？」である。その代替案には、Git、LFS、アーティファクトストア、クラウドストレージ、課題追跡、ブランチ保護、レビュー、ビルドパイプライン、アセットツールが含まれ得る。Perforce は単純化された戯画ではなく、組み合わせプロセス全体に勝たなければならない。
規律ある購入者は、リポジトリの規模主張ではなく、実際の変更によって Perforce を判断すべきである。変更には厄介な部分を含めるべきである：バイナリファイル、ロック、レビュー、ビルド統合、パーミッション、ロールバック、リカバリー。Perforce がその変更をより明確に、速く、安全に、監査可能にするなら、その価値は具体的である。単にファイルを保存するだけで、組織が所有権、ブランチルール、受け入れ基準について議論し続けるなら、プラットフォームは問題を解決していない。
それが Perforce の狭いが耐久性のあるケースである。その価値は広大なデポを保持できることではない。その価値は、適切な環境において、困難な変更をより曖昧さなく、より無駄なく受け入れ済みにできることである。購入者の責任は、リポジトリが手放せなくなる前に、これが自らの作業にとって真実であることを証明することである。