Close

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

前回の記事で説明したように、Git は、ほぼすべてのタイプのデジタル開発において SCM の事実上の選択肢となっています。しかし、Perforce に長年の貴重な履歴が保存されているのならば、おそらく切り替えのコストを慎重に検討していることでしょう。この記事では、これらの問題に正面から取り組み、データを Git に移行する方法について説明します。Perforce から Git への移行プロセスを 8 つのステップに分割しました。


ステップ 1:Perforce データの移動

Perforce から Git にデータを移行するには、2つの一般的なアプローチがあります。移行の前に、ソフトウェアプロジェクトの取り扱い方について、Perforce と Git の基本的な違いを考慮する必要があります。

Perforce サーバは、それぞれ独自の分岐モデルを持つ数十から数百の異なるソフトウェアプロジェクトを保持できます。開発者は、作業コピーに入れるファイルを Perforce サーバに伝える「ビュー」を定義します。一方、Git リポジトリは通常、単一のソフトウェアプロジェクトとそのブランチとタグを保持しています(大きな一体型の Git リポジトリも存在します)。通常、リポジトリを複製して、サブモジュールやサブツリーをチェックアウトします。

データを移動する問題には、Perforce からデータを抽出する方法と、それを同等の Git リポジトリのセットに変換する方法の 2 つの部分に分かれています。

Perforce データの移動オプション 1:Git Fusion の使用

Perforce でデータの履歴全体を保存したい場合は、Perforce 独自の Git Fusion ツールを使用して、Perforce サーバーのセクション (単一プロジェクト) を Git リポジトリに抽出できます。基本的には以下の手順を実行します。

データベース
関連資料

Git リポジトリ全体を移動する方法

Bitbucket ロゴ
ソリューションを見る

Bitbucket Cloud での Git の使用方法についてのチュートリアルです。

  • Git Fusion をインストールします。
  • 分岐構造を含む、データの正しいビューの設定
  • いずれかの Git クライアントを使用して Git Fusion から複製を作成します。
  • 自分のリポジトリを Bitbucket にプッシュします。
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@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 Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket  git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in Bitbucket.

これで Perforce データを常に 100% 忠実にコピーできるわけではありません。部分的マージのように、一部の Perforce 操作は、相当する操作が Git に存在しません。しかし、全体として見れば、この方法により多大な労力をかけずに履歴のほとんどを取得することができます。

既存の SCM から最近 10 年間のブランチ作成履歴を保護しても、同じワークフローを継続して使用する必要はないことを覚えておいてください。特に、実用的な第一歩として、Git Flow のようなフィーチャーブランチワークフローの採用を検討すべきです。

メリットとデメリット

  • ほとんどのセットアップ作業とランタイムが必要
  • ほとんどの履歴を保持 (従来の Perforce サーバをシャットダウンできます)
  • 履歴に既存の分岐モデルを維持

Perforce データの移動オプション 2:新たに最初から行う

もう1つの方法はやり直すことです。これまでの入り組んだ履歴のことはすべて忘れてください。そして、プロジェクトに対応する Perforce の各ブランチの head (先端) を単に抽出し、それを新しい空の Git リポジトリにチェックインします (これは、必要なデータの正しい 'ビュー' で Perforce ワークスペースを定義したことになります)。

これは最も簡単で最速のテクニックです。Perforce の履歴がどんなに複雑であっても、新しい Git リポジトリは無駄なくすっきりとしています。蓄積された荷物なしで新しい Git ベースのワークフローを開始できます。

主な欠点としては、おそらく、誰かが何らかの理由で履歴コードを調べる必要がある場合に備えて、古い Perforce サーバを読み取り専用モードに保つ必要があることです。これにより、ライセンス料はかかりませんが、古いサーバーをしばらく維持することになります。

**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin  git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.

メリットとデメリット

  • 速くて簡単
  • 分岐モデルとワークフローの再設計
  • 読み取り専用アクセスに使用されるレガシー 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:複雑な依存関係

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 を気に入っている理由をご覧ください


この記事を共有する
次のトピック

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

一面のツールを使ってコラボレーションしている人たち

Bitbucket ブログ

DevOps のイラスト

DevOps ラーニング パス

Demo Den アトラシアン・エキスパートによる機能デモ

Bitbucket Cloud が、Atlassian Open DevOps とどのように連携するか

DevOps ニュースレター購読

Thank you for signing up