마이그레이션 후 기여 및 멤버십 매핑
GitLab v19.4Offering: GitLab Self-Managed, GitLab Dedicated
요약
마이그레이션 후 매핑을 사용하면 원본 인스턴스의 사용자 기여와 멤버십이 대상 인스턴스의 실제 사용자가 아니라 플레이스홀더 사용자에게 먼저 할당됩니다. 실제 사용자로의 할당을 미룰 수 있으므로 가져오기 결과를 검토한 뒤 올바른 사용자에게 기여를 재할당할 시간을 확보할 수 있습니다.
히스토리
importer_user_mapping과bulk_import_importer_user_mapping이라는 기능 플래그와 함께 GitLab 17.4에서 직접 전송용으로 도입되었습니다. 기본적으로 비활성화되어 있습니다.- GitLab 17.6에서
importer_user_mapping과gitea_user_mapping이라는 기능 플래그와 함께 Gitea 용으로,importer_user_mapping과github_user_mapping이라는 플래그와 함께 GitHub 용으로 도입되었습니다. 기본적으로 비활성화되어 있습니다. importer_user_mapping과bitbucket_server_user_mapping이라는 기능 플래그와 함께 GitLab 17.7에서 Bitbucket Server 용으로 도입되었습니다. 기본적으로 비활성화되어 있습니다.- GitLab 17.7에서 직접 전송용으로 GitLab.com 및 GitLab Self-Managed에 활성화되었습니다.
- GitLab 17.7에서 Bitbucket Server, Gitea, GitHub 용으로 GitLab.com에 활성화되었습니다.
- GitLab 17.8에서 Bitbucket Server, Gitea, GitHub 용으로 GitLab Self-Managed에 활성화되었습니다.
- 개인 네임스페이스로 가져올 때 기여를 개인 네임스페이스 소유자에게 재할당하는 기능이
user_mapping_to_personal_namespace_owner라는 기능 플래그와 함께 GitLab 18.3에서 도입되었습니다. 기본적으로 비활성화되어 있습니다. - GitLab 18.4에서 직접 전송용으로 일반 공개되었습니다. 기능 플래그
bulk_import_importer_user_mapping이 제거되었습니다. - 서비스 계정, 프로젝트 봇, 그룹 봇에 기여를 재할당하는 기능이
- GitLab 18.6에서 Gitea 용으로 일반 공개되었습니다. 기능 플래그
- 개인 네임스페이스로 가져올 때 기여를 개인 네임스페이스 소유자에게 재할당하는 기능이 GitLab 18.6에서 일반 공개되었습니다. 기능 플래그
user_mapping_to_personal_namespace_owner가 제거되었습니다. github_user_mapping기능 플래그가 GitLab 18.8에서 제거되었습니다.user_mapping_service_account_and_bots기능 플래그가 GitLab 18.10에서 제거되었습니다.
마이그레이션 후 매핑을 사용하면 원본 인스턴스의 사용자 기여와 멤버십이 대상 인스턴스의 실제 사용자가 아니라 플레이스홀더 사용자에게 먼저 할당됩니다.
실제 사용자로의 할당을 미룰 수 있으므로 가져오기 결과를 검토한 뒤 올바른 사용자에게 기여를 재할당할 시간을 확보할 수 있습니다. 이 과정을 통해 매핑을 통제하면서도 기여자를 정확히 표시할 수 있습니다.
마이그레이션 후 사용자 기여 및 멤버십 매핑은 다음 원본에서 마이그레이션할 때 기본적으로 사용할 수 있습니다.
프로젝트를 개인 네임스페이스로 가져오면 사용자 기여 매핑과 멤버십 매핑이 지원되지 않으며 모든 기여가 개인 네임스페이스 소유자에게 할당됩니다. 이렇게 할당된 기여는 재할당할 수 없습니다.
사전 요구 사항#
- 사용자 제한에 따라 사용자 수를 계획합니다.
- GitLab.com으로 가져오는 경우 유료 네임스페이스를 설정합니다.
- GitLab.com으로 가져오면서 GitLab.com 그룹용 SAML SSO를 사용하는 경우, 모든 사용자가 자신의 SAML ID를 GitLab.com 계정에 연결하도록 합니다.
마이그레이션 후 매핑 워크플로#
마이그레이션 후 매핑을 사용하면 GitLab 이 가져온 멤버십과 기여를 모두 플레이스홀더 사용자에 매핑합니다. 대상 인스턴스에 같은 이메일 주소를 가진 사용자가 있더라도 플레이스홀더 사용자는 대상 인스턴스에 생성됩니다. 대상 인스턴스에서 기여를 재할당하기 전까지 모든 기여는 플레이스홀더 사용자와 연결됩니다.
가져오기가 완료되고 결과를 검토한 뒤에는 다음과 같이 매핑을 갱신할 수 있습니다.
- 멤버십과 기여를 대상 인스턴스의 기존 사용자에게 재할당합니다. 원본 인스턴스와 대상 인스턴스에서 이메일 주소가 다른 사용자의 멤버십과 기여도 매핑할 수 있습니다.
- 대상 인스턴스에 새 사용자를 만들고 멤버십과 기여를 그 사용자에게 재할당합니다.
과거 컨텍스트를 보존하기 위해 일부 기여는 플레이스홀더 사용자에게 할당된 상태로 둘 수도 있습니다.
대상 인스턴스의 사용자에게 기여를 재할당하면 해당 사용자는 다음 중 하나를 선택할 수 있습니다.
- 재할당을 수락합니다. 재할당 처리에는 몇 분이 걸릴 수 있습니다. 이후 같은 원본 인스턴스에서 대상 인스턴스의 같은 최상위 그룹이나 하위 그룹으로 가져올 때는 기여가 해당 사용자에게 자동으로 매핑됩니다.
- 재할당을 거부합니다.
엔터프라이즈 사용자#
히스토리
- GitLab 18.0에서 도입되었습니다.
최상위 그룹에 엔터프라이즈 사용자가 한 명 이상 있으면 조직 내 엔터프라이즈 사용자에게만 기여를 재할당할 수 있습니다.
따라서 조직 외부 사용자에게 실수로 재할당하는 일이 발생하지 않습니다.
삭제된 사용자#
원본 인스턴스에서 지금은 삭제된 사용자가 남긴 기여는 대상 인스턴스에서 고스트 사용자에 매핑됩니다. 다만 다음 경우는 예외입니다.
- 원본 인스턴스에서 해당 기여가 삭제된 사용자로부터 제대로 분리되지 않은 경우
- Bitbucket Server에서 마이그레이션하는 경우
플레이스홀더 사용자#
기여 및 멤버십 매핑을 사용하면 기여와 멤버십이 대상 인스턴스의 사용자에게 곧바로 할당되지 않습니다. 대신 기여나 멤버십을 가져온 활성, 비활성, 봇 사용자마다 플레이스홀더 사용자가 생성됩니다.
기여와 멤버십은 모두 이 플레이스홀더 사용자에게 먼저 할당되며, 가져오기 후에 대상 인스턴스의 기존 사용자에게 재할당할 수 있습니다.
재할당하기 전까지 기여는 플레이스홀더와 연결됩니다. 플레이스홀더 멤버십은 구성원 목록에 표시되지 않습니다.
플레이스홀더 사용자는 라이선스 한도에 포함되지 않습니다.
예외#
다음 경우에는 플레이스홀더 사용자가 생성되지 않습니다.
- 삭제된 사용자의 기여가 포함된 프로젝트를 Gitea에서 가져오는 경우. 이런 사용자의 기여는 프로젝트를 가져온 사용자에게 매핑됩니다.
- 플레이스홀더 사용자 제한을 초과한 경우. 새 사용자의 기여는 모두 import 사용자에게 매핑됩니다.
플레이스홀더 사용자 속성#
플레이스홀더 사용자는 일반 사용자와 달라서 다음 작업을 할 수 없습니다.
- 로그인
- 파이프라인 실행 등 모든 작업 수행
- 이슈와 머지 리퀘스트의 담당자나 리뷰어 추천 목록에 표시
- 프로젝트와 그룹의 구성원 등록
원본 인스턴스의 사용자와의 연결을 유지하기 위해 플레이스홀더 사용자는 다음 정보를 가집니다.
- 새 플레이스홀더 사용자가 필요한지 가져오기 과정에서 판단하는 데 사용하는 고유 식별자(
source_user_id) - 원본 호스트명 또는 도메인(
source_hostname) - 기여 재할당에 도움이 되는 원본 사용자 이름(
source_name) - 기여를 재할당할 때 그룹 소유자를 돕는 원본 사용자의 사용자명(
source_username) - 어느 가져오기 도구가 플레이스홀더를 생성했는지 구분하는 가져오기 유형(
import_type) - 마이그레이션 추적을 위해 현지 시간으로 기록된 원본 사용자 생성 시각(
created_at) (GitLab 17.10에서 도입)
과거 컨텍스트를 보존하기 위해 플레이스홀더 사용자의 이름과 사용자명은 원본 사용자의 이름과 사용자명에서 파생됩니다.
- 플레이스홀더 사용자의 이름은
Placeholder <source user name>입니다. - 플레이스홀더 사용자의 사용자명은
%{source_username}_placeholder_user_%{incremental_number}입니다.
플레이스홀더 사용자 보기#
사전 요구 사항:
- 그룹의 Owner 권한이 있어야 합니다.
플레이스홀더 사용자는 그룹이나 프로젝트를 가져오는 동안 대상 인스턴스에 생성됩니다. 최상위 그룹과 그 하위 그룹으로 가져오는 동안 생성된 플레이스홀더 사용자를 보려면 다음 단계를 수행합니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다. 이 그룹은 최상위 그룹이어야 합니다.
- 왼쪽 사이드바에서 Manage > Members를 선택합니다.
- Placeholders 탭을 선택합니다.
플레이스홀더 사용자 필터링#
히스토리
- GitLab 17.11에서 도입되었습니다.
사전 요구 사항:
- 인스턴스에 대한 관리자 접근 권한이 있어야 합니다.
플레이스홀더 사용자는 그룹이나 프로젝트를 가져오는 동안 대상 인스턴스에 생성됩니다. 인스턴스 전체에서 가져오기 중 생성된 플레이스홀더 사용자를 필터링하려면 다음 단계를 수행합니다.
- 오른쪽 상단에서 Admin을 선택합니다.
- 왼쪽 사이드바에서 Overview > Users를 선택합니다.
- 검색 상자에서 type으로 사용자를 필터링합니다.
플레이스홀더 사용자 생성#
플레이스홀더 사용자는 가져오기 원본별, 최상위 그룹별로 생성됩니다.
- 같은 프로젝트를 대상 인스턴스의 같은 최상위 그룹으로 두 번 가져오면 두 번째 가져오기는 첫 번째 가져오기와 같은 플레이스홀더 사용자를 사용합니다.
- 같은 프로젝트를 대상 인스턴스의 다른 최상위 그룹으로 두 번 가져오면 두 번째 가져오기는 해당 최상위 그룹 아래에 새 플레이스홀더 사용자를 생성합니다.
플레이스홀더 사용자는 최상위 그룹에만 연결됩니다. 하위 그룹이나 프로젝트를 삭제하면 해당 플레이스홀더 사용자는 최상위 그룹의 어떤 기여도 더 이상 참조하지 않습니다. 테스트할 때는 지정된 최상위 그룹을 사용하는 것이 좋습니다. 플레이스홀더 사용자 삭제는 이슈 519391과 이슈 537340에서 제안되어 있습니다.
사용자가 재할당을 수락하면, 같은 원본 인스턴스에서 대상 인스턴스의 같은 최상위 그룹이나 하위 그룹으로 이후에 가져올 때는 플레이스홀더 사용자가 생성되지 않습니다. 대신 기여가 해당 사용자에게 자동으로 매핑됩니다.
플레이스홀더 사용자 삭제#
히스토리
- GitLab 18.0에서 도입되었습니다.
플레이스홀더 사용자가 포함된 최상위 그룹을 삭제하면 해당 사용자는 자동으로 제거 대상으로 예약됩니다. 이 과정은 완료까지 시간이 걸릴 수 있습니다. 다만 플레이스홀더 사용자가 다른 프로젝트나 그룹에도 연결되어 있으면 시스템에 그대로 남습니다.
플레이스홀더 사용자 제한#
GitLab.com으로 가져오는 경우 플레이스홀더 사용자는 대상 인스턴스의 최상위 그룹별로 제한됩니다. 제한은 플랜과 시트 수에 따라 다릅니다. 플레이스홀더 사용자는 라이선스 한도에 포함되지 않습니다.
| GitLab.com 플랜 | 시트 수 | 최상위 그룹의 플레이스홀더 사용자 제한 |
|---|---|---|
| Free 및 모든 트라이얼 | 모든 수량 | 200 |
| Premium | < 100 | 500 |
| Premium | 101-500 | 2000 |
| Premium | 501 - 1000 | 4000 |
| Premium | > 1000 | 6000 |
| Ultimate 및 오픈 소스 | < 100 | 1000 |
| Ultimate 및 오픈 소스 | 101-500 | 4000 |
| Ultimate 및 오픈 소스 | 501 - 1000 | 6000 |
| Ultimate 및 오픈 소스 | > 1000 | 8000 |
GitLab Self-Managed와 GitLab Dedicated에서는 기본적으로 플레이스홀더 제한이 적용되지 않습니다. GitLab 관리자가 자신의 인스턴스에 플레이스홀더 제한을 설정할 수 있습니다.
현재 플레이스홀더 사용자 사용량과 제한을 보려면 다음 단계를 수행합니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다. 이 그룹은 최상위 그룹이어야 합니다.
- Settings > Usage quotas를 선택합니다.
- Import 탭을 선택합니다.
필요한 플레이스홀더 사용자 수는 미리 산정할 수 없습니다.
플레이스홀더 사용자 제한에 도달하면 모든 기여가
Import User라는 기능하지 않는 단일 사용자에게 할당됩니다.
Import User에게 할당된 기여는 중복이 제거될 수 있으며,
일부 기여는 가져오기 중에 생성되지 않을 수 있습니다.
예를 들어 머지 리퀘스트 승인자의 승인 여러 건이 Import User에게 할당되면
첫 번째 승인만 생성되고 나머지는 무시됩니다.
중복이 제거될 수 있는 기여는 다음과 같습니다.
- 승인 규칙
- 이모지 반응
- 이슈 담당자
- 멤버십
- 머지 리퀘스트 승인, 담당자, 리뷰어
- 푸시, 머지 리퀘스트, 배포 접근 수준
모든 변경은 시스템 노트를 생성하며, 시스템 노트는 플레이스홀더 사용자 제한의 영향을 받지 않습니다.
대체 매핑 방법#
마이그레이션 후 매핑 대신 마이그레이션 중에 매핑하는 방법도 있습니다. 이 방법은 권장하지 않으며, 문제가 발견되어도 수정되지 않을 가능성이 높습니다.
대체 매핑 방법은 다음과 같은 특징이 있습니다.
- GitLab Self-Managed 로의 마이그레이션에서만 사용할 수 있습니다.
- 해당하는
*_user_mapping기능 플래그 비활성화를 포함해 마이그레이션 전 준비가 필요합니다. - 다음 원본에서의 마이그레이션에 사용할 수 있습니다.
- GitHub
- Bitbucket Server
- Gitea(GitLab 18.5 이하)
자세한 내용은 각 가져오기 도구의 대체 매핑 방법 문서를 참고합니다.