• 대규모 SaaS 고객이 조직 수준에서 라이선스를 예상하는가, 즉 여러 최상위 그룹을 하나의 라이선스에 포함시킬 수 있는 능력이 있는가?
• 조직에 대체 GitLab 도메인 이름을 구성할 수 있는지 예상하는가 (예: customer.gitlab.com)?
• 조직이 자체 가시성 설정(공개/비공개)을 가질 것으로 예상하는가? 가시성은 최상위 그룹의 속성으로 유지될 것인가?
• 최상위 그룹에서 조직으로 기능을 이전하는 것은 어떻게 될 것인가?

조직: 자주 묻는 질문

대규모 SaaS 고객이 조직 수준에서 라이선스를 예상하는가, 즉 여러 최상위 그룹을 하나의 라이선스에 포함시킬 수 있는 능력이 있는가?

네, 이것은 이행팀과 논의되었으며 조직에 대한 MVC 로드맵의 일부입니다. 자세한 내용은 조직과 이행 간의 일치를 참조하세요.

조직에 대체 GitLab 도메인 이름을 구성할 수 있는지 예상하는가 (예: customer.gitlab.com)?

현재 이 시점에서 대체 GitLab 도메인 이름을 구성할 계획은 없습니다. 이전에 하위 도메인이 관리적인 도전을 가져온다는 것을 들었었습니다. 현재 GitLab Dedicated가 그에 더 나은 적합이 될 것입니다.

조직이 자체 가시성 설정(공개/비공개)을 가질 것으로 예상하는가? 가시성은 최상위 그룹의 속성으로 유지될 것인가?

조직은 현재 공개 상태이지만 자체 독립적인 가시성 설정을 갖게 될 것입니다. 자세한 내용은 사용자가 조직을 볼 수 있는 경우도 참조하세요.

최상위 그룹에서 조직으로 기능을 이전하는 것은 어떻게 될 것인가?

우리의 요구 사항 중 하나는 모든 것이 조직에 매핑되어야 한다는 것입니다. 오직 그렇게 함으로써 우리가 노력하는 격리를 달성할 수 있을 것입니다. SaaS의 경우, 모든 기존 그룹과 프로젝트는 이미 백엔드에서 Org_ID = 1에 매핑되어 있습니다. Org_ID = 1은 기본 조직(Default Organization)을 의미하며, 조직 롤아웃 후에는 모든 기존 그룹과 프로젝트가 기본 조직의 일부로 표시될 것입니다. 우리는 자체 호스팅 고객도 가능한 한 SaaS와 유사하도록 하고 싶어합니다. 자체 호스팅의 경우 사용자가 많은 조직을 만들 것으로 기대하지 않으며, 우리는 그렇게 하지 않을 것입니다. 우리는 SaaS에서 사용자가 많은 조직을 만들 것으로 기대하며, 자체 호스팅 사용자는 그렇게 하지 않을 것으로 예상하고 있습니다. 우리는 can_create_organization 애플리케이션 설정을 통해 이를 제어할 것이며, 이 설정은 SaaS에는 기본적으로 활성화되고, 자체 호스팅 사용자에게는 기본적으로 비활성화될 것입니다.

당신의 기능이 계층 지원을 지원할 수 있는지, 다시 말해 기능이 충돌을 일으키지 않고 여러 중첩된 수준에 존재할 수 있는지 고려하십시오. 만약 당신의 기능이 계층을 지원할 수 있는 경우:

• 오늘, 당신은 SaaS와 자체 호스팅을 위해 최상위 그룹에 기능을 추가해야 하며, 자체 호스팅을 위해 인스턴스에도 추가해야 합니다.
• 조직이 준비되면, 당신은 인스턴스 수준의 기능을 조직 개체로 이전하여 모든 고객을 위해 조직 및 최상위 그룹에서 사용할 수 있도록 할 것입니다.

만약 당신의 기능이 계층을 지원할 수 없는 경우:

• 오늘, 당신은 SaaS를 위해 최상위 그룹에 기능을 추가해야 하며, 자체 호스팅을 위해 인스턴스에 추가해야 합니다. 최상위 그룹 기능은 자체 호스팅 사용자에게 숨겨질 것입니다.
• 조직이 준비되면, 당신은 자체 호스팅 사용자를 위해 인스턴스 기능을 조직으로 이전하지만, SaaS의 경우 조직 수준에서는 숨길 것입니다. SaaS의 경우, 사용자는 계속해서 최상위 그룹에서 기능을 관리하게 되며, 조직 수준이 아닙니다. 미래에 대부분의 유료 고객이 자체 조직으로 이동했을 때, 당신은 파괴적인 변경을 도입하여 SaaS 및 자체 호스팅 모든 고객을 대상으로 조직 수준에서 숨긴 기능을 해제할 수 있으며, 최상위 그룹에서 기능을 제거할 수 있게 될 것입니다.