GitHub エンタープライズServer にデータを移行する

移行データの準備

scp コマンドを使用して、ソースインスタンスまたは組織から生成された移行アーカイブを GitHub Enterprise Server ターゲットにコピーします。
```
scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
```
ターゲットの GitHub Enterprise Server インスタンスに SSH で接続します。詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
```
ssh -p 122 admin@HOSTNAME
```
ghe-migrator prepare コマンドを使ってターゲットインスタンスにインポートするためのアーカイブを準備し、以降の手順で使用する新しい移行 GUID を生成します。
```
ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
```
- 新しいインポートの試行を開始するには、もう一度 ghe-migrator prepare を実行し、新しい移行 GUID を取得します。
- 移行ファイルをステージングする場所を指定するには、--staging-path=/full/staging/path を使用してコマンドを追加します。既定値は /data/user/tmp です。

移行のコンフリクトのリストの生成

移行 GUID を指定した ghe-migrator conflicts コマンドを使用して、conflicts.csv ファイルを生成します。
```
ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
```
- 競合が報告されない場合、データを安全にインポートできます。
競合がある場合は、scp コマンドを使用して、conflicts.csv をローカルコンピューターにコピーします。
```
scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
```
「移行コンフリクトの解決もしくはカスタムマッピングのセットアップ」に進みます。

移行コンフリクトのレビュー

テキストエディターまたは CSV 互換のスプレッドシートソフトウェアを使用して、conflicts.csv を開きます。
以下の例と参照表のガイダンスを使用して、conflicts.csv ファイルを確認し、確実にインポート時に適切なアクションが実行されるようにします。

conflicts.csv ファイルには、競合の ''移行マップ'' と推奨アクションが含まれています。移行マップは、ソースから移行されるデータと、そのデータがどのようにターゲットに適用されるかのリストです。

`model_name`	`source_url`	`target_url`	`recommended_action`
`user`	`https://example-gh.source/octocat`	`https://example-gh.target/octocat`	`map`
`organization`	`https://example-gh.source/octo-org`	`https://example-gh.target/octo-org`	`map`
`repository`	`https://example-gh.source/octo-org/widgets`	`https://example-gh.target/octo-org/widgets`	`rename`
`team`	`https://example-gh.source/orgs/octo-org/teams/admins`	`https://example-gh.target/orgs/octo-org/teams/admins`	`merge`
`project`	`https://example-gh.source/octo-org/widgets/projects/1`	`https://example-gh.target/octo-org/projects/1`	`merge`

conflicts.csv の各行には次の情報が示されます。

名前	説明
`model_name`	変更されるデータの種類。
`source_url`	データのソースURL。
`target_url`	期待されるデータのターゲットURL。
`recommended_action`	データのインポート時に推奨されるアクション `ghe-migrator` が実行されます。

各レコードタイプで可能なマッピング

データの転送時に ghe-migrator で実行できるいくつかの異なるマッピングアクションがあります。

`action`	説明	適用可能なモデル
`import`	（デフォルト）ソースからのデータがターゲットにインポートされます。	すべてのレコードタイプ
`map`	ソースデータに基づいて新しいモデルを作成する代わりに、ターゲット内の既存のレコードが使用されます。リポジトリを既存の組織にインポートしたり、ターゲットのユーザー ID をソースのユーザー ID にマッピングしたりする場合に便利です。	ユーザー、組織、プロジェクト
`rename`	ソースからのデータは名前が変更されてターゲットにコピーされます。	ユーザー、組織、リポジトリ、プロジェクト
`map_or_rename`	ターゲットが存在する場合、そのターゲットにマップします。そうでない場合はインポートされたモデルの名前を変更します。	ユーザー
`merge`	ソースからのデータはターゲット上の既存のデータと組み合わされます。	Teams、プロジェクト

conflicts.csv ファイルを確認し、ghe-migrator audit を使用して、確実に適切なアクションが実行されるようにすることを強くお勧めします。すべてが良好な場合、続行できます。

移行コンフリクトの解決もしくはカスタムマッピングのセットアップ

ghe-migrator で正しくない変更が行われると思われる場合は、conflicts.csv 内でデータを変更することによって修正できます。 conflicts.csv 内の任意の行を変更できます。

たとえば、ソースの octocat ユーザーがターゲットの octocat にマップされていることに気付いたとしましょう。

`model_name`	`source_url`	`target_url`	`recommended_action`
`user`	`https://example-gh.source/octocat`	`https://example-gh.target/octocat`	`map`

このユーザをターゲット上の他のユーザにマップさせることができます。 octocat が実際にはターゲットの monalisa であるべきだとわかっているとします。 monalisa を示すように、conflicts.csv の target_url 列を変更することができます。

`model_name`	`source_url`	`target_url`	`recommended_action`
`user`	`https://example-gh.source/octocat`	`https://example-gh.target/monalisa`	`map`

別の例として、octo-org/widgets リポジトリの名前をターゲットインスタンスの octo-org/amazing-widgets に変更する場合は、target_url を octo-org/amazing-widgets、および recommend_action を rename に変更します。

`model_name`	`source_url`	`target_url`	`recommended_action`
`repository`	`https://example-gh.source/octo-org/widgets`	`https://example-gh.target/octo-org/amazing-widgets`	`rename`

カスタムマッピングの追加

移行における一般的なシナリオは、移行されたユーザがターゲット上ではソース上とは異なるユーザ名を持つことです。

ソースのユーザ名のリストとターゲットのユーザー名のリストがあれば、カスタムマッピングのCSVファイルを構築し、各ユーザのユーザ名とコンテンツが移行の終了時点で正しく割り当てられているようにそのファイルを適用できます。

ghe-migrator audit コマンドを使用して、カスタムマッピングを適用するために必要な CSV 形式で、移行されるユーザーの CSV をすばやく生成できます。

ghe-migrator audit -m user -g MIGRATION-GUID > users.csv

これで、その CSV を編集し、マップまたは名前を変更する各ユーザーの新しい URL を入力してから、4 番目の列を更新し、適宜、map または rename が含まれるようにすることができます。

たとえば、ユーザー octocat の名前をターゲット https://example-gh.target の monalisa に変更するには、次の内容の行を作成します。

`model_name`	`source_url`	`target_url`	`state`
`user`	`https://example-gh.source/octocat`	`https://example-gh.target/monalisa`	`rename`

同じプロセスは、カスタムマッピングをサポートする各レコードのマッピングを作成するために使うことができます。詳細については、レコードで可能なマッピングに関する表を参照してください。

修正された移行データの適用

変更を行った後、scp コマンドを使用して、変更した conflicts.csv (または正しい形式の他のマッピング .csv ファイル) をターゲットインスタンスに適用します。
```
scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
```
ghe-migrator map コマンドを使用して移行データを再マップし、変更した .csv ファイルと移行 GUID へのパスを渡します。
```
ghe-migrator map -i conflicts.csv  -g MIGRATION-GUID
```
ghe-migrator map -i conflicts.csv -g MIGRATION-GUID コマンドで競合がまだ存在することが報告された場合は、移行の競合解決プロセスをもう一度実行します。

インポートしたデータを GitHub Enterprise Server に適用する

ターゲットの GitHub Enterprise Server インスタンスに SSH で接続します。詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
```
ssh -p 122 admin@HOSTNAME
```
ghe-migrator import コマンドを使用して、インポートプロセスを開始します。必要なものは次のとおりです。
- 移行 GUID。詳細については、「G GitHub Enterprise Server にインポートするための移行データの準備」を参照してください。
- 認証のための personal access token。私用する personal access token はサイト管理者としての認証専用です。特定のスコープまたはアクセス許可は必要ありません。詳しくは、「個人用アクセストークンを管理する」を参照してください。
```
$ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN

> Starting GitHub::Migrator
> Import 100% complete /
```
- 移行ファイルをステージングする場所を指定するには、--staging-path=/full/staging/path を使用してコマンドを追加します。既定値は /data/user/tmp です。

移行データのレビュー

既定では、ghe-migrator audit はすべてのレコードを返します。また、以下の条件でレコードをフィルタリングすることもできます。

レコードのタイプ。
レコードの状態。

レコードの種類は、移行されたデータで見つかったものと一致します。

レコードタイプのフィルタ

レコードタイプ	フィルター名
ユーザー	`user`
組織	`organization`
リポジトリ	`repository`
Teams	`team`
マイルストーン	`milestone`
Projects (Classic)	`project`
発行	`issue`
Issueのコメント	`issue_comment`
Pull Request	`pull_request`
プルリクエストのレビュー	`pull_request_review`
コミットのコメント	`commit_comment`
プルリクエストのレビューのコメント	`pull_request_review_comment`
リリース	`release`
プルリクエストあるいはIssueに対して行われたアクション	`issue_event`
保護されたブランチ	`protected_branch`

レコードの状態フィルタ

レコードの状態	説明
`export`	レコードはエクスポートされます。
`import`	レコードはインポートされます。
`map`	レコードはマップされます。
`rename`	レコードの名前が変更されます。
`merge`	レコードはマージされます。
`exported`	レコードはエクスポートに成功しました。
`imported`	レコードはインポートに成功しました。
`mapped`	レコードはマップに成功しました。
`renamed`	レコードの名前の変更に成功しました。
`merged`	レコードはマージに成功しました。
`failed_export`	レコードはエクスポートに失敗しました。
`failed_import`	レコードはインポートに失敗しました。
`failed_map`	レコードはマップに失敗しました。
`failed_rename`	レコードの名前の変更に失敗しました。
`failed_merge`	レコードはマージに失敗しました。

監査されたレコードのフィルタリング

ghe-migrator audit コマンドを使用すると、-m フラグを使用してレコードの種類に基づいてフィルター処理できます。同様に、-s フラグを使用してインポート状態をフィルター処理できます。次のようなコマンドです。

ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID

たとえば、インポートに成功したすべての組織とチームを見るには以下のようにします。

$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed

失敗したすべてのインポートを監査することを強くお勧めします。 これを行うには、次のように入力します。

$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed

失敗したインポートに関する懸念がある場合は、GitHub Enterprise サポートにアクセスしてお問い合わせください。

GitHub Enterprise Server でインポートを完了する

ターゲットインスタンスへの移行が適用され、その内容を確認したら、リポジトリのロックを解除して、ソースから削除します。ソースデータを削除する前に、すべてが期待どおりに機能していることを確認するため2週間ほど待つことをおすすめします。

ターゲットインスタンス上でのリポジトリのアンロック

GitHub.com に SSH で接続します。インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリノードに SSH 接続します。クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
Shell
```
ssh -p 122 admin@HOSTNAME
```
```
ssh -p 122 admin@HOSTNAME
```
ghe-migrator unlock コマンドを使用して、インポートされたすべてのリポジトリのロックを解除します。移行GUIDが必要になります。

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project

警告: scheduleトリガーを使用してリポジトリに GitHub Actions ワークフローが含まれている場合、ワークフローはインポート後に自動的に実行されません。スケジュールされたワークフローをもう一度開始するには、リポジトリにコミットをプッシュします。詳しくは、「ワークフローをトリガーするイベント」を参照してください。

ソース上でのリポジトリのアンロック

移行が完了したら、ソースのリポジトリのロックを解除する必要があります。

GitHub.com で組織からリポジトリのロックを解除する

GitHub.com組織のリポジトリのロックを解除するには、DELETE 要求を移行ロック解除エンドポイントに送信します。必要なものは次のとおりです。

認証のためのアクセストークン
移行の一意の id
アンロックするリポジトリの名前

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock

GitHub.com で組織からリポジトリを削除する

GitHub.com組織のリポジトリのロックを解除した後、リポジトリ削除エンドポイントを使用して以前に移行したすべてのリポジトリを削除する必要があります。認証のためのアクセストークンが必要になります。

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  https://api.github.com/repos/ORG-NAME/REPO_NAME

GitHub Enterprise Server インスタンスからリポジトリをアンロックする

GitHub.com に SSH で接続します。インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリノードに SSH 接続します。クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
Shell
```
ssh -p 122 admin@HOSTNAME
```
```
ssh -p 122 admin@HOSTNAME
```
ghe-migrator unlock コマンドを使用して、インポートされたすべてのリポジトリのロックを解除します。移行GUIDが必要になります。

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project

GitHub エンタープライズServer にデータを移行する

この記事の内容