GitLab 그룹은 다음 방향으로 마이그레이션할 수 있습니다:

• GitLab Self-Managed 및 GitLab Dedicated에서 GitLab.com으로
• GitLab.com에서 GitLab Self-Managed 및 GitLab Dedicated로
• 한 GitLab Self-Managed 또는 GitLab Dedicated 인스턴스에서 다른 인스턴스로
• 동일한 GitLab 인스턴스 안에서

직접 전송 마이그레이션은 그룹의 새 사본을 만듭니다. 그룹을 복사하는 대신 이동하려면, 그룹이 같은 GitLab 인스턴스에 있는 경우 그룹을 이전할 수 있습니다. 마이그레이션보다 그룹 이전이 더 빠르고 더 완전한 방법입니다.

그룹은 다음 방법으로 마이그레이션할 수 있습니다:

• 직접 전송(권장).
• 대상 인스턴스가 소스 인스턴스와 직접 네트워크로 연결되지 않은 경우, 오브젝트 스토리지를 통한 오프라인 전송.
• 내보내기 파일 업로드.

GitLab.com에서 GitLab Self-Managed 또는 GitLab Dedicated 인스턴스로 마이그레이션하는 경우, 관리자가 해당 인스턴스에 사용자를 만들 수 있습니다.

GitLab Self-Managed와 GitLab Dedicated에서는 기본적으로 그룹 항목 마이그레이션을 사용할 수 없습니다. 이 기능을 표시하려면 관리자가 애플리케이션 설정에서 활성화합니다.

직접 전송으로 그룹을 마이그레이션하면 그룹이 한 위치에서 다른 위치로 복사됩니다. 다음을 할 수 있습니다:

• 여러 그룹을 한 번에 복사합니다.
• GitLab UI에서 최상위 그룹을 다음 위치로 복사합니다:
  • 다른 최상위 그룹.
  • 기존 최상위 그룹의 하위 그룹.
  • GitLab.com을 포함한 다른 GitLab 인스턴스.
• 직접 전송 방식 그룹 및 프로젝트 마이그레이션 API에서 최상위 그룹과 하위 그룹을 위 위치로 복사합니다.
• 프로젝트를 포함하거나 포함하지 않고 그룹을 복사합니다. 프로젝트를 포함한 그룹 복사는 GitLab.com에서 기본으로 제공됩니다.

모든 그룹 및 프로젝트 리소스가 복사되지는 않습니다. 복사되는 리소스 목록은 다음을 참고합니다:

• 마이그레이션되는 그룹 항목.
• 마이그레이션되는 프로젝트 항목.

마이그레이션을 시작한 뒤에는 소스 인스턴스에서 가져온 그룹이나 프로젝트를 변경하지 않아야 합니다. 변경 사항이 대상 인스턴스로 복사되지 않을 수 있기 때문입니다.

직접 전송 마이그레이션에 대한 의견은 피드백 이슈에 남길 수 있습니다.

특정 프로젝트 마이그레이션#

GitLab UI에서 직접 전송으로 그룹을 마이그레이션하면 그룹의 모든 프로젝트가 마이그레이션됩니다. 직접 전송으로 그룹 안의 특정 프로젝트만 마이그레이션하려면 API를 사용해야 합니다.

알려진 문제#

• 이슈 406685 때문에 파일 이름이 255자를 넘는 파일은 마이그레이션되지 않습니다.
• 소스 인스턴스에서 매핑될 때, 공유 멤버는 대상에 해당 멤버십이 이미 존재하지 않는 한 대상에서 직접 멤버로 매핑됩니다. 즉, 소스 인스턴스의 최상위 그룹을 대상 인스턴스의 최상위 그룹으로 가져오면, 소스 최상위 그룹이 필요한 공유 멤버십 계층 정보를 갖고 있더라도 프로젝트에서는 항상 직접 멤버로 매핑됩니다. 공유 멤버십의 완전한 매핑 지원은 이슈 458345에 제안돼 있습니다.
• GitLab 17.0, 17.1, 17.2에서는 가져온 에픽과 작업 항목이 원래 작성자가 아니라 가져오기를 실행한 사용자에게 매핑됩니다.
• 직접 전송은 서로 다른 소스 그룹의 그룹이나 프로젝트를 하나의 대상 그룹으로 통합하는 방식을 지원하지 않습니다. 그룹이나 프로젝트를 통합하려면 마이그레이션 전에 소스 인스턴스에서 구조를 재편하거나, 플레이스홀더 사용자 재배정이 끝난 뒤 대상 인스턴스에서 재편합니다. 이슈 589460을 참고합니다.
• 대상 네임스페이스가 소스와 다른 조직에 속하고 두 조직 중 하나가 격리로 표시돼 있으면, 직접 전송 마이그레이션이 실패합니다. 자세한 내용은 이슈 595674를 참고합니다.
• 직접 전송 마이그레이션은 기여를 대상 인스턴스의 차단 해제된 사용자에게 매핑하므로, 소스 인스턴스에서 숨겨져 있던 차단 사용자의 기여가 대상 인스턴스에서는 다시 나타납니다. 이러한 기여를 숨기려면 대상 인스턴스에서 다음 중 하나를 수행합니다:
  • 해당 사용자를 차단합니다.
  • 해당 기여를 제거합니다. 자세한 내용은 이슈 508111을 참고합니다.
• 마이그레이션 중 노트, 이슈 설명, 머지 리퀘스트 설명의 URL 참조는 마이그레이션 대상 그룹 또는 프로젝트(source_full_path)에 속한 링크에 대해서만 다시 작성됩니다. 소스 인스턴스의 다른 그룹이나 프로젝트를 가리키는 URL은 그 그룹이나 프로젝트가 함께 마이그레이션되더라도 다시 작성되지 않습니다. 마이그레이션 후에는 소스 인스턴스를 계속 가리키는 외부 링크를 직접 수정할 수 있습니다.

마이그레이션 기간 추정#

직접 전송 마이그레이션의 기간은 추정하기 어렵습니다. 마이그레이션 기간에는 다음 요소가 영향을 줍니다:

• 소스 및 대상 GitLab 인스턴스에서 사용할 수 있는 하드웨어와 데이터베이스 리소스. 소스와 대상 인스턴스의 리소스가 많을수록 마이그레이션 기간이 짧아질 수 있습니다. 이유는 다음과 같습니다:
  • 소스 인스턴스는 API 요청을 받아 내보낼 엔티티를 추출하고 직렬화합니다.
  • 대상 인스턴스는 job을 실행하고 자신의 데이터베이스에 엔티티를 만듭니다.
• 내보낼 데이터의 복잡도와 크기. 예를 들어 머지 리퀘스트가 각각 1,000개인 서로 다른 프로젝트 두 개를 마이그레이션한다고 가정합니다. 한 프로젝트의 머지 리퀘스트에 첨부 파일, 댓글 등 항목이 훨씬 많다면 두 프로젝트의 마이그레이션 시간은 크게 달라질 수 있습니다. 따라서 프로젝트의 머지 리퀘스트 수만으로는 마이그레이션 소요 시간을 제대로 예측할 수 없습니다.

마이그레이션을 정확히 추정하는 공식은 없습니다. 다만 프로젝트 을 가져오는 각 파이프라인 워커의 평균 소요 시간은 프로젝트 가져오기에 걸리는 시간을 가늠하는 데 도움이 됩니다.

여기서 relation은 내보낼 수 있는 항목의 한 유형입니다.

마이그레이션 기간은 예측하기 어렵지만, 다음과 같은 사례가 관측되었습니다:

• 프로젝트 100개(이슈 19.9천 개, 머지 리퀘스트 83천 개, 파이프라인 10만 개 이상)가 8시간 만에 마이그레이션되었습니다.
• 프로젝트 1,926개(이슈 22천 개, 머지 리퀘스트 16만 개, 파이프라인 110만 개)가 34시간 만에 마이그레이션되었습니다.

대규모 프로젝트를 마이그레이션하다가 타임아웃이나 마이그레이션 기간 문제가 발생하면 마이그레이션 기간 단축을 시도합니다.

제한#

기본 제한값은 직접 전송 마이그레이션 제한을 참고합니다.

다음 API로 최대 relation 크기 제한을 테스트할 수 있습니다:

• 그룹 relation 내보내기 API.
• 프로젝트 relation 내보내기 API

두 API 중 하나가 최대 relation 크기 제한보다 큰 파일을 만들면 직접 전송 그룹 마이그레이션이 실패합니다.

가시성 규칙#

마이그레이션 후에는 다음과 같이 동작합니다:

• 비공개 그룹과 프로젝트는 비공개로 유지됩니다.
• 내부 그룹과 프로젝트:
  • 내부 그룹으로 복사되면 내부 가시성이 제한되지 않는 한 내부로 유지됩니다. 제한된 경우에는 비공개가 됩니다.
  • 비공개 그룹으로 복사되면 비공개가 됩니다.
• 공개 그룹과 프로젝트:
  • 공개 그룹으로 복사되면 공개 가시성이 제한되지 않는 한 공개로 유지됩니다. 제한된 경우에는 내부가 됩니다.
  • 내부 그룹으로 복사되면 내부 가시성이 제한되지 않는 한 내부가 됩니다. 제한된 경우에는 비공개가 됩니다.
  • 비공개 그룹으로 복사되면 비공개가 됩니다.

소스 인스턴스에서 일반 공개로부터 콘텐츠를 숨기기 위해 사설 네트워크를 사용했다면, 대상 인스턴스에도 비슷한 구성을 마련하거나 비공개 그룹으로 가져옵니다.

직접 전송 마이그레이션 프로세스#

직접 전송으로 그룹 및 프로젝트 마이그레이션을 참고합니다.