Perforce から Git に移行するためのステップバイステップ ガイド
前回の記事で説明したように、Git は、ほぼすべてのタイプのデジタル開発において SCM の事実上の選択肢となっています。しかし、Perforce に長年の貴重な履歴が保存されているのならば、おそらく切り替えのコストを慎重に検討していることでしょう。この記事では、これらの問題に正面から取り組み、データを Git に移行する方法について説明します。Perforce から Git への移行プロセスを 8 つのステップに分割しました。
- Perforce データの移動
- ユーザーと権限の新しい Git リポジトリへのマッピング
- 大容量のバイナリファイル
- 複雑な依存関係
- 移行中にチームを構成する
- データのミラーリング
- ALM ツール
- Perforce から Git への移行後に正常に完了したことを確認する方法
ステップ 1：Perforce データの移動
Perforce から Git にデータを移行するには、２つの一般的なアプローチがあります。移行の前に、ソフトウェアプロジェクトの取り扱い方について、Perforce と Git の基本的な違いを考慮する必要があります。
Perforce サーバは、それぞれ独自の分岐モデルを持つ数十から数百の異なるソフトウェアプロジェクトを保持できます。開発者は、作業コピーに入れるファイルを Perforce サーバに伝える「ビュー」を定義します。一方、Git リポジトリは通常、単一のソフトウェアプロジェクトとそのブランチとタグを保持しています（大きな一体型の Git リポジトリも存在します）。通常、リポジトリを複製して、サブモジュールやサブツリーをチェックアウトします。
データを移動する問題には、Perforce からデータを抽出する方法と、それを同等の Git リポジトリのセットに変換する方法の 2 つの部分に分かれています。
Perforce データの移動オプション 1：Git Fusion の使用
Perforce でデータの履歴全体を保存したい場合は、Perforce 独自の Git Fusion ツールを使用して、Perforce サーバーのセクション (単一プロジェクト) を Git リポジトリに抽出できます。基本的には以下の手順を実行します。
- Git Fusion をインストールします。
- 分岐構造を含む、データの正しいビューの設定
- いずれかの Git クライアントを使用して Git Fusion から複製を作成します。
- 自分のリポジトリを Bitbucket にプッシュします。
実践例 *この例を実行するには、Git Fusion が既に稼働している Perforce サーバーが必要です。* Perforce プロジェクトがリポジトリ パス //depot/acme/… (Perforce ディポ表示構文) にあるとします。そこには 3 つのブランチがあります。 - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Perforce では、ブランチはツリー内の追加ディレクトリとして表示されます。 最初のステップは、Perforce の分岐関係を理解できるように Git Fusion を設定することです。これを行うには、リポジトリ設定ファイルを作成します。 [@repo] description = Acme project charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/…… [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/…… Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config ここで、通常の Bitbucket 管理ツールを使用して、acme という名前の空のプロジェクトを Bitbucket に作成します。通常の標準に従ってアクセス制御とチーム メンバーを設定できます。 次に、Git Fusion から複製します。 git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket 完了です。これで、インポートされた履歴が Bitbucket に表示されるはずです。
これで Perforce データを常に 100％ 忠実にコピーできるわけではありません。部分的マージのように、一部の Perforce 操作は、相当する操作が Git に存在しません。しかし、全体として見れば、この方法により多大な労力をかけずに履歴のほとんどを取得することができます。
既存の SCM から最近 10 年間のブランチ作成履歴を保護しても、同じワークフローを継続して使用する必要はないことを覚えておいてください。特に、実用的な第一歩として、Git Flow のようなフィーチャーブランチワークフローの採用を検討すべきです。
メリットとデメリット
- ほとんどのセットアップ作業とランタイムが必要
- ほとんどの履歴を保持 (従来の Perforce サーバをシャットダウンできます）
- 履歴に既存の分岐モデルを維持
Perforce データの移動オプション 2：新たに最初から行う
もう１つの方法はやり直すことです。これまでの入り組んだ履歴のことはすべて忘れてください。そして、プロジェクトに対応する Perforce の各ブランチの head (先端) を単に抽出し、それを新しい空の Git リポジトリにチェックインします (これは、必要なデータの正しい 'ビュー' で Perforce ワークスペースを定義したことになります）。
これは最も簡単で最速のテクニックです。Perforce の履歴がどんなに複雑であっても、新しい Git リポジトリは無駄なくすっきりとしています。蓄積された荷物なしで新しい Git ベースのワークフローを開始できます。
主な欠点としては、おそらく、誰かが何らかの理由で履歴コードを調べる必要がある場合に備えて、古い Perforce サーバを読み取り専用モードに保つ必要があることです。これにより、ライセンス料はかかりませんが、古いサーバーをしばらく維持することになります。
**実践例** ご使用の Perforce ワークスペース (プロジェクト データのマスター ブランチがチェック アウトされているディレクトリ) に移動して p4 sync を実行します。これにより、ファイルの最新のリビジョンが取得されます。 ここで、通常の Bitbucket 管理ツールを使用して、acme という名前の空のプロジェクトを Bitbucket に作成します。通常の標準に従ってアクセス制御とチーム メンバーを設定できます。 次に、ワークスペースに新しい Git リポジトリを作成し、Bitbucket にプッシュします: git init。 git remote add origin git push –u --all origin git push --tags origin 新しい Bitbucket プロジェクトの最初のコミットとしてコードの最新のスナップショットが表示されるはずです。
メリットとデメリット
- 速くて簡単
- 分岐モデルとワークフローの再設計
- 読み取り専用アクセスに使用されるレガシー Perforce サーバー
ステップ 2：ユーザーと権限
データを移動した後の次のタスクは、通常、新しい Bitbucket プロジェクトへのユーザーと権限のマッピングを開始することです。ユーザー ディレクトリに LDAP を使用する場合、ここで時間を節約できます。それ以外の場合は、p4 users –o コマンドを使用して Perforce から一連のユーザー アカウントを簡単に抽出してから、それらをプロジェクトごとに Bitbucket に入力できます。
Perforce の権限はきめ細かくて複雑で、個々のファイルへのアクセスが除外される可能性があるため、Perforce の権限を同等の Bitbucket 権限に変換するのは難しい場合があります。この複雑な権限スキームが、Perforce サーバーが停止する理由の 1 つです。アクセスを試みるたびに、サーバーが複雑なデータ構造に対してコストのかかる計算を実行する可能性があります。
ほとんどの場合、通常のプロジェクト、リポジトリ、およびブランチ レベルの権限を使用して、Bitbucket でより簡単な権限セットを定義するようにプロジェクト リードに依頼するほうが効率的です。Git は非常に多くの新しいワークフロー オプションを提供しているため、いずれにしても権限設定を再検討したくなるでしょう。たとえば、Perforce ではブランチ作成を制限していたかもしれませんが、Bitbucket では main ブランチへのプッシュ アクセスを制限するだけで済む場合もあります。
ステップ 3：バイナリファイル
大きなバイナリ blob を Perforce に保存した場合は、Git でそれらをどのように管理するかを慎重に検討してください。Git LFS を試すこともできますし、代わりに通常のアーティファクト管理システムを使用することもできます。いずれにしても、大きな blob をそのまま Git リポジトリにプッシュしたくはないでしょう。
ステップ 4：複雑な依存関係
Perforce の作業コピーは、実際に複数のモジュールからのデータの読み取り専用コピーにマップされることがあります。Git では、これはサブモジュール、サブツリーを使用するか、CI/CD またはアーティファクト管理システムを利用して行われます。ここでは簡単な答えはありませんが、Git リポジトリ間のサブモジュール関係をモデル化できるデータ インポート ツールもあります。サブモジュールやサブツリーの使い方の詳細については、https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ でそれぞれについて確認できます。
ステップ 5：移行中にチームを構成する方法
さて、お使いの Perforce サーバーには 10 チームによる 100 のプロジェクトがあります。移行戦略が策定されており、ツール セットも用意されています。メンテナンス時間をスケジュールして、実行してください!
いや、ちょっとお待ちください。
SCM ツールの切り替えは、データだけでなく開発者にとっても重要であることを忘れないでください。考慮すべき人、プロセス、スケジュールがあります。実現不可能なことをたった 1 日でやろうとしないでください。あまりに危険すぎます。
実際の移行フェーズ中にプロジェクト計画を検討する必要があります (新しい Jira ワークフローを試してみる良い機会になるかもしれません)。検討事項は以下のとおりです。
- チーム別やプロジェクト別に移行する。スプリントまたはプログラムインクリメントの開始時にプロジェクトとチームを開始することが目的です。これは適応する時間的余裕がある場合に適しています。
- 漸次移行する。週末にすべてのデータをインポートしておき、Git へのチームの移行は時間をかけてゆっくりと完了させます。定期的にインポートツールを再実行して差分をピックアップします。この計画の場合複雑さは増しますが、チーム間に依存関係があり、早期導入者が CI/CD パイプラインをフィードするために少なくとも Git で撮った最近のスナップショットを必要とする場合は適しています。
- 一定期間、同時に両方のシステムを使用する。気弱な人向きではありませんが、技術的には、Git Fusion を使用して双方向のデータ交換を行うことは可能です。ただし、データ変換で混乱を招くような複雑な操作を行っていない場合に限ります。
最後に、モチベーション、理由、実行方法に関する一連のステップなど、変更事項をチームにしっかり伝えてください。ソフトウェア開発ライフサイクル全体で経験を積んだエンジニアがいる「アーリー アダプター」チームを選抜し、そのチームを他のチームのモデルにしましょう。困難に直面している人々を支援できる Git の推進者を探しましょう。小規模で、わかりやすく、反復的な変更を行うことで、このプロセスを成功させることができます。
ステップ 6：ミラーとクラスタ
Perforce には、データをリモートサイトにミラーリングして待ち時間の影響を軽減するためのシンプルで効果的なシステムがあります。読み取り専用クラスタリングのために一群のローカルミラーリングを実行する場合は、より複雑なシステムが用意されています。待ち時間は単に Git の問題ではありませんが、世界中でオペレーションを行なっている場合は、クラスタリングとミラーリングの両方について Bitbucket Data Center を調べる必要があります。これにより、グローバルチームのために複製する時間が大幅に短縮されます。
ステップ 7：ALM ツール
ここで、いくつかの良いお知らせがあります。Perforce から Git に移行する際には、ALM ツール スタックに関するたくさんの選択肢があります。世の中のほとんどすべての開発者と ALM ツールが Git と連携しています。そして、もちろん、Bitbucket は Jira や Bamboo と効率的に統合できます。Git に移行すると、フィーチャー ブランチのワークフローを活用する計画ブランチなどの Bamboo の機能を調べることができます。
ステップ 8：成功の定義
Perforce から Git への移行の間、どのようにして成功を正確に測定するのでしょうか。多くの移行プロジェクトでは、データ転送の忠実性に重点を置く傾向があります。しかし、これは多くの理由から有用なメトリックではありません。Perforce のような集中型 SCM システムで生じたこととまったく同じ内容を、Git においてビット単位の履歴で取得することは決してできないでしょう。
より実用的なアプローチは、CI/CD を検証に使用することです。CI/CD パイプラインを Perforce から Git に切り替えても、依然としてすべてのテストに合格できますか?依然としてソフトウェアのデプロイが可能ですか?重要な古いビルドが CI/CD パイプラインを介してすべて合格できたら、勝利を宣言する時です!
終了
これで、Perforce から Git へ移行する理由と、実際にそこに到達する方法がわかりました。次のステップは Git ソリューションを選択することです。ゲーム開発のために Perforce から切り替える場合は、ゲーム開発者が Bitbucket を気に入っている理由をご覧ください。
