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

조직: 자주 묻는 질문

대형 SaaS 고객이 조직 수준에서 라이선스를 기대하는가요? 예를 들어 여러 최상위 그룹을 한 라이선스에 포함시키는 능력이 있는가요?

네, 이에 대해 Fulfillment와 논의되었으며, 이는 조직을 위한 MVP 로드맵의 일부입니다. 조직과 Fulfillment 간의 조정도 참조하세요.

조직에 대체 GitLab 도메인 이름을 구성할 수 있는 것을 기대하고 있나요(예: customer.gitlab.com)?

현재 이른 시일 내에 대체 GitLab 도메인 이름을 구성할 계획은 없습니다. 서브 도메인이 관리적인 어려움을 가져온다는 이전의 의견을 들은 적이 있습니다. 이 순간에는 GitLab Dedicated가 그에 훨씬 더 적합할 것입니다.

조직이 자체 가시성 설정(공개/비공개)을 가질 것으로 기대하고 있나요? 가시성은 최상위 그룹의 속성으로 유지될까요?

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

최상위 그룹에서 특정 기능을 조직으로 이관하는 것은 어떻게 보일까요?

우리의 요구 사항 중 하나는 모든 것을 조직에 매핑해야 한다는 것입니다. 이렇게만 하면 우리가 추구하는 격리를 달성할 수 있을 것입니다. SaaS의 경우, 모든 기존 그룹 및 프로젝트는 이미 백엔드에서 Org_ID = 1에 매핑되어 있습니다. Org_ID = 1은 기본 조직에 해당하며, 조직 롤아웃 시에 기존의 모든 그룹과 프로젝트가 기본 조직의 일부로 표시됩니다. 가능한 SaaS와 온프레미스 간에 최대한의 동등성을 추구하려고 하기 때문에 온프레미스 고객도 모든 것을 기본 조직에 매핑받게 됩니다. SaaS와 온프레미스의 차이점은 SaaS의 경우 사용자가 많은 조직을 생성할 것으로 예상되지만 온프레미스는 그렇지 않을 것이라는 것입니다. 우리는 can_create_organization 응용 프로그램 설정을 통해 이를 제어할 것입니다. 이 설정은 SaaS에 대해 기본적으로 활성화되고 온프레미스 사용자에 대해 기본적으로 비활성화될 것입니다.

귀하의 기능이 단계적으로 지원할 수 있는지 여부를 고려하십시오. 다시 말해, 기능이 충돌을 일으키지 않고 여러 중첩 수준에서 존재할 수 있는 기능인지를 고려해보세요. 귀하의 기능이 단계적으로 지원할 수 있다면:

• 현재, SaaS 및 온프레미스의 최상위 그룹에 기능을 추가해야 하며, 온프레미스의 경우 인스턴스에도 추가해야 합니다.
• 조직이 준비되면 인스턴스 수준의 기능을 조직 개체로 이관하게 되며, 그때부터 모든 고객을 위해 조직 및 최상위 그룹에서 이용할 수 있을 것입니다.

귀하의 기능이 단계적으로 지원할 수 없다면:

• 현재, SaaS에서는 최상위 그룹에만 기능을 추가해야 하고, 온프레미스에서는 인스턴스에 추가해야 합니다. 최상위 그룹 기능은 온프레미스 사용자에게는 숨겨져야 합니다.
• 조직이 준비되면 온프레미스 고객을 위해 인스턴스 기능을 조직으로 이관하지만, SaaS에서는 조직 수준에서 숨겨져야 합니다. SaaS에서는 사용자가 여전히 최상위 그룹에서 기능을 관리하고 조직 수준에서 관리하지 않을 것입니다. 미래에 대부분의 유료 고객이 자체 조직으로 이동하면, 모든 고객(SaaS 및 온프레미스)을 대상으로 중단 변경 사항을 도입하고 최상위 그룹에서 기능을 숨기고 조직 수준에서 제거할 수 있을 것입니다.