이 버전의 GitHub Enterprise는 다음 날짜에 중단되었습니다. 2024-03-26. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

Bitbucket Server에서 GitHub Enterprise Cloud로 마이그레이션의 개요

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

이 문서의 내용

개요

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

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

마이그레이션 계획

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

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

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

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

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

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

  1. 마이그레이션해야 하는 리포지토리 및 끌어오기 요청의 수를 결정합니다.
  2. 팀이 마이그레이션할 준비가 된 시기를 이해하려면 관련자를 인터뷰하세요.
  3. 이 가이드의 나머지 부분을 완전히 검토한 다음 마이그레이션 타임라인 결정합니다.

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

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

Bitbucket Server에서 마이그레이션하는 경우 GitHub Enterprise Importer은(는) Git 리포지토리 및 끌어오기 요청만 마이그레이션합니다. CI 파이프라인과 같은 다른 모든 자산은 Bitbucket Server에 유지됩니다.

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

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

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

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

필요한 권한과 Bitbucket Server 인스턴스에 대한 액세스 권한도 있어야 합니다.

  • 관리자 또는 슈퍼 관리자 권한
  • Bitbucket Server 인스턴스가 Linux를 실행하는 경우 SFTP은 지원되는 SSH 프라이빗 키를 사용하여 인스턴스에 액세스합니다("Bitbucket 서버에서 마이그레이션에 대한 액세스 관리" 참조)
  • Bitbucket Server 인스턴스가 Windows를 실행하는 경우 파일 공유(SMB)가 인스턴스에 액세스합니다
  1. 대상 조직의 조직 소유자가 마이그레이션을 수행할지 또는 다른 사람에게 마이그레이션자 역할을 부여해야 할지를 결정합니다.
  2. 마이그레이션자 역할을 부여하도록 선택한 경우, 역할을 부여할 사람 또는 팀을 결정합니다.
  3. 사용자 또는 팀에 마이그레이션자 역할을 부여합니다. 자세한 내용은 "Bitbucket 서버에서 마이그레이션에 대한 액세스 관리"을 참조하세요.
  4. 사용자가 모든 액세스 요구 사항을 충족하도록 personal access token을(를) 올바르게 구성했는지 확인합니다. 자세한 내용은 "Bitbucket 서버에서 마이그레이션에 대한 액세스 관리"을 참조하세요.
  5. 마이그레이션자에게 Bitbucket Server 인스턴스에 대한 관리자 또는 슈퍼 관리자 권한 및 SFTP 액세스 권한이 있는지 확인합니다.

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

다음으로 GitHub에서 만들 조직 구조를 계획합니다.

Bitbucket Server에서 리포지토리는 프로젝트로 그룹화됩니다. GitHub에서 조직이 리포지토리를 소유합니다. 그러나 가장 좋은 방법이 Bitbucket Server의 프로젝트당 GitHub에 하나의 조직을 만드는 것이라고 가정해서는 안 됩니다.

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

마이그레이션된 각 리포지토리는 이러한 조직 중 하나에 따라 소유되므로 각 조직 내에서 그룹화되지 않은 리포지토리의 큰 목록이 발생할 수 있습니다. 그러나 GitHub의 팀을 만들어 리포지토리 그룹에 대한 액세스를 관리할 수 있습니다. 자세한 내용은 "팀 정보"을(를) 참조하세요.

마이그레이션 활동을 일괄 처리로 중단하려면 조직별 일괄 처리를 고려하세요.

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

마이그레이션 실행

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

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

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

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

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

  1. 평가판 마이그레이션을 위한 테스트 조직을 만듭니다.
  2. 평가판 마이그레이션을 실행합니다.
  3. 평가판 마이그레이션을 위해 아래 설명된 후속 작업을 완료합니다.
  4. 사용자에게 마이그레이션 결과가 유효한지 검사하도록 요청합니다.
  5. 평가판 마이그레이션에서 발견한 문제를 해결합니다.
  6. 대상에서 IP 허용 목록을 사용하는 경우 GitHub Enterprise Importer의 액세스를 허용하도록 목록을 구성합니다. 자세한 내용은 "Bitbucket 서버에서 마이그레이션에 대한 액세스 관리"을 참조하세요.
  7. 프로덕션 마이그레이션을 실행합니다. 자세한 내용은 "Bitbucket Server에서 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를 사용하여 마이그레이션 문제 해결"을 참조하세요. 마이그레이션 경고를 검토한 후에는 해당 경고를 수락하고 계속 진행할지 결정해야 합니다.

리포지토리 표시 유형 설정

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

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

사용 권한 구성

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

마이그레이션된 리포지토리에 대한 액세스 권한을 부여하려면 팀을 만들고 각 팀에 리포지토리에 대한 액세스 권한을 부여하시면 됩니다.

  1. 팀을 만듭니다. 자세한 내용은 "팀 만들기"을(를) 참조하세요.
  2. 팀에 조직 구성원을 추가합니다. 자세한 내용은 "팀에 조직 멤버 추가"을(를) 참조하세요.
  3. 각 팀에 리포지토리에 대한 액세스 권한을 부여합니다. 자세한 내용은 "조직 리포지토리에 대한 팀 액세스 관리"을(를) 참조하세요.

마네킹 회수

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

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

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

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

IP 허용 목록 구성

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

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