GitHub Enterprise Importer을(를) 사용하는 리포지토리 마이그레이션 정보
GitHub CLI 또는 API를 사용하여 마이그레이션을 실행할 수 있습니다.
GitHub CLI은(는) 마이그레이션 프로세스를 간소화하며 대부분의 고객에게 권장됩니다. 사용자 지정 요구 사항이 많은 고급 고객은 API를 사용하여 GitHub Enterprise Importer와 자체 통합을 빌드할 수 있습니다.
필수 조건
- 마이그레이션의 평가판을 수행하고 곧바로 프로덕션 마이그레이션을 완료하는 것이 좋습니다. 평가판 실행에 대한 자세한 내용은 "Azure DevOps에서 GitHub Enterprise Cloud로 마이그레이션의 개요"을(를) 참조하세요.
- 마이그레이션될 데이터와 가져오기 도구의 알려진 지원 제한 사항을 이해했는지 확인하세요. 자세한 내용은 "Azure DevOps에서 GitHub Enterprise Cloud로 마이그레이션 정보"을(를) 참조하세요.
- 필수는 아니지만 프로덕션 마이그레이션 중에는 작업을 중지하는 것이 좋습니다. Importer은(는) 델타 마이그레이션을 지원하지 않으므로 마이그레이션 중에 발생하는 변경 내용은 마이그레이션되지 않습니다. 프로덕션 마이그레이션 중에 작업을 중단하지 않도록 선택하는 경우, 이러한 변경 내용을 수동으로 마이그레이션해야 합니다.
- GitHub에 대한 대상 조직의 경우 귀하가 조직 소유자이거나 마이그레이션자 역할이 있어야 합니다. 마이그레이션자 역할에 대한 자세한 내용은 "Azure DevOps에서 마이그레이션에 대한 액세스 관리"을 참조하세요.
0단계: GitHub GraphQL API 사용 준비
GraphQL 쿼리를 만들려면 사용자 고유의 스크립트를 작성하거나 Insomnia와 같은 HTTP 클라이언트를 사용해야 합니다.
인증 방법을 포함하여 GitHub GraphQL API를 시작하는 방법에 대한 자세한 내용은 "GraphQL을 사용하여 통화 구성"을 참조하세요.
모든 GraphQL 쿼리를 마이그레이션의 대상으로 보냅니다. 데이터 보존 기능을 갖춘 GitHub Enterprise Cloud로 마이그레이션하는 경우 엔터프라이즈의 하위 도메인인 GHE.com에 대한 엔드포인트로 쿼리를 보내세요.
1단계: 마이그레이션 대상에 대한 ownerId
가져오기
GitHub Enterprise Cloud의 조직 소유자는 마이그레이션된 리포지토리를 소유하려는 조직의 조직 ID라고도 하는 GetOrgInfo
쿼리를 ownerId
에 반환합니다. 마이그레이션 대상을 식별하려면 ownerId
이(가) 필요합니다.
GetOrgInfo
쿼리
query(
$login: String!
){
organization (login: $login)
{
login
id
name
databaseId
}
}
쿼리 변수 | 설명 |
---|---|
login | 조직 이름 |
GetOrgInfo
응답
{
"data": {
"organization": {
"login": "Octo",
"id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
"name": "Octo-org",
"databaseId": 5610
}
}
}
이 예제에서는 MDEyOk9yZ2FuaXphdGlvbjU2MTA=
이(가) 다음 단계에서 사용할 조직 ID 또는 ownerId
입니다.
2단계: 마이그레이션할 위치 식별
createMigrationSource
쿼리를 사용하여 마이그레이션 원본을 설정할 수 있습니다. GetOrgInfo
쿼리에서 수집된 조직 ID 또는 조직 ID를 ownerId
에 제공해야 합니다.
마이그레이션 원본은 ADO 조직입니다.
createMigrationSource
변형
mutation createMigrationSource($name: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
migrationSource {
id
name
url
type
}
}
}
참고: type
에 AZURE_DEVOPS
을(를) 사용해야 합니다.
쿼리 변수 | 설명 |
---|---|
name | 마이그레이션 원본의 이름입니다. 이 이름은 사용자 고유의 참조용이므로, 모든 문자열을 사용할 수 있습니다. |
ownerId | GitHub Enterprise Cloud에 있는 조직의 조직 ID입니다. |
createMigrationSource
응답
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
"name": "Azure Devops Source",
"url": "https://dev.azure.com",
"type": "AZURE_DEVOPS"
}
}
}
}
이 예제에서 MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA
은(는) 다음 단계에서 사용할 마이그레이션 원본 ID입니다.
3단계: 리포지토리 마이그레이션 시작
마이그레이션을 시작하면 단일 리포지토리와 함께 제공되는 데이터가 사용자가 식별하는 새로운 GitHub 리포지토리로 마이그레이션됩니다.
동일한 원본 조직에서 한 번에 여러 리포지토리를 이동하려는 경우 여러 마이그레이션을 큐에 대기시킬 수 있습니다. 최대 5개까지의 리포지토리 마이그레이션을 동시에 실행할 수 있습니다.
startRepositoryMigration
변형
mutation startRepositoryMigration (
$sourceId: ID!,
$ownerId: ID!,
$sourceRepositoryUrl: URI!,
$repositoryName: String!,
$continueOnError: Boolean!,
$accessToken: String!,
$githubPat: String!,
$targetRepoVisibility: String!
){
startRepositoryMigration( input: {
sourceId: $sourceId,
ownerId: $ownerId,
repositoryName: $repositoryName,
continueOnError: $continueOnError,
accessToken: $accessToken,
githubPat: $githubPat,
targetRepoVisibility: $targetRepoVisibility
sourceRepositoryUrl: $sourceRepositoryUrl,
}) {
repositoryMigration {
id
migrationSource {
id
name
type
}
sourceUrl
}
}
}
쿼리 변수 | 설명 |
---|---|
sourceId | 마이그레이션 원본 id 이(가) createMigrationSource 변경에서 반환되었습니다. |
ownerId | GitHub Enterprise Cloud에 있는 조직의 조직 ID입니다. |
repositoryName | GitHub Enterprise Cloud에서 조직이 소유한 리포지토리 내의 현재 사용되지 않는 사용자 지정 고유 리포지토리 이름입니다. 마이그레이션이 완료되었거나 중지되었을 경우, 오류 로깅 문제가 이 리포지토리에 생성됩니다. |
continueOnError | 마이그레이션이 실패하지 않는 오류가 발생할 경우, 마이그레이션을 계속할 수 있도록 하는 마이그레이션 설정입니다. true 또는 false 이어야 합니다. Importer에서 Git 원본을 이동할 수 없거나 Importer이(가) 연결을 끊고 마이그레이션을 완료하기 위해 다시 연결할 수 없는 한 마이그레이션이 계속되도록 continueOnError 을(를) true (으)로 설정하는 것이 좋습니다. |
githubPat | personal access token의 대상 조직에 대한 GitHub Enterprise Cloud입니다. |
accessToken | 원본에 대한 personal access token입니다. |
targetRepoVisibility | 새로운 리포지토리의 표시 여부 변경 private , public 또는 internal 여야 합니다. 설정하지 않은 경우, 리포지토리가 프라이빗으로 마이그레이션됩니다. |
sourceRepositoryUrl | 형식 https://dev.azure.com/{organization}/{project}/_git/{repository} 을(를) 사용하는 원본 리포지토리의 URL입니다. |
personal access token 요구 사항은 "Azure DevOps에서 마이그레이션에 대한 액세스 관리"을 참조하세요.
다음 단계에서는 startRepositoryMigration
변형에서 반환된 마이그레이션 ID를 사용하여 마이그레이션 상태를 검사합니다.
4단계: 마이그레이션 상태 확인
마이그레이션 오류를 감지하고 마이그레이션이 작동하는지 확인하려면 getMigration
쿼리를 사용하여 마이그레이션 상태를 검사할 수 있습니다. getMigrations
(으)로 여러 마이그레이션의 상태를 검사할 수도 있습니다.
getMigration
쿼리는 상태를 반환하여 마이그레이션이 queued
, in progress
, failed
또는 completed
일지 알려줍니다. 마이그레이션에 실패한 경우 Importer은(는) 실패의 원인을 제공합니다.
getMigration
쿼리
query (
$id: ID!
){
node( id: $id ) {
... on Migration {
id
sourceUrl
migrationSource {
name
}
state
failureReason
}
}
}
쿼리 변수 | 설명 |
---|---|
id | startRepositoryMigration 변형이 반환된 id 마이그레이션입니다. |
5단계: 마이그레이션 유효성 검사 및 오류 로그 검사
마이그레이션이 완료되면, 마이그레이션 로그 리포지토리를 검사하는 것이 좋습니다. 이 문제는 대상 리포지토리의 GitHub에서 생성됩니다.
마지막으로, 마이그레이션된 리포지토리에서 건전성 검사를 검토하는 것이 좋습니다.
1단계: ADO2GH extension of the GitHub CLI 설치
첫 번째 마이그레이션인 경우 ADO2GH extension of the GitHub CLI을(를) 설치해야 합니다. GitHub CLI에 대한 자세한 내용은 "GitHub CLI 정보"을 참조하세요.
또는 github/gh-ado2gh
리포지토리의 릴리스 페이지에서 독립 실행형 이진 파일을 다운로드할 수 있습니다. gh
접두사 없이 이 이진 파일을 직접 실행할 수 있습니다.
-
GitHub CLI을(를) 설치하세요. GitHub CLI에 대한 설치 지침은 GitHub CLI 리포지토리를 참조하세요.
참고: GitHub CLI 버전 2.4.0 이상이 필요합니다.
gh --version
명령을 사용하여 설치한 버전을 검사할 수 있습니다. -
ADO2GH extension을(를) 설치합니다.
Shell gh extension install github/gh-ado2gh
gh extension install github/gh-ado2gh
ADO2GH extension에 대한 도움이 필요할 때마다 명령과 함께 --help
플래그를 사용할 수 있습니다. 예를 들어, gh ado2gh --help
은(는) 사용 가능한 모든 명령을 나열하고 gh ado2gh migrate-repo --help
은(는) migrate-repo
명령에 사용할 수 있는 모든 옵션을 나열합니다.
2단계: ADO2GH extension of the GitHub CLI 업데이트
ADO2GH extension of the GitHub CLI은(는) 매주 업데이트됩니다. 최신 버전의 확장을 사용하고 있는지 확인합니다.
gh extension upgrade github/gh-ado2gh
gh extension upgrade github/gh-ado2gh
3단계: 환경 변수 설정
ADO2GH extension을(를) 사용하여 GitHub Enterprise Cloud(으)로 마이그레이션하기 전에 원본 및 대상 조직에 액세스할 수 있는 personal access token을(를) 만든 다음, personal access token을(를) 환경 변수로 설정해야 합니다.
-
GitHub Enterprise Cloud에서 대상 조직에 대해 인증할 personal access token (classic)을(를) 만들고 기록하여 토큰이 모든 요구 사항을 충족하는지 확인합니다. 자세한 내용은 "Azure DevOps에서 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.
-
Azure DevOps에서 원본 조직에 대해 인증할 personal access token을(를) 만들고 기록하여 이 토큰이 동일한 요구 사항을 모두 충족하는지 확인합니다. 자세한 내용은 "Azure DevOps에서 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.
-
personal access token에 대한 환경 변수를 설정하고, 아래 명령의 토큰을 위에서 기록한 personal access token(으)로 바꿉니다. 대상 조직에 대한
GH_PAT
및 원본 조직에 대한ADO_PAT
을(를) 사용합니다.-
Terminal을 사용하는 경우
export
명령을 사용합니다.Shell export GH_PAT="TOKEN" export ADO_PAT="TOKEN"
export GH_PAT="TOKEN" export ADO_PAT="TOKEN"
-
PowerShell을 사용하는 경우
$env
명령을 사용합니다.Shell $env:GH_PAT="TOKEN" $env:ADO_PAT="TOKEN"
$env:GH_PAT="TOKEN" $env:ADO_PAT="TOKEN"
-
-
데이터 보존 기능을 갖춘 GitHub Enterprise Cloud로 마이그레이션하는 경우, 편리하게 엔터프라이즈에 대한 베이스 API URL의 환경 변수를 설정합니다. 예시:
Shell export TARGET_API_URL="https://api.octocorp.ghe.com"
export TARGET_API_URL="https://api.octocorp.ghe.com"
이 변수는 GitHub CLI에서 실행하는 명령에
--target-api-url
옵션과 함께 사용합니다.
4단계: 마이그레이션 스크립트 생성
여러 리포지토리를 한 번에 GitHub Enterprise Cloud으로 마이그레이션하려면 GitHub CLI을(를) 사용하여 마이그레이션 스크립트를 생성합니다. 결과 스크립트에는 리포지토리당 하나씩의 마이그레이션 명령 목록이 포함됩니다.
참고: 스크립트를 생성하면 PowerShell 스크립트가 출력됩니다. 터미널을 사용하는 경우 .ps1
파일 확장과 함께 스크립트를 출력하고 Mac 또는 Linux용 PowerShell을 설치하여 실행해야 합니다.
단일 리포지토리를 마이그레이션하려면 다음 단계로 건너뜁니다.
마이그레이션 스크립트 생성
마이그레이션 스크립트를 생성하려면 gh ado2gh generate-script
명령을 실행합니다.
gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output FILENAME
gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output FILENAME
자리 표시자
명령 내의 자리 표시자를 다음 값으로 바꿉니다.
자리 표시자 | 값 |
---|---|
SOURCE | 원본 조직의 이름 |
대상 | 대상 조직의 이름 |
FILENAME | 결과 마이그레이션 스크립트의 파일 이름 터미널을 사용하는 경우 생성된 스크립트에서 PowerShell을 실행해야 하므로 .ps1 파일 확장을 사용합니다. Mac 또는 Linux용 PowerShell을 설치할 수 있습니다. |
추가 인수
인수 | 설명 |
---|---|
--target-api-url TARGET-API-URL | GHE.com로 마이그레이션하는 경우 --target-api-url TARGET-API-URL 을(를) 추가합니다. 여기서 TARGET-API-URL은 엔터프라이즈 하위 도메인의 기본 API URL입니다. 예: https://api.octocorp.ghe.com |
--all | 파이프라인 다시 연결, 팀 만들기 및 Azure Boards 통합 구성과 같은 추가 기능을 스크립트에 추가합니다. |
--download-migration-logs | 마이그레이션된 각 리포지토리에 대한 마이그레이션 로그를 다운로드합니다. 마이그레이션 로그에 대한 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션 로그 액세스"를 참조하세요. |
마이그레이션 스크립트 검토
스크립트를 생성한 후, 파일을 검토하고 필요에 따라 스크립트를 편집합니다.
- 마이그레이션하지 않으려는 리포지토리가 있는 경우, 해당 줄을 삭제하거나 주석 처리합니다.
- 리포지토리가 대상 조직에 다른 이름을 갖도록 하려면 해당
--target-repo
플래그 값을 업데이트합니다. - 새 리포지토리의 표시 여부를 변경하려면 해당
--target-repo-visibility
플래그의 값을 업데이트합니다. 기본적으로 스크립트는 원본 리포지토리와 동일한 표시 여부를 설정합니다.
ADO2GH을(를) GitHub CLI의 확장이 아닌 독립 실행형 바이너리로 다운로드한 경우 gh ado2gh
대신 이진 파일을 실행하려면 생성된 스크립트를 업데이트해야 합니다.
5단계: 리포지토리 마이그레이션
gh ado2gh migrate-repo
명령이 포함된 마이그레이션 스크립트 또는 단일 리포지토리를 사용하여 여러 리포지토리를 마이그레이션할 수 있습니다.
여러 리포지토리 마이그레이션
여러 리포지토리를 동시에 마이그레이션하려면 이 위에서 생성한 스크립트를 실행합니다. 아래 명령의 FILENAME을 스크립트를 생성할 때 제공받은 파일 이름으로 바꿉니다.
-
터미널을 사용하는 경우,
./
을(를) 사용하세요.Shell ./FILENAME
./FILENAME
-
PowerShell을 사용하는 경우
.\
을(를) 사용하세요.Shell .\FILENAME
.\FILENAME
단일 리포지토리 마이그레이션
단일 리포지토리를 마이그레이션하려면 gh ado2gh migrate-repo
명령을 사용하세요.
gh ado2gh migrate-repo --ado-org SOURCE --ado-team-project TEAM-PROJECT --ado-repo CURRENT-NAME --github-org DESTINATION --github-repo NEW-NAME
gh ado2gh migrate-repo --ado-org SOURCE --ado-team-project TEAM-PROJECT --ado-repo CURRENT-NAME --github-org DESTINATION --github-repo NEW-NAME
Note
GHE.com로 마이그레이션하는 경우 --target-api-url TARGET-API-URL
을(를) 추가합니다. 여기서 TARGET-API-URL은 엔터프라이즈 하위 도메인의 기본 API URL입니다. 예: https://api.octocorp.ghe.com
명령 내의 자리 표시자를 다음 값으로 바꿉니다.
자리 표시자 | 값 |
---|---|
SOURCE | 원본 조직의 이름 |
CURRENT-NAME | 마이그레이션할 리포지토리의 이름 |
대상 | 대상 조직의 이름 |
NEW-NAME | 마이그레이션된 리포지토리에서 사용할 이름 |
팀 프로젝트 | 마이그레이션하려는 리포지토리의 팀 프로젝트 이름 |
마이그레이션을 취소하려면 abort-migration
명령을 사용하여 MIGRATION-ID를 migrate-repo
에서 반환된 ID로 바꿔야 합니다.
gh ado2gh abort-migration --migration-id MIGRATION-ID
gh ado2gh abort-migration --migration-id MIGRATION-ID
6단계: 마이그레이션 유효성 검사 및 오류 로그 검사
마이그레이션이 완료되면, 마이그레이션 로그를 검토하는 것이 좋습니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션 로그 액세스"을(를) 참조하세요.
마이그레이션된 리포지토리에서 건전성 검사를 검토하는 것이 좋습니다.