Azure DevOps에서 GitHub Enterprise Cloud로 마이그레이션의 개요

계획에서 후속작업 완료 시행까지 GitHub Enterprise Importer을(를) 사용하여 Azure DevOps에서 GitHub(으)로 마이그레이션하는 전체 프로세스를 완료하는 방법을 알아보세요.

이 문서의 내용

개요

GitHub Enterprise Importer을(를) 사용하여 리포지토리별로 GitHub Enterprise Cloud(으)로 마이그레이션할 수 있습니다. 자세한 내용은 GitHub Enterprise Importer 정보을(를) 참조하세요.

Azure DevOps(ADO)에서 마이그레이션하는 경우 이 가이드를 사용하여 마이그레이션을 계획 및 구현하고, 후속작업을 완료할 수 있습니다.

ADO에서 GitHub(으)로 마이그레이션하는 엔터프라이즈는 일반적으로 다단계 접근 방식을 따릅니다.

  1. ADO에서 (으)로 파이프라인을 마이그레이션합니다.
  2. 보드 및 아티팩트와 같은 남은 자산을 ADO에서 GitHub(으)로 마이그레이션합니다.

이 가이드에서는 첫 번째 작업 단계를 완료하고, 리포지토리를 GitHub(으)로 마이그레이션하는 방법을 안내하며, ADO2GH extension of the GitHub CLI을(를) 사용하고 있다고 가정합니다.

마이그레이션 계획

마이그레이션을 계획하기 위해선, 다음 질문을 스스로에게 묻습니다.

마이그레이션을 얼마나 빨리 완료해야 합니까?

타임라인을 결정합니다. 이는 주로 접근 방식을 결정합니다. 타임라인을 결정하는 첫 번째 단계는 마이그레이션해야 하는 항목의 인벤토리를 가져오는 것입니다. 이 데이터를 수집하려면 GitHub CLI의 gh-repo-stats확장을 사용합니다. 이 오픈 소스 도구는 조직에 마이그레이션할 데이터양을 자세히 나타내는 보고서를 생성합니다.

Note

gh-repo-stats는 GitHub 지원에서 지원하지 않는 제3자 오픈 소스 도구입니다. 이 도구 에 대한 도움이 필요한 경우 해당 리포지토리에서 문제를 엽니다.

  • 리포지토리 수
  • 끌어오기 요청 수

마이그레이션 시기는 주로 리포지토리의 끌어오기 요청 수를 기반으로 합니다. 1,000개의 리포지토리를 마이그레이션하려는 경우 각 리포지토리에는 평균 100개의 끌어오기 요청이 있으며 50명의 사용자만 리포지토리에 기여한 경우 마이그레이션이 매우 빠를 수 있습니다. 100개의 리포지토리만 마이그레이션하려고 하지만 리포지토리에 각각 평균 75,000개의 끌어오기 요청과 5,000명의 사용자가 있는 경우 마이그레이션하는 데 시간이 훨씬 더 오래 걸리고 계획 및 테스트가 훨씬 더 많이 필요합니다.

분석기를 사용한 후에는, 원하는 타임라인에 대해 재고 데이터의 무게를 측정할 수 있습니다. 조직에서 더 높은 수준의 변화를 견딜 수 있는 경우, 모든 리포지토리를 한 번에 마이그레이션하여 며칠 안에 마이그레이션 작업을 완료할 수도 있습니다. 그러나 동시에 마이그레이션할 수 없는 다양한 팀 역시 있을 수 있습니다. 이 경우 팀의 타임라인에 맞게 마이그레이션을 일괄 처리하고 스테이징하여 마이그레이션 노력을 확장할 수 있습니다.

  1. GitHub CLI에 대한 gh-repo-stats확장을 사용한 다음 마이그레이션 인벤토리를 검토합니다.
  2. 팀이 마이그레이션할 준비가 된 시기를 이해하려면, 관련자를 인터뷰합니다.
  3. 이 가이드의 나머지 부분을 완전히 검토한 다음 마이그레이션 타임라인을 결정합니다.

Note

gh-repo-stats는 GitHub 지원에서 지원하지 않는 제3자 오픈 소스 도구입니다. 이 도구 에 대한 도움이 필요한 경우 해당 리포지토리에서 문제를 엽니다.

마이그레이션할 내용을 이해합니까?

귀하와 관련자가 GitHub Enterprise Importer에서 마이그레이션할 수 있는 데이터를 이해하도록 해야 합니다.

ADO에서 마이그레이션하는 경우 GitHub Enterprise Importer은(는) 끌어오기 요청 및 일부 분기 정책을 포함하여 Git 리포지토리만 마이그레이션합니다. 파이프라인, 작업 항목, 아티팩트, 테스트 계획, 해제 및 대시보드와 같은 다른 자산은 ADO에 남아 있을 것입니다.

권한은 GitHub에서 ADO와 다르게 작동하므로 GitHub Enterprise Importer은(는) ADO에서 리포지토리 권한을 마이그레이션하려고 시도하지 않습니다. 자세한 내용은 사용 권한 구성을 참조하세요.

서비스 후크는 ADO에서 마이그레이션되지 않으므로 별도로 다시 만들어야 합니다.

  1. Azure DevOps에서 마이그레이션된 데이터를 검토합니다. 자세한 내용은 Azure DevOps에서 GitHub Enterprise Cloud로 마이그레이션 정보을(를) 참조하세요.
  2. 수동으로 마이그레이션하거나 다시 생성해야 하는 데이터 목록을 만듭니다.

마이그레이션을 실행할 사람은 누구입니까?

리포지토리를 마이그레이션하려면 대상 조직의 조직 소유자 되거나 조직 소유자가 마이그레이션자 역할을 부여해야 합니다.

  1. 대상 조직의 조직 소유자가 마이그레이션을 수행하도록 할지, 다른 사람에게 마이그레이션자 역할을 부여해야 하는지 결정합니다.
  2. 마이그레이션자 역할을 부여하도록 선택한 경우, 역할을 부여할 사람 또는 팀을 결정합니다.
  3. 사용자 또는 팀에 마이그레이션자 역할을 부여합니다. 자세한 내용은 Azure DevOps에서 마이그레이션에 대한 액세스 관리을(를) 참조하세요.
  4. 사용자가 모든 액세스 요구 사항을 충족하도록 personal access token을(를) 올바르게 구성했는지 확인합니다. 자세한 내용은 Azure DevOps에서 마이그레이션에 대한 액세스 관리을(를) 참조하세요.

GitHub에서 원하는 조직 구조는 무엇입니까?

다음으로 GitHub에서 만들 조직 구조를 계획합니다. ADO 및 GitHub에는 엔터프라이즈 작업을 구성하는 다양한 방법이 있습니다.

  • ADO: 조직 > 팀 프로젝트 > 리포지토리
  • GitHub: 엔터프라이즈 > 조직 > 리포지토리

Note

ADO에서 리포지토리를 그룹화하는 데 사용되는 팀 프로젝트의 개념은 GitHub에 없습니다. GitHub의 조직을 ADO의 팀 프로젝트와 동등한 것으로 취급하지 않는 것이 좋습니다.

GitHub(으)로 마이그레이션한 후에는 엔터프라이즈 계정 하나만 있어야 하며 해당 엔터프라이즈에서 소수의 조직만 소유해야 합니다. ADO의 각 조직은 GitHub의 단일 조직에 해당해야 합니다. ADO의 각 팀 프로젝트에 대한 GitHub와 관련된 조직을 만들지 않는 것이 좋습니다.

이로 인해 각 조직 내에서 그룹화되지 않은 리포지토리의 큰 목록이 발생할 수 있습니다. 그러나 팀을 만들어 리포지토리 그룹에 대한 액세스를 관리할 수 있습니다. 자세한 내용은 팀 정보을(를) 참조하세요.

마이그레이션 활동을 일괄 처리로 중단하려는 경우 새 구조를 통해 일괄 처리를 결정할 수 있습니다. ADO에 둘 이상의 조직이 있고 각 조직의 리포지토리가 합리적으로 크기가 조정된 일괄 처리인 경우 조직별로 일괄 처리를 고려합니다. GitHub CLI을(를) 사용하여 ADO와 관련된 전체 조직에 대한 마이그레이션 스크립트를 생성할 수 있습니다.

  1. 새로운 조직 구조를 결정합니다.
  2. 마이그레이션 작업을 더 작은 일괄 처리로 분할해야 하는지에 대한 여부를 결정합니다.
  3. 그렇다면, 마이그레이션을 중단하는 방법을 결정합니다.

마이그레이션 실행

계획을 완료한 후에, 실제 마이그레이션을 시작할 수 있습니다. 마이그레이션 중 및 마이그레이션 후에 엔터프라이즈에 고유할 수 있는 문제를 발견할 수 있도록 모든 마이그레이션의 평가판 실행을 수행하는 것을 권장합니다. 평가판 실행에서 발견된 문제를 해결한 후 생산 마이그레이션을 실행할 수 있습니다.

평가판 마이그레이션은 몇 가지 중요한 정보를 발견하는 데 도움이 됩니다.

  • 지정된 리포지토리에 대한 마이그레이션이 성공적으로 완료될 수 있는지의 여부
  • 사용자가 리포지토리를 작업을 성공적으로 시작할 수 있는 상태로 되돌릴 수 있는지의 여부
  • 마이그레이션을 실행하는 데 걸리는 시간- 마이그레이션 일정을 계획하고 관련자의 기대치를 설정하는 데 유용합니다.

평가판 실행에는 시간 조정이 많이 필요하지 않습니다. GitHub Enterprise Importer은(는) 마이그레이션 중인 리포지토리의 사용자에게 가동 중지 시간이 필요하지 않습니다. 그러나 마이그레이션 중에 새 데이터가 생성되지 않도록 생산 마이그레이션 중에 작업을 중지하는 것이 좋습니다. 그러면 마이그레이션된 리포지토리에서 누락됩니다. 이는 평가판 마이그레이션에 대한 문제가 아니므로 평가판 실행은 언제든지 할 수 있습니다. 평가판 마이그레이션을 완료하는 데 걸리는 시간을 줄이기 위해 평가판 실행에 대한 배치를 다시 예약할 수 있습니다. 그런 다음, 해당 리포지토리의 사용자는 자신의 시간에 맞는 결과의 유효성을 검사할 수 있습니다.

평가판 마이그레이션의 대상으로 사용할 테스트 조직을 만드는 것이 좋습니다. 모든 평가판 실행에 단일 조직을 사용하거나, 의도한 각 대상 조직에 대해 하나의 테스트 조직을 만들 수 있습니다. 조직이 프로덕션이 아닌 마이그레이션 유효성 검사를 위한 것임을 명확히 하려면 조직 이름의 끝에 -sandbox을(를) 포함시키는 것이 좋습니다. 완료한 후, 테스트 조직을 삭제할 수 있습니다.

  1. 평가판 마이그레이션을 위한 테스트 조직을 만듭니다.
  2. 평가판 마이그레이션을 실행합니다.
  3. 평가판 마이그레이션을 위해 아래 설명된 후속 작업을 완료합니다.
  4. 사용자에게 마이그레이션 결과가 유효한지 검사하도록 요청합니다.
  5. 평가판 마이그레이션에서 발견한 문제를 해결합니다.
  6. 대상에서 IP 허용 목록을 사용하는 경우 GitHub Enterprise Importer의 액세스를 허용하도록 목록을 구성합니다. 자세한 내용은 Azure DevOps에서 마이그레이션에 대한 액세스 관리을(를) 참조하세요.
  7. 프로덕션 마이그레이션을 실행합니다. 자세한 내용은 Azure DevOps에서 GitHub Enterprise Cloud로 리포지토리 마이그레이션을(를) 참조하세요.
  8. 필요에 따라 테스트 조직을 삭제합니다.

후속 작업 완료

각 마이그레이션이 완료되면, 리포지토리가 작동할 준비가 되기 전에 몇 가지 추가 작업을 완료해야 합니다.

마이그레이션 상태 확인

먼저 마이그레이션이 성공했는지 실패했는지 확인합니다.

마이그레이션의 상태 검사 방법은 마이그레이션을 실행하는 방법에 따라 달라집니다.

  • GitHub CLI를 사용하여 마이그레이션을 실행한 경우 기본적으로 마이그레이션이 완료되면 마이그레이션이 성공했는지 아니면 실패했는지 여부가 프로세스에 표시됩니다. 마이그레이션에 실패한 경우 실패 이유가 표시됩니다.

    Migration completed (ID: RM_123)! State: SUCCEEDED

  • 선택적 --queue-only 인수와 함께 GitHub CLI를 사용하여 마이그레이션을 실행한 경우 마이그레이션을 대기한 직후 프로세스가 종료되고 마이그레이션이 성공했는지 또는 실패했는지는 알려주지 않습니다. wait-for-migration 명령을 사용하거나 마이그레이션 로그를 검토하여 마이그레이션의 상태 검사 수 있습니다.

  • GraphQL API를 사용하여 마이그레이션을 실행한 경우 RepositoryMigration 개체의 state 필드와 failureReason 필드를 쿼리할 수 있습니다.

마이그레이션에 실패한 경우 마이그레이션 로그에 오류의 원인에 대한 추가 정보가 포함될 수 있습니다. 자세한 내용은 "마이그레이션 로그 검토"를 참조하세요.

마이그레이션 로그 검토

마이그레이션된 각 리포지토리에 대한 마이그레이션 로그를 검토합니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션 로그 액세스"을(를) 참조하세요.

마이그레이션에 실패한 경우 로그에 오류의 원인에 대한 추가 정보가 포함될 수 있습니다.

마이그레이션에 성공하면 마이그레이션 로그에 마이그레이션되지 않았거나 주의해야 마이그레이션된 특정 데이터 조각(예: 끌어오기 요청, 문제 또는 주석)을 나타내는 경고가 표시될 수 있습니다.

마이그레이션 경고 이해에 대한 자세한 내용은 "GitHub Enterprise Importer를 사용하여 마이그레이션 문제 해결"을 참조하세요. 마이그레이션 경고를 검토한 후에는 해당 경고를 수락하고 계속 진행할지 결정해야 합니다.

리포지토리 표시 유형 설정

모든 리포지토리는 기본적으로 비공개로 마이그레이션되며 마이그레이션 및 조직 소유자가 실행한 사용자만 리포지토리에 액세스할 수 있습니다. 리포지토리를 비공개로 만들지 않기 위해선, 표시 유형을 변경합니다.

  • --target-repo-visibility CLI 옵션 또는 targetRepoVisibility GraphQL 속성을 사용하여 리포지토리의 표시 여부를 설정할 수 있습니다.
  • 브라우저에서 리포지토리의 표시 유형을 변경할 수 있습니다. 자세한 내용은 "리포지토리 표시 유형 설정"을(를) 참조하세요.
  • 또는 GitHub CLI을(를) 사용하여 명령줄에서 리포지토리 표시 유형을 변경할 수 있습니다. 마이그레이션을 실행하기 위해 생성된 스크립트에 이 명령을 추가할 수 있습니다. 자세한 내용은 GitHub CLI 설명서의 “gh repo edit”을 참조하세요.

사용 권한 구성

권한은 GitHub에서 ADO와 다르게 작동하므로 GitHub Enterprise Importer은(는) ADO에서 리포지토리 권한을 마이그레이션하려고 시도하지 않습니다.

ADO2GH CLI를 사용한 경우 GitHub Enterprise Importer은(는) ADO의 각 팀 프로젝트에 대한 GitHub에서 두 개의 팀을 만듭니다. 각 팀에는 팀 프로젝트에서 시작된 모든 리포지토리에 대해 다른 수준의 액세스 권한이 부여됩니다.

팀마이그레이션된 리포지토리에 대한 액세스
팀 프로젝트-유지관리자유지 관리자
팀 프로젝트-관리자관리자

마이그레이션된 리포지토리에 대한 액세스 권한을 부여하려면 이러한 팀에 구성원을 추가하시면 됩니다. GitHub에서 수동으로 이 작업을 수행하거나 마이그레이션 중에 Azure Active Directory(AAD) 그룹에 팀을 연결하도록 선택한 경우 AAD에서 그룹 멤버십을 관리하여 수동으로 이 작업을 수행하시면 됩니다. 팀 멤버십을 수동으로 관리하는 방법에 대한 자세한 내용은 팀에 조직 멤버 추가을(를) 참조하세요.

ADO2GH CLI를 사용하지 않거나 이 기본값보다 고급인 사용 권한 구성이 필요한 경우 마이그레이션된 리포지토리에 대한 사용 권한을 구성합니다. 필요에 맞게 마이그레이션 스크립트를 수정하거나 마이그레이션 후 수동으로 사용 권한을 구성할 수 있습니다. GitHub에서 리포지토리에 대한 액세스를 관리하는 방법에 대한 자세한 내용은 조직의 리포지토리 역할을(를) 참조하세요.

  1. GitHub에 필요한 사용 권한 구조를 결정합니다.
  2. 기본값과 다른 경우 팀 멤버십 및 사용 권한을 설정하는 계획을 세워야 합니다.

마네킹 회수

GitHub Enterprise Importer을(를) 사용하여 마이그레이션을 실행하면, 마이그레이션된 리포지토리의 모든 사용자 활동(Git 커밋 제외)은 마네킹이라는 자리 표시자 ID에 기인합니다.

GitHub CLI을(를) 사용하거나 브라우저에서 각 마네킹의 기록을 조직 구성원에게 다시 배포할 수 있습니다. GitHub CLI을(를) 사용하는 경우 마네킹을 대량으로 회수할 수 있습니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마네킹 회수"을 참조하세요.

Note

조직 소유자만이 마네킹을 회수할 수 있습니다. 마이그레이션자 역할이 부여된 경우, 조직 소유자에게 문의하여 이 단계를 수행합니다.

  1. 마네킹을 회수할지에 대한 여부를 결정합니다.
  2. 회수를 완료할 때를 계획합니다.
  3. 마네킹을 회수합니다.
  4. 구성원 중 팀 멤버 자격을 통해 리포지토리에 대한 적절한 액세스 권한이 아직 없는 경우, 구성원에게 리포지토리에 대한 액세스 권한을 부여합니다. 자세한 내용은 "조직 리포지토리에 대한 개인 액세스 권한 관리" 항목을 참조하세요.

IP 허용 목록 구성

GitHub Enterprise Importer에 대한 IP 범위를 대상 조직의 IP 허용 목록에 추가한 경우 해당 항목을 제거할 수 있습니다. 대상 엔터프라이즈에 대한 ID 공급자의 IP 허용 목록 제한을 사용하지 않도록 설정했을 경우, 지금 다시 사용하도록 설정할 수 있습니다.

자세한 내용은 Azure DevOps에서 마이그레이션에 대한 액세스 관리을(를) 참조하세요.