조직
조직 이니셔티브는 SaaS 및 Self-managed 설치 사이의 기능 동등성을 달성하는 데 초점을 맞춥니다.
그룹 및 프로젝트 통합
조직 이니셔티브의 하나인 그룹 및 프로젝트 통합은 그룹과 프로젝트 간의 기능 차이를 해결하는 것입니다. 일부 기능(에픽과 같은)은 그룹 수준에서만 사용할 수 있습니다. 일부 기능(이슈와 같은)은 프로젝트 수준에서만 사용할 수 있습니다. 기타 기능(마일스톤과 같은)은 그룹 및 프로젝트 양쪽에서 사용할 수 있습니다.
그룹 또는 프로젝트 수준에서 기능을 추가하도록 하는 요청이 많이 있습니다. 다른 수준으로 기능을 이동하는 것은 여러 측면에서 문제가 됩니다:
- 기능을 이동하는 데 엔지니어링 시간이 필요합니다.
- 기능의 사용 가능성을 유지하기 위해 사용자 경험(UI) 오버헤드가 필요합니다.
- 중복되는 코드가 생성됩니다.
기능이 한 수준(프로젝트, 그룹 또는 인스턴스)에서 다른 수준으로 복사될 때, 복사본에는 종종 서로 다른 미묘한 차이가 있습니다. 이러한 뉘앙스는 수정이 필요할 때 추가적인 엔지니어링 시간을 요구하며, 수정은 여러 위치로 복사되어야 합니다. 이러한 미묘한 차이는 기능이 다른 위치에서 사용될 때 다른 사용자 경험을 만듭니다.
이 문제에 대한 해결책은 그룹과 프로젝트를 단일 엔터티, namespace
,로 통합하는 것입니다. 이 솔루션에 대한 작업은 여러 단계로 나뉘어져 있으며 epic 6473에서 추적됩니다.
그룹 및 프로젝트 네임스페이스와 상호 작용하는 기능 계획 방법
현재 시스템의 각 프로젝트에는 namespaces
테이블에 기록이 있습니다. 이를 통해 그룹과 프로젝트 간에 공유되는 기능을 만들 수 있습니다. 공동 동작은 관련 매커니즘을 사용하여 추가할 수 있습니다. Namespace
모델은 UserNamespace
메서드에 대한 책임이 있기 때문에 프로젝트와 그룹에 대한 공유 동작에 Namespace
모델을 사용하는 것은 권장되지 않습니다.
리소스 기반 기능
리소스 기반 기능을 이동시키려면 기존 기능을 지원해야 합니다. 이는 두 단계로 달성할 수 있습니다.
단계 1 - 설정
- 네임스페이스 테이블에 링크
- 테이블에 열 추가
- 예를 들어 이슈에는
프로젝트 ID
가 프로젝트 테이블을 가리킵니다.namespaces
테이블에 대한 링크를 설정해야 합니다. - 새 레코드에 이미 올바른 데이터가 있는지 코드 수정
- 역추적
단계 2 - 필수 작업
- 관련 사용 권한 모델 및 해당 성능에 대한 조사
- 권한을 확인하고 유지해야 합니다.
- 1단계에서 이동한 기능에 종속되는 기능을 지원하기 위해 다른 모델이 필요한지 조사
- CRUD 서비스 및 API(REST 및 GraphQL)를 1단계에서 추가한 새 열을 가리키도록 수정
- 리소스 검색 시 성능을 고려합니다.
새 기능 추가는 각 팀과 기능에 매우 의존적입니다.
설정 관련 기능
현재 NamespaceSettings
에는 계층적 설정이 있습니다. ProjectNamespace
를 만들면 이 프레임워크를 사용하여 일부 설정이 프로젝트 수준에서 적용되도록 할 수 있습니다.
설정 작업 시 다음을 확인해야 합니다:
- ‘조인’ 쿼리에 사용되지 않거나 해당 쿼리를 수정하지 않아야 합니다.
- 설정 업데이트가 고려되어야 합니다.
- 프로젝트에서 네임스페이스로 이동하려면 단계 1에서 설명한 것과 유사한 데이터베이스 프로세스를 따라야 합니다.
관련 주제
- 그룹 및 프로젝트 통합 아키텍처 문서
- 조직 사용자 문서