조직 개발 가이드

GitLab 조직(Organization) 개발 지침으로, 현재 단계의 목표, 데이터베이스 설계, Current.organization 사용법, 라우팅, 격리 테스트, 프론트엔드 가이드라인을 설명합니다.

조직 이니셔티브 는 GitLab.com과 GitLab Self-Managed 간의 기능 동등성(feature parity) 달성에 초점을 맞추고 있습니다. 기능 팀을 위한 가이드 # 조직 레벨에서 기능을 개발하기 전에 고려해야 할 사항은 이 섹션을 참조하세요. Organizations를 Beta 로 출시하는 목표 마일스톤은 19.4(2026-09-11)입니다. 이전에는 GitLab Self-Managed의 인스턴스 레벨에서 구현한 기능을 GitLab.com의 최상위 그룹용으로 다시 구현해야 했습니다. 조직은 이러한 중복을 없앱니다. 이제 기본 방침은 양쪽 모두를 지원하는 조직 레벨에서 기능을 개발하는 것입니다. 예를 들어 Artifact Registry는 조직을 앵커 포인트 로 사용합니다. 모든 기능에 조직 레벨 범위가 필요한 것은 아니며, Organizations가 아직 Beta로 출시되지 않았기 때문에 유의해야 할 주요 고려 사항이 있습니다. 자세한 내용은 다음 섹션을 참조하세요. 기능을 개발하기 전에 Slack( #g_organizations )에서 팀에 문의하여 사용 사례를 논의하세요. 기능에 조직 레벨 범위가 필요한지 판단하기 # 모든 기능이 조직 레벨에 속하는 것은 아닙니다. 대부분의 기능은 계속해서 그룹, 프로젝트 또는 사용자 레벨에 연결되어야 합니다. 이는 대부분의 기능이 인스턴스나 TLG 레벨을 대상으로 하지 않았던 기존 패러다임과 동일합니다. 조직 내 여러 그룹에 걸쳐 있는 기능은 그룹 레벨로 범위를 지정하되 그룹 간 탐색을 제공해야 합니다. 이것만으로는 조직 레벨 버전을 새로 만들 충분한 근거가 되지 않습니다. 사용자에게 조직 레벨의 거버넌스나 구성이 명확히 필요한 경우에만 조직 레벨에서 기능을 개발하세요. 자세한 내용은 Organizations Charter ( https://docs.google.com/document/d/1ldPftCifCDkdw3_3JKOnFjdwNHGIgbHIbW8HEc92i1Y/edit , 내부 접근 권한 필요)를 참조하세요. 조직 레벨 기능에 특화된 역할 계획하기 # 조직 레벨 역할은 그룹 및 프로젝트 역할과 별개입니다. 기능을 설계할 때: 각 조직 역할(Owner, User)이 수행할 수 있는 작업을 정의하세요. 그룹 레벨 역할이 조직 레벨 역할에 그대로 매핑된다고 가정하지 마세요. 기능에 새로운 조직 레벨 권한이 필요한지, 아니면 기존 역할로 충분한지 고려하세요. 자세한 내용은 조직 사용자 문서 를 참조하세요. 최상위 그룹을 자체 조직으로 이전하도록 요구하기 (GitLab.com) # 조직 컨텍스트에 의존하는 기능은 TLG가 자체 조직 내에 있어야 합니다. GitLab.com의 기본 조직에는 현재 TLG 소유자가 Organization Owner가 아닌 TLG들이 포함되어 있기 때문입니다. 이를 organization.default? 와 같은 검사로 강제하지 마세요. GitLab Self-Managed와 GitLab Dedicated는 정당하게 기본 조직 내에서 실행되므로, 이러한 검사