참고: GitHub Enterprise Importer은(는) 현재 공개 베타 버전이며 변경될 수 있습니다.
Azure DevOps에서 마이그레이션 정보
GitHub Enterprise Importer을(를) 사용하여 리포지토리별로 GitHub Enterprise Cloud로 마이그레이션할 수 있습니다. 자세한 내용은 "GitHub Enterprise Importer 정보.
ADO(Azure DevOps)에서 마이그레이션하는 경우 이 가이드를 사용하여 마이그레이션을 계획하고 구현하고 후속 작업을 완료할 수 있습니다.
ADO에서 GitHub로 마이그레이션하는 기업은 일반적으로 다단계 접근 방식을 따릅니다.
- 리포지토리를 ADO에서 GitHub로 마이그레이션합니다.
- Azure Pipelines에서 GitHub Actions로 파이프라인을 마이그레이션합니다.
- 보드 및 아티팩트와 같은 나머지 자산을 ADO에서 GitHub로 마이그레이션합니다.
이 가이드에서는 리포지토리를 GitHub로 마이그레이션하는 첫 번째 단계를 완료하는 방법을 안내하고 ADO2GH extension of the GitHub CLI을(를) 사용하고 있다고 가정합니다.
마이그레이션 계획
마이그레이션을 계획하려면 다음 질문을 스스로에게 묻습니다.
마이그레이션을 얼마나 빨리 완료해야 합니까?
타임라인을 결정합니다. 이 타임라인은 주로 접근 방식을 결정합니다. 타임라인을 결정하는 첫 번째 단계는 마이그레이션해야 하는 항목의 인벤토리를 가져오는 것입니다. 이 데이터를 수집하려면 GitHub Migration Analyzer를 사용합니다. 이 오픈 소스 도구는 조직을 위해 마이그레이션할 데이터의 양을 자세히 설명한 보고서를 생성합니다.
- 리포지토리 수
- 끌어오기 요청 수
마이그레이션 타이밍은 주로 리포지토리의 끌어오기 요청 수를 기반으로 합니다. 1,000개의 리포지토리를 마이그레이션하고 각 리포지토리에 평균 100개의 끌어오기 요청이 있고 50명의 사용자만 리포지토리에 기여한 경우 마이그레이션이 매우 빠를 수 있습니다. 100개의 리포지토리만 마이그레이션하려고 하지만 리포지토리에 각각 평균 75,000개의 끌어오기 요청과 5,000명의 사용자가 있는 경우 마이그레이션이 훨씬 더 오래 걸리고 훨씬 더 많은 계획과 테스트가 필요합니다.
분석기를 사용한 후 원하는 타임라인에 대해 인벤토리 데이터의 무게를 측정할 수 있습니다. 조직에서 더 높은 수준의 변경을 견딜 수 있는 경우 모든 리포지토리를 한 번에 마이그레이션하여 며칠 안에 마이그레이션 작업을 완료할 수 있습니다. 그러나 동시에 마이그레이션할 수 없는 다양한 팀이 있을 수 있습니다. 이 경우 마이그레이션 작업을 확장하여 팀의 타임라인에 맞게 마이그레이션을 일괄 처리하고 엇갈릴 수 있습니다.
- GitHub Migration Analyzer를 사용한 다음 마이그레이션 인벤토리를 검토합니다.
- 팀이 마이그레이션할 준비가 된 시기를 이해하려면 관련자를 인터뷰합니다.
- 이 가이드의 나머지 부분을 완전히 검토한 다음 마이그레이션 타임라인을 결정합니다.
마이그레이션할 내용이 이해되나요?
사용자와 관련자가 GitHub Enterprise Importer에서 마이그레이션할 수 있는 데이터를 이해해야 합니다.
ADO에서 마이그레이션하는 경우 GitHub Enterprise Importer은 끌어오기 요청 및 일부 분기 정책을 포함하여 Git 리포지토리만 마이그레이션합니다. 파이프라인, 작업 항목, 아티팩트, 테스트 계획, 릴리스 및 대시보드와 같은 다른 모든 자산은 ADO에 유지됩니다.
권한은 ADO와 GitHub에서 다르게 작동하므로 GitHub Enterprise Importer는 ADO에서 리포지토리 권한을 마이그레이션하려고 시도하지 않습니다. 자세한 내용은 "권한 구성"을 참조하세요.
서비스 후크는 ADO에서 마이그레이션되지 않으므로 별도로 다시 만들어야 합니다.
- Azure DevOps에서 마이그레이션된 데이터를 검토합니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션 지원"을 참조하세요.
- 수동으로 마이그레이션하거나 다시 만들어야 하는 모든 데이터 목록을 만듭니다.
마이그레이션을 실행할 사람은 누구인가요?
리포지토리를 마이그레이션하려면 대상 조직의 조직 소유자이거나 조직 소유자가 사용자에게 마이그레이션자 역할을 부여해야 합니다.
- 대상 조직의 조직 소유자가 마이그레이션을 수행할지 또는 다른 사람에게 마이그레이션자 역할을 부여해야 하는지 여부를 결정합니다.
- 마이그레이션자 역할을 부여하도록 선택한 경우 역할을 부여할 사람 또는 팀을 결정합니다.
- 개인 또는 팀에 마이그레이션자 역할을 부여합니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션자 역할 부여"을 참조하세요. 1. 사용자가 모든 액세스 요구 사항을 충족하도록 personal access tokens을(를) 올바르게 구성했는지 확인합니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 액세스 관리"을 참조하세요.
GitHub에서 원하는 조직 구조는 무엇인가요?
다음으로 GitHub에서 만들 조직 구조를 계획합니다. ADO 및 GitHub에는 엔터프라이즈 작업을 구성하는 다양한 방법이 있습니다.
- ADO: 조직 > 팀 프로젝트 > 리포지토리
- GitHub: 엔터프라이즈 > 조직 > 리포지토리
참고: ADO에서 리포지토리를 그룹화하는 데 사용되는 팀 프로젝트의 개념은 GitHub에 없습니다. GitHub Enterprise Server의 조직을 ADO의 팀 프로젝트와 동등한 것으로 취급하지 않는 것이 좋습니다.
GitHub로 마이그레이션한 후에는 엔터프라이즈 계정이 하나만 있고 해당 엔터프라이즈가 소유한 조직은 소수에 불과해야 합니다. ADO의 각 조직은 GitHub의 단일 조직에 해당해야 합니다. ADO의 각 팀 프로젝트에 대해 GitHub에 조직을 만들지 않는 것이 좋습니다.
이로 인해 각 조직 내에서 그룹화되지 않은 리포지토리의 큰 목록이 발생할 수 있습니다. 그러나 팀을 만들어 리포지토리 그룹에 대한 액세스를 관리할 수 있습니다. 자세한 내용은 "팀 정보"을 참조하세요.
마이그레이션 작업을 일괄 처리로 분리하려는 경우 새 구조가 일괄 처리를 결정하는 데 도움이 될 수 있습니다. ADO에 둘 이상의 조직이 있고 각 조직의 리포지토리가 합리적으로 크기가 조정된 일괄 처리인 경우 조직별로 일괄 처리를 고려합니다. GitHub CLI를 사용하여 ADO에서 전체 조직에 대한 마이그레이션 스크립트를 생성할 수 있습니다.
- 새 조직 구조가 무엇인지 결정합니다.
- 마이그레이션 작업을 더 작은 일괄 처리로 분할해야 하는지 여부를 결정합니다.
- 그렇다면 마이그레이션을 중단하는 방법을 결정합니다.
마이그레이션 실행
계획을 완료한 후 실제 마이그레이션을 시작할 수 있습니다. 마이그레이션 중 및 마이그레이션 후에 엔터프라이즈에 고유할 수 있는 문제를 파악할 수 있도록 모든 마이그레이션의 평가판 실행을 수행하는 것이 좋습니다. 평가판 실행에서 발견된 문제를 해결한 후 프로덕션 마이그레이션을 실행할 수 있습니다.
평가판 마이그레이션은 몇 가지 중요한 정보를 결정하는 데 도움이 됩니다.
- 지정된 리포지토리에 대한 마이그레이션이 성공적으로 완료될 수 있는지 여부
- 리포지토리를 사용자가 작업을 성공적으로 시작할 수 있는 상태로 되돌릴 수 있는지 여부
- 마이그레이션을 실행하는 데 걸리는 시간- 마이그레이션 일정을 계획하고 관련자의 기대치를 설정하는 데 유용합니다.
평가판 실행에는 많은 시간 조정이 필요하지 않습니다. GitHub Enterprise Importer은(는) 마이그레이션 중인 리포지토리의 사용자에게 가동 중지 시간이 필요하지 않습니다. 그러나 마이그레이션 중에 새 데이터가 생성되지 않도록 프로덕션 마이그레이션 중에 작업을 중지하는 것이 좋습니다. 그러면 마이그레이션된 리포지토리에서 누락됩니다. 이는 평가판 마이그레이션에 대한 문제가 아니므로 언제든지 평가판 실행이 발생할 수 있습니다. 평가판 마이그레이션을 완료하는 데 걸리는 시간을 줄이기 위해 평가판 실행에 대한 일괄 처리를 다시 예약할 수 있습니다. 그런 다음, 해당 리포지토리의 사용자는 자신의 시간에 결과의 유효성을 검사할 수 있습니다.
평가판 마이그레이션의 대상으로 사용할 테스트 조직을 만드는 것이 좋습니다. 모든 평가판 실행에 단일 조직을 사용하거나 원하는 각 대상 조직에 대해 하나의 테스트 조직을 만들 수 있습니다. 조직이 프로덕션이 아닌 마이그레이션 유효성 검사를 위한 것임을 명확히 하려면 조직 이름의 끝에 를 포함하는 -sandbox 것이 좋습니다. 완료되면 테스트 조직을 삭제할 수 있습니다.
- 평가판 마이그레이션을 위한 테스트 조직을 만듭니다.
- 평가판 마이그레이션을 실행합니다. 자세한 내용은 "GitHub Enterprise Importer를 사용하여 마이그레이션 실행 준비"을 참조하세요.
- 평가판 마이그레이션에 대해 아래에 설명된 후속 작업을 완료합니다.
- 사용자에게 마이그레이션 결과의 유효성을 검사하도록 요청합니다.
- 평가판 마이그레이션에서 발견된 문제를 해결합니다. 1. 대상에서 IP 허용 목록을 사용하는 경우 GitHub Enterprise Importer의 액세스를 허용하도록 목록을 구성합니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 액세스 관리"을 참조하세요.
- 프로덕션 마이그레이션을 실행합니다. 자세한 내용은 "Azure DevOps에서 GitHub Enterprise Cloud로 리포지토리 마이그레이션"을 참조하세요.
- 필요에 따라 테스트 조직을 삭제합니다.
후속 작업 완료
각 마이그레이션이 완료되면 리포지토리가 작동할 준비가 되기 전에 몇 가지 추가 작업을 완료해야 합니다.
마이그레이션 로그 검토
먼저 마이그레이션된 각 리포지토리에 대한 마이그레이션 로그를 검토합니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션 로그 액세스"을 참조하세요.
리포지토리 내의 특정 항목을 마이그레이션할 수 없는 경우 마이그레이션 로그에 경고가 표시됩니다.
참고: "마이그레이션 로그" 문제에 아래쪽에 "마이그레이션 완료됨"이 포함된 경우 리포지토리가 마이그레이션되었습니다. 오류 메시지는 끌어오기 요청에 대한 주석과 같이 리포지토리 내의 특정 항목이 올바르게 마이그레이션되지 않았을 수 있음을 나타냅니다.
- 마이그레이션 로그를 검토합니다.
- 각 로그에 대한 경고를 검토하고 마이그레이션 수용을 차단하는 경고가 없는지 확인합니다. 자세한 내용은 "GitHub Enterprise Importer를 사용하여 마이그레이션 문제 해결"을 참조하세요.
리포지토리 표시 유형 설정
모든 리포지토리는 프라이빗으로 마이그레이션되며 마이그레이션을 실행한 사용자와 조직 소유자만 리포지토리에 액세스할 수 있습니다. 리포지토리를 프라이빗으로 설정하지 않으려면 표시 유형을 변경합니다.
- 브라우저에서 리포지토리의 표시 유형을 변경할 수 있습니다. 자세한 내용은 "리포지토리 표시 유형 설정"을 참조하세요.
- 또는 GitHub CLI을(를) 사용하여 명령줄에서 리포지토리 표시 유형을 변경할 수 있습니다. 마이그레이션을 실행하기 위해 생성된 스크립트에 이 명령을 추가할 수도 있습니다. 자세한 내용은 GitHub CLI 설명서의 “
gh repo edit”을 참조하세요.
권한 구성
권한은 ADO와 GitHub에서 다르게 작동하므로 GitHub Enterprise Importer는 ADO에서 리포지토리 권한을 마이그레이션하려고 시도하지 않습니다.
ADO2GH CLI를 사용한 경우 GitHub Enterprise Importer는 ADO의 각 팀 프로젝트에 대해 GitHub에 두 개의 팀을 만듭니다. 각 팀에는 팀 프로젝트에서 시작된 모든 리포지토리에 대해 다른 수준의 액세스 권한이 부여됩니다.
| 팀 | 마이그레이션된 리포지토리에 대한 액세스 |
|---|---|
| TEAM-PROJECT-Maintainers | 유지 관리자 |
| TEAM-PROJECT-Admins | 관리자 |
마이그레이션된 리포지토리에 대한 액세스 권한을 부여하려면 이러한 팀에 사용자를 추가할 수 있습니다. GitHub에서 수동으로 수행하거나 마이그레이션 중에 AAD(Azure Active Directory) 그룹에 팀을 연결하도록 선택한 경우 AAD에서 그룹 멤버 자격을 관리하여 이 작업을 수행할 수 있습니다. 팀 멤버 자격을 수동으로 관리하는 방법에 대한 자세한 내용은 "팀에 조직 멤버 추가.
ADO2GH CLI를 사용하지 않거나 이 기본값보다 고급인 권한 구성이 필요한 경우 마이그레이션된 리포지토리에 대한 권한을 구성합니다. 필요에 맞게 마이그레이션 스크립트를 수정하거나 마이그레이션 후 수동으로 권한을 구성할 수 있습니다. GitHub에서 리포지토리에 대한 액세스를 관리하는 방법에 대한 자세한 내용은 "조직의 리포지토리 역할.
- GitHub에 필요한 권한 구조를 결정합니다.
- 기본값과 다른 경우 팀 멤버 자격 및 사용 권한을 설정하기 위한 계획을 수립합니다.
마네킹 회수
GitHub Enterprise Importer을(를) 사용하여 마이그레이션을 실행한 후 마이그레이션된 리포지토리의 모든 사용자 활동(Git 커밋 제외)은 마네킹이라는 자리 표시자 ID에 기인합니다.
GitHub CLI을(를) 사용하여 특성 초대를 보내거나 브라우저에서 각 마네킹에 대한 기록을 조직 구성원에게 다시 적용할 수 있습니다. GitHub CLI을(를) 사용하는 경우 마네킹을 대량으로 회수할 수 있습니다. 자세한 내용은 "AUTOTITLE"을 참조하세요.
참고: organization 소유자만 마네킹을 회수할 수 있습니다. 마이그레이션자 역할이 부여된 경우 조직 소유자 문의하여 이 단계를 수행합니다.
- 마네킹을 회수할지 여부를 결정합니다.
- 회수를 완료할 시기를 계획합니다.
- 마네킹을 되찾습니다.
- 구성원 중 팀 멤버 자격을 통해 리포지토리에 대한 적절한 액세스 권한이 아직 없는 경우 구성원에게 리포지토리에 대한 액세스 권한을 부여합니다. 자세한 내용은 "조직 리포지토리에 대한 개인 액세스 권한 관리"을 참조하세요.
IP 허용 목록 구성
GitHub Enterprise Importer에 대한 IP 범위를 대상 조직의 IP 허용 목록에 추가한 경우 해당 항목을 제거할 수 있습니다. 대상 엔터프라이즈에 대한 ID 공급자의 IP 허용 목록 제한을 사용하지 않도록 설정한 경우 지금 다시 사용하도록 설정할 수 있습니다.
자세한 내용은 "GitHub Enterprise Importer에 대한 액세스 관리"을 참조하세요.