조직

조직 이니셔티브는 SaaS와 셀프 매니지드 설치 사이의 기능 동등성을 달성하기 위해 노력하고 있습니다.

그룹 및 프로젝트 통합

조직 이니셔티브의 한 측면은 그룹 및 프로젝트를 통합하여 그들 사이의 기능 차이를 해결하는 것입니다. 에픽(Epics)과 같은 일부 기능은 그룹 레벨에서만 사용할 수 있습니다. 이슈(Issues)와 같은 다른 기능은 프로젝트 레벨에서만 사용할 수 있습니다. 그리고 마일스톤(Milestones)과 같은 다른 기능은 그룹과 프로젝트 양쪽에서 사용할 수 있습니다.

그룹 또는 프로젝트 레벨에 기능을 추가하라는 많은 요청을 받습니다. 기능을 서로 다른 수준으로 옮기는 것은 여러 측면에서 문제가 됩니다.

  • 기능을 옮기는 데에는 엔지니어링 시간이 필요합니다.
  • 기능 가용성의 정신적 모델을 유지하기 위해 UX 오버헤드가 필요합니다.
  • 중복된 코드를 생성합니다.

기능이 한 수준(프로젝트, 그룹 또는 인스턴스)에서 다른 수준으로 복사될 때, 복사본은 종종 서로 약간 다른 특징을 가지고 있습니다. 이러한 미묘한 차이로 인해 수정이 필요할 때 추가적인 엔지니어링 시간이 소요되며, 수정 사항을 여러 위치에 복사해야 합니다. 이러한 미묘한 차이는 또한 기능이 다른 위치에서 사용될 때 서로 다른 사용자 경험을 만들어 냅니다.

이 문제에 대한 해결책은 그룹과 프로젝트를 단일 entity ‘namespace’로 통합하는 것입니다. 이 솔루션에 대한 작업은 여러 단계로 나눠지고 에픽 6473에서 추적됩니다.

그룹 및 프로젝트네임스페이스와 상호작용하는 기능 계획 방법

현재 시스템의 모든 프로젝트는 ‘네임스페이스’ 테이블에 레코드가 있습니다. 이를 통해 그룹과 프로젝트 사이에서 공유되는 기능을 위한 공통 인터페이스를 사용할 수 있습니다. 공유 동작은 관심사 메커니즘을 사용하여 추가할 수 있습니다. ‘네임스페이스’ 모델은 ‘UserNamespace’ 메서드를 담당하므로 프로젝트와 그룹을 위한 공유 동작에 ‘네임스페이스’ 모델을 사용하는 것은 권장되지 않습니다.

리소스 기반 기능

리소스 기반 기능을 이주하기 위해서는 기존 기능을 지원해야 합니다. 이것은 두 단계로 달성할 수 있습니다.

1단계 - 설정

  • 네임스페이스 테이블에 연결
    • 테이블에 열을 추가합니다.
    • 예를 들어 이슈에서 ‘프로젝트 id’가 프로젝트 테이블을 가리킵니다. ‘네임스페이스’ 테이블로의 링크를 확립해야 합니다.
    • 새 레코드가 이미 올바른 데이터를 가지도록 코드를 수정합니다.
    • Backfill

2단계 - 필요 작업

  • 권한 모델 및 이와 관련된 성능 문제를 조사합니다.
    • 권한을 확인하고 유지해야 합니다.
  • 1단계에서 이주한 기능에 종속되는 기능을 지원하기 위해 다른 모델이 무엇을 지원해야 하는지 조사합니다.
  • 새로운 열을 추가했던 1단계에서 가리키도록 CRUD 서비스와 API (REST 및 GraphQL)를 조정합니다.
  • 리소스를 검색할 때 성능을 고려합니다.

새로운 기능을 도입하는 것은 모든 팀과 기능이 매우 의존적입니다.

설정 관련 기능

현재로서는 ‘네임스페이스설정’에 대한 캐스케이딩 설정이 가능합니다. ‘프로젝트 네임스페이스’를 생성함으로써 우리는 이 프레임워크를 사용하여 일부 설정이 프로젝트 수준에도 적용되도록 할 수 있습니다.

설정을 작업할 때 다음 사항을 고려해야 합니다:

  • ‘join’ 쿼리에서 사용되지 않거나 해당 쿼리를 수정하지 않아야 합니다.
  • 설정을 업데이트할 수 있도록 고려되어야 합니다.
  • 프로젝트에서 프로젝트 네임스페이스로 이동하려면, 1단계에서 설명한 유사한 데이터베이스 프로세스를 따라야합니다.

관련 주제