GitHub Enterprise 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`	원본의 데이터는 대상의 기존 데이터와 결합됩니다.	팀, 프로젝트

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을 입력한 다음, 필요한 경우 네 번째 열에 map 또는 rename을 포함하도록 업데이트할 수 있습니다.

예를 들어 대상 https://example-gh.target에서 octocat 사용자의 이름을 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입니다. 자세한 내용은 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`
프로젝트(클래식)	`project`
문제	`issue`
이슈 설명	`issue_comment`
끌어오기 요청	`pull_request`
끌어오기 요청 검토	`pull_request_review`
커밋 주석	`commit_comment`
끌어오기 요청 검토 설명	`pull_request_review_comment`
릴리스	`release`
끌어오기 요청 또는 문제에 대해 수행된 작업	`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주 정도 대기하여 모든 요소가 예상대로 작동하는지 확인하는 것이 좋습니다.

대상 인스턴스에서 리포지토리 잠금 해제

에 SSH합니다. 인스턴스가 여러 노드로 구성된 경우(예: 고가용성 또는 지역 복제가 구성된 경우) 주 노드에 대한 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

Warning

리포지토리에 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 인스턴스에서 리포지토리 잠금 해제

에 SSH합니다. 인스턴스가 여러 노드로 구성된 경우(예: 고가용성 또는 지역 복제가 구성된 경우) 주 노드에 대한 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 Enterprise Server로 데이터 마이그레이션

이 문서의 내용