| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
- 대형 SaaS 고객이 조직 수준에서 라이선스를 받을 것으로 예상하는가, 예를 든다면 하나의 라이선스 아래에서 여러 최상위 그룹을 포함하는 능력을 가질 것으로 예상하는가?
- 조직에 대체 GitLab 도메인 이름(예:
customer.gitlab.com)을 구성할 수 있는 것으로 예상하는가? - 조직이 자체 가시성 설정(공개/비공개)을 가지는 것으로 예상하는가? 가시성은 최상위 그룹의 속성으로 유지될 것인가?
- 최상위 그룹에서 조직으로 기능을 이관하는 것은 어떤 모습으로 보일 것인가?
조직: 자주 묻는 질문
대형 SaaS 고객이 조직 수준에서 라이선스를 받을 것으로 예상하는가, 예를 든다면 하나의 라이선스 아래에서 여러 최상위 그룹을 포함하는 능력을 가질 것으로 예상하는가?
네, 이것은 이행과 관련된 사항으로 논의되었으며, 조직의 Post MVC 로드맵에 포함되어 있습니다. 조직과 이행 사이의 맞춤도 참조하세요.
조직에 대체 GitLab 도메인 이름(예: customer.gitlab.com)을 구성할 수 있는 것으로 예상하는가?
현재 이 시점에서 대체 GitLab 도메인 이름 구성 계획은 없습니다. 이전에 서브도메인이 관리적인 도전을 가져온다는 의견을 들었습니다. 현재 GitLab Dedicated가 그에 훨씬 더 적합합니다.
조직이 자체 가시성 설정(공개/비공개)을 가지는 것으로 예상하는가? 가시성은 최상위 그룹의 속성으로 유지될 것인가?
현재 조직은 공개 상태이지만 자체적인 가시성 설정을 갖게 될 것입니다. 사용자가 조직을 볼 수 있는 시기도 참조하세요.
최상위 그룹에서 조직으로 기능을 이관하는 것은 어떤 모습으로 보일 것인가?
우리의 요구 사항 중 하나는 모든 것을 조직으로 매핑해야 한다는 것입니다.
이렇게만 해야만 우리가 추구하는 격리를 달성할 수 있을 것입니다.
SaaS의 경우, 모든 기존 그룹 및 프로젝트는 이미 백엔드에서 Org_ID = 1에 매핑되어 있습니다.
Org_ID = 1은 기본 조직을 나타내며, 조직 롤아웃 후 모든 기존 그룹 및 프로젝트가 기본 조직의 일부가되어 해당 컨텍스트에서 표시될 것입니다.
SaaS와 온프레미스 간의 차이점은 SaaS에서 사용자가 여러 조직을 생성할 것으로 예상하고, 온프레미스에서는 그렇지 않다는 것입니다.
이를 can_create_organization 어플리케이션 설정을 통해 관리할 것이며, 해당 설정은 SaaS에는 기본적으로 활성화되고, 온프레미스 사용자에게는 기본적으로 비활성화될 것입니다.
귀하의 기능이 단계적으로 구성을 지원할 수 있는지 여부를 고려하십시오. 다시 말해, 기능이 충돌을 일으키지 않고 여러 단계에 걸쳐 존재할 수 있는지를 판단해 보세요. 귀하의 기능이 단계적으로 구성을 지원할 수 있다면:
- 오늘, SaaS 및 온프레미스 모두 최상위 그룹에 기능을 추가해야 합니다. 온프레미스의 경우 인스턴스에도 추가해야 합니다.
- 조직이 준비되면 인스턴스 수준의 기능을 조직 객체로 이관하면 모든 고객을 대상으로 해당 기능이 조직 및 최상위 그룹 모두에서 사용할 수 있게됩니다.
귀하의 기능이 단계적으로 구성을 지원할 수 없다면:
- 오늘, SaaS 전용으로 최상위 그룹에 기능을 추가해야 하며, 온프레미스의 경우 인스턴스에 추가해야 합니다. 최상위 그룹 기능은 온프레미스 사용자에게는 숨겨져 있을 것입니다.
- 조직이 준비되면 온프레미스 고객을 위해 인스턴스 기능을 조직으로 이관하되, SaaS의 경우에는 조직 수준에서 해당 기능을 숨겨야 합니다. SaaS에서 사용자는 기능을 최상위 그룹에서 계속 관리하며, 조직 수준에서는 관리하지 않을 것입니다. 미래에 대부분의 유료 고객이 자체 조직으로 이동하면, 모든 고객(SaaS 및 온프레미스)을 대상으로 중요 변경 사항을 도입하고 최상위 그룹에서 해당 기능을 숨기고 조직 수준에서 제거할 수 있습니다.