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자보다 긴 파일은 마이그레이션되지 않습니다.
• GitLab 16.1 이전 버전에서는 직접 전송을 예약된 스캔 실행 정책과 함께 사용하지 않는 것이 좋습니다.
• GitLab 16.9 이전 버전에서는 이슈 438422로 인해 DiffNote::NoteDiffFileCreationError 오류가 나타날 수 있습니다. 이 오류가 발생하면 머지 리퀘스트 diff에 대한 노트의 diff가 누락되지만 노트와 머지 리퀘스트는 여전히 가져옵니다.
• 소스 인스턴스에서 매핑된 경우 공유 멤버는 해당 멤버십이 대상에 이미 존재하지 않는 한 대상에서 직접 멤버로 매핑됩니다. 즉, 소스 인스턴스의 최상위 그룹을 대상 인스턴스의 최상위 그룹으로 가져오면 소스 최상위 그룹에 필요한 공유 멤버십 계층 구조 세부 정보가 포함되어 있어도 항상 프로젝트의 직접 멤버로 매핑됩니다. 공유 멤버십의 전체 매핑 지원은 이슈 458345에서 제안되고 있습니다.
• GitLab 17.0, 17.1, 17.2에서 가져온 에픽과 작업 항목이 원래 작성자가 아닌 가져오는 사용자에게 매핑됩니다.
• 직접 전송은 다른 소스 그룹의 그룹이나 프로젝트를 단일 대상 그룹으로 통합하는 것을 지원하지 않습니다. 그룹이나 프로젝트를 통합하려면 마이그레이션 전에 소스 인스턴스에서 재구성하거나 플레이스홀더 사용자 재할당이 완료된 후 대상 인스턴스에서 재구성하세요. 이슈 589460 참조.

마이그레이션 기간 추정#

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

• 소스 및 대상 GitLab 인스턴스에서 사용 가능한 하드웨어 및 데이터베이스 리소스. 소스 및 대상 인스턴스의 더 많은 리소스는 더 짧은 마이그레이션 기간을 초래할 수 있습니다:
  • 소스 인스턴스는 API 요청을 수신하고 내보낼 엔티티를 추출하고 직렬화합니다.
  • 대상 인스턴스는 잡을 실행하고 데이터베이스에 엔티티를 만듭니다.
• 내보낼 데이터의 복잡성 및 크기. 예를 들어 각각 1000개의 머지 리퀘스트가 있는 두 개의 다른 프로젝트를 마이그레이션하려는 경우를 상상해보세요. 한 프로젝트의 머지 리퀘스트에 첨부 파일, 댓글 및 기타 항목이 훨씬 더 많다면 두 프로젝트를 마이그레이션하는 데 매우 다른 시간이 걸릴 수 있습니다. 따라서 프로젝트의 머지 리퀘스트 수는 프로젝트 마이그레이션에 걸리는 시간의 좋은 예측 지표가 아닙니다.

마이그레이션을 안정적으로 추정하는 정확한 공식은 없습니다. 그러나 프로젝트 을 가져오는 각 파이프라인 워커의 평균 기간은 프로젝트 가져오기에 걸리는 시간을 파악하는 데 도움이 됩니다.

이 컨텍스트에서 relation은 내보낼 수 있는 항목의 유형입니다.

마이그레이션 기간을 예측하기 어렵지만 다음이 관찰되었습니다:

• 100개의 프로젝트 (19.9k 이슈, 83k 머지 리퀘스트, 100k+ 파이프라인)가 8시간에 마이그레이션됨.
• 1926개의 프로젝트 (22k 이슈, 160k 머지 리퀘스트, 110만 파이프라인)가 34시간에 마이그레이션됨.

대규모 프로젝트를 마이그레이션하면서 타임아웃이나 마이그레이션 기간 문제가 발생하는 경우 마이그레이션 기간 단축을 시도하세요.

제한#

기본 제한은 직접 전송 마이그레이션 제한을 참조하세요.

다음 API를 사용하여 최대 relation 크기 제한을 테스트할 수 있습니다:

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

어느 API든 최대 relation 크기 제한보다 큰 파일을 생성하면 직접 전송에 의한 그룹 마이그레이션이 실패합니다.

가시성 규칙#

마이그레이션 후:

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

소스 인스턴스에서 일반 대중으로부터 콘텐츠를 숨기기 위해 사설 네트워크를 사용했다면 대상 인스턴스에도 유사한 설정이 있거나 비공개 그룹으로 가져오도록 하세요.

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

직접 전송을 사용하여 그룹 및 프로젝트 마이그레이션을 참조하세요.