4단계. Azure DevOps에서 GitHub로 마이그레이션 준비

얼마나 마이그레이션해야 하는 양을 결정합니다.

타임라인을 결정합니다. 이는 주로 접근 방식을 결정합니다. 타임라인을 결정하는 첫 번째 단계는 마이그레이션해야 하는 항목의 인벤토리를 가져오는 것입니다.

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

          `inventory-report` 명령을 ADO2GH extension of the GitHub CLI에서 사용하는 것이 좋습니다. 이 명령은 Azure DevOps API와 연결한 다음, 여러 CSV 파일을 만듭니다. 
          `repos.csv` 에는 끌어오기 요청 수를 포함하여 리포지토리에 대한 정보가 포함되어 있습니다.

CSV 파일을 생성하려면 다음 명령어를 사용하고 YOUR_ADO_ORG를 Azure DevOps에서 귀하의 조직 이름으로 변경하십시오.

gh ado2gh inventory-report --ado-org YOUR_ADO_ORG

gh ado2gh inventory-report --ado-org YOUR_ADO_ORG

마이그레이션해야 하는 리포지토리의 인벤토리를 가져와 원하는 타임라인과 비교할 때 인벤토리 데이터의 무게를 측정합니다.

• 조직에서 더 높은 수준의 변화를 견딜 수 있는 경우, 모든 리포지토리를 한 번에 마이그레이션하여 며칠 안에 마이그레이션 작업을 완료할 수도 있습니다.
• 동시에 마이그레이션할 수 없는 팀이 있는 경우 마이그레이션을 일괄 처리하고 팀의 타임라인에 맞게 스테이거하여 마이그레이션 노력을 확장할 수 있습니다.

GitHub 조직 구조 결정

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

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

GitHub로 마이그레이션한 후에는 엔터프라이즈 계정 하나만 있어야 하며 해당 엔터프라이즈에서 소수의 조직만 소유해야 합니다. ADO의 각 조직은 GitHub의 단일 조직에 해당해야 합니다.

마이그레이션 작업을 일괄 처리로 중단하려는 경우 새 구조가 이를 확인하는 데 도움이 될 수 있습니다. ADO에 둘 이상의 조직이 있고 각 조직의 리포지토리가 합리적으로 크기가 조정된 일괄 처리인 경우 조직별로 일괄 처리를 고려합니다.

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

리포지토리 권한 구성

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

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

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

다음 단계:

다음 단계에서는 시험 실행을 수행한 다음 리포지토리를 마이그레이션합니다. 5단계. Azure DevOps에서 Github로 리포지토리 마이그레이션을(를) 참조하세요.