A step-by-step guide to migrating from Perforce to Git

ステップ 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：複雑な依存関係

A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/git-subtree.

ステップ 5：移行中にチームを構成する方法

さて、お使いの Perforce サーバーには 10 チームによる 100 のプロジェクトがあります。移行戦略が策定されており、ツール セットも用意されています。メンテナンス時間をスケジュールして、実行してください!

いや、ちょっとお待ちください。

SCM ツールの切り替えは、データだけでなく開発者にとっても重要であることを忘れないでください。考慮すべき人、プロセス、スケジュールがあります。実現不可能なことをたった 1 日でやろうとしないでください。あまりに危険すぎます。

実際の移行フェーズ中にプロジェクト計画を検討する必要があります (新しい Jira ワークフローを試してみる良い機会になるかもしれません)。検討事項は以下のとおりです。

• チーム別やプロジェクト別に移行する。スプリントまたはプログラムインクリメントの開始時にプロジェクトとチームを開始することが目的です。これは適応する時間的余裕がある場合に適しています。
• 漸次移行する。週末にすべてのデータをインポートしておき、Git へのチームの移行は時間をかけてゆっくりと完了させます。定期的にインポートツールを再実行して差分をピックアップします。この計画の場合複雑さは増しますが、チーム間に依存関係があり、早期導入者が CI/CD パイプラインをフィードするために少なくとも Git で撮った最近のスナップショットを必要とする場合は適しています。
• 一定期間、同時に両方のシステムを使用する。気弱な人向きではありませんが、技術的には、Git Fusion を使用して双方向のデータ交換を行うことは可能です。ただし、データ変換で混乱を招くような複雑な操作を行っていない場合に限ります。

最後に、モチベーション、理由、実行方法に関する一連のステップなど、変更事項をチームにしっかり伝えてください。ソフトウェア開発ライフサイクル全体で経験を積んだエンジニアがいる「アーリー アダプター」チームを選抜し、そのチームを他のチームのモデルにしましょう。困難に直面している人々を支援できる Git の推進者を探しましょう。小規模で、わかりやすく、反復的な変更を行うことで、このプロセスを成功させることができます。

Step 6: Mirrors and clusters

Perforce には、データをリモートサイトにミラーリングして待ち時間の影響を軽減するためのシンプルで効果的なシステムがあります。読み取り専用クラスタリングのために一群のローカルミラーリングを実行する場合は、より複雑なシステムが用意されています。待ち時間は単に Git の問題ではありませんが、世界中でオペレーションを行なっている場合は、クラスタリングとミラーリングの両方について Bitbucket Data Center を調べる必要があります。これにより、グローバルチームのために複製する時間が大幅に短縮されます。

Step 7: ALM tools

ここで、いくつかの良いお知らせがあります。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 を気に入っている理由をご覧ください。