This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
ongoing @alexpooley @ifarkas @grzesiek @m_gill @mushakov devops data stores 2021-02-07

그룹 및 프로젝트 통합

다수의 기능이 단독으로 그룹이나 프로젝트 내에서 제공되고 있습니다. 그룹 및 프로젝트 기능 간의 경계는 과거에는 명확했으나, 이제는 그룹에서 프로젝트 기능 또는 프로젝트에서 그룹 기능을 요구하는 수요가 증가하고 있습니다. 예를 들어, 그룹에서 이슈를 가지거나 프로젝트에서 에픽을 가지는 등의 요구가 있습니다.

Simplify Groups & Projects Working Group은 우리의 아키텍처가 그룹과 프로젝트 간의 기능을 공유하는 것에 중요한 장애물임을 확인했습니다.

아키텍처 이슈: https://gitlab.com/gitlab-org/architecture/tasks/-/issues/7

도전 과제

기능 중복

특정 기능을 다른 수준에서 사용할 필요가 있는 경우, 우리는 이미 확립된 프로세스가 없습니다. 이로 인해 동일한 기능을 다시 구현해야 합니다. 이러한 구현은 시간이 지남에 따라 서로 다르게 발전하게 됩니다. 이 접근 방식의 몇 가지 문제점은 다음과 같습니다:

  • 기능은 해당 컨테이너에 결합됩니다. 실제로 기능을 해당 컨테이너에서 분리하는 것은 쉽지 않습니다. 결합의 정도는 기능마다 다릅니다.
  • 단순한 기능 중복은 더 복잡하고 취약한 코드베이스로 이어집니다.
  • 그룹 및 프로젝트 간의 통합 솔루션은 시스템 성능을 저하시킬 수 있습니다.
  • 다양한 팀에서 기능 범위가 넓은데, 이러한 변경 사항은 개발 간섭을 관리해야 합니다.
  • 그룹/프로젝트 계층 구조는 자연스럽게 기능 계층 구조를 만듭니다. 기능이 컨테이너 간에 존재할 때, 기능 계층 구조가 모호해집니다.
  • 기능 중복은 개발 속도를 늦춥니다.

상당한 아키텍처 변경 가능성이 있습니다. 이러한 변경 사항은 제품 디자인과 독립적이어야 하므로 고객 경험이 일관되게 유지될 수 있습니다.

성능

리소스는 복잡한 방식으로만 쿼리될 수 있습니다. 이는 권한, 에픽 등에서 성능 문제를 일으켰습니다. 예를 들어 사용자가 액세스할 프로젝트를 쿼리하려면 다음 소스를 고려해야 합니다:

  • 개인 프로젝트
  • 직접적인 그룹 멤버십
  • 직접적인 프로젝트 멤버십
  • 상속된 그룹 멤버십
  • 상속된 프로젝트 멤버십
  • 그룹 공유
  • 그룹 공유를 통한 상속된 멤버십
  • 프로젝트 공유

그룹/프로젝트 멤버십, 그룹/프로젝트 공유도 기능 중복의 예시입니다.

목표

현재 이 청사진은 엔지니어링 도전 과제와 엄격히 관련되어 있습니다.

  • 그룹 및 프로젝트 컨테이너 아키텍처 통합.
  • 기능을 해당 컨테이너에서 분리하기 위한 해결책 집합 개발.
  • 제품 변경과 엔지니어링 변경 분리.
  • 다른 팀에 악영향을 미치지 않고 아키텍처 변경 전략 개발.
  • 기능이 다른 수준에서 사용 가능하도록 하기 위한 해결책 제공.

제안

기존 Namespace 모델을 기능의 컨테이너로 사용합니다. 이미 User (개인 namespace와 연관된)에 Namespace이 있으며, Group (이것은 Namespace의 서브클래스입니다)과 연관이 있습니다. 이를 더 확장하여 Namespace을 Projects와 연관시켜 ProjectNamespaces을 도입할 수 있습니다. 각 Project는 해당 ProjectNamespace에 의해 소유되어야 하며, 이 관계는 기존의 Project <-> Group 또는 개인 namespace 관계를 대체해야 합니다.

또한 우리는 개인 네임스페이스를 위한 별도의 모델이 없고 일반적인 Namespace 모델을 대신 사용합니다. 이는 혼란스럽지만, UserNamespace라는 전용 서브클래스를 만들어 해결할 수 있습니다.

그 결과, Namespace 계층 구조는 다음과 같이 전환됩니다:

classDiagram Namespace <|-- UserNamespace Namespace <|-- Group Namespace <|-- ProjectNamespace

새로운 기능은 Namespace에 구현되어야 합니다. 마찬가지로, 다른 수준에서 해당 기능을 재구현할 필요가 있는 경우, Namespace로 이동함으로써 해당 기능이 모든 수준에서 사용 가능해집니다:

  • 개인 네임스페이스
  • 그룹
  • 프로젝트

여러 Namespaces에서 그룹 계층 구조를 쿼리하는 다양한 순회 쿼리는 이미 사용 가능합니다. Projects는 계층 구조에서 리프 노드를 나타냅니다. 그러나 ProjectNamespace를 도입함으로써 이러한 순회 쿼리를 사용하여 프로젝트를 검색할 수 있습니다.

이는 또한 핵심 기능 일부의 더 단순화를 가능케 합니다:

  • 라우트는 프로젝트와 그룹 계층 구조를 혼합하는 대신 Namespace 계층 구조를 기반으로 생성되어야 합니다.
  • GroupMembers 및 ProjectMembers를 구분할 필요가 없습니다. 모든 Members는 Namespace와 관련되어야 합니다. 이는 단순화된 쿼리와 잠재적으로 정책을 중복 제거할 수 있습니다.

더 많은 기능이 Namespace로 이동됨에 따라 Project 모델의 역할은 시간이 지남에 따라 본질적으로 리포지터리 관련 기능의 컨테이너로 축소될 것입니다.

반복

우리의 기능을 위한 Namespace로서의 Namespace를 설정하기 위해 필요한 작업은 Consolidate Groups and Projects 에픽 아래에서 추적됩니다.

단계 1 (완료)

  • 단계 1 에픽.
  • 목표:
    1. 각 프로젝트가 namespaces 테이블에 type='Project'로 해당 레코드를 받도록 보장합니다.
    2. 사용자 네임스페이스의 경우, 타입을 NULL에서 User로 변경합니다.

프로젝트 및 프로젝트 네임스페이스가 같은지 확인해야 합니다:

  • 프로젝트 생성: 신규 프로젝트마다 프로젝트 네임스페이스가 생성되도록 Rails 콜백을 사용합니다. 프로젝트 네임스페이스 레코드는 프로젝트의 created_at/updated_at 속성과 동일한 created_at 및 updated_at 속성을 포함해야 합니다.
  • 프로젝트 업데이트: Rails의 after_save 콜백을 사용하여 프로젝트 및 프로젝트 네임스페이스 간 일부 속성이 동기화되도록 보장합니다. 자세한 정보는 project#after_save를 참조하세요.
  • 프로젝트 삭제: FKs cascade 삭제 또는 Rails 콜백을 사용하여 Project 또는 해당 ProjectNamespace이 제거될 때 해당하는 ProjectNamespace 또는 Project도 제거되도록 보장합니다.
  • 프로젝트를 다른 그룹으로 이전: 프로젝트 이전 시, 해당 프로젝트 네임스페이스가 동일한 그룹으로 이전되도록 보장합니다.
  • 그룹을 이전: 그룹을 이전할 때, 해당하는 모든 서브 프로젝트가 해당하는 프로젝트 네임스페이스가 올바르게 이전되도록 보장합니다.
  • 프로젝트 내보내기 또는 가져오기
    • 프로젝트 내보내기는 현재 이 단계에서는 프로젝트 및 해당 프로젝트 네임스페이스가 미래에 내보낼 특정 정보를 포함하지 않으므로, 프로젝트만 계속해서 내보냅니다. 최종적으로 프로젝트 네임스페이스도 함께 내보내길 원합니다.
    • 프로젝트 가져오기는 새 프로젝트를 생성하므로 프로젝트 네임스페이스는 프로젝트 모델의 Rails after_save 콜백을 통해 생성됩니다.
  • 그룹 내보내기 또는 가져오기: Group을 가져오거나 내보낼 때, 프로젝트는 해당 작업에 포함되지 않습니다. 그 기능이 변경되어 해당 그룹이 가져오거나 내보낼 때 Project가 포함될 경우, 해당 프로젝트 네임스페이스들도 가져오기 또는 내보내기에 포함되어야 합니다.

이러한 요소들을 확인한 후, 데이터베이스 마이그레이션을 실행하여 모든 Project에 대한 ProjectNamespace 레코드를 생성합니다. 마이그레이션 중에 생성된 프로젝트 네임스페이스의 created_at 및 updated_at 속성은 마이그레이션 실행 시간과 동일하게 설정됩니다. 프로젝트 네임스페이스의 created_at 및 updated_at 속성이 해당 프로젝트의 created_at 및 updated_at 속성과 일치하지 않도록 합니다. 이러한 서로 다른 날짜는 필요한 경우 생성된 프로젝트 네임스페이스의 감사를 수행하는 데 도움이 될 수 있습니다. 이 작업이 완료된 후, Backfill ProjectNamespace for every Project에서 설명한 대로 데이터를 마이그레이션해야 합니다.

Phase 2 (완료)

  • Phase 2 epic.
  • Goal: ProjectNamespace를 데이터베이스 수준에서 다른 엔터티에 연결합니다.

이 단계에서는:

  • 엔지니어링 수준에서 회사 전체에 변경 사항을 전달합니다. 팀이 협력하지 않더라도, 엔지니어들이 다가오는 변경 사항을 인식할 수 있도록 합니다.
  • 재발 및 충돌 또는 중복된 작업을 피하기 위해 인지도를 높입니다. 이는 단계 3 이전에 처리할 수 있습니다.

Phase 3 (진행중)

이 단계에서는 Project에서 ProjectNamespace또는 직접 Namespace로 기본적이고 중요한 프로젝트 기능을 마이그레이션합니다. 이 단계의 문제 해결:

  • 멤버/멤버 작업 통합 - UI 및 API 수준에서.
  • 즐겨찾기: 현재 프로젝트만 즐겨찾기 할 수 있습니다. 이를 그룹 수준으로 확장하고 싶습니다.
  • 공통 작업: 삭제, 이전, 복원. 이는 컨트롤러 수준에서 통일하고 나중에 하위로 전파할 수 있습니다.
  • 현재는 프로젝트 수준에서만 아카이브가 작동합니다. 이를 “보류 중인 삭제” 메커니즘과 유사하게 그룹 수준으로 가져올 수 있습니다.
  • 아바타 서빙 및 작업.

Phase 4

이 단계에서는 Project에서 ProjectNamespace/Namespace로 추가 기능을 마이그레이션합니다:

  • Project의 사용을 코드에서 ProjectNamespace로 대체합니다.
  • Namespace 및 네임스페이스 기능을 노출하기 위한 API 변경
    • 그룹에 대한 API를 확장할 것인지 또는 namespaces 엔드포인트를 도입하고 groups 및 projects 엔드포인트를 천천히 폐기할 것인지 조사합니다.
  • Project에서 ProjectNamespace 또는 Namespace로 마이그레이션해야 하는 각 기능 분해
    • Project -> Namespace로 기능을 직접 이동할 수 있는지 Project -> ProjectNamespace -> Namespace로 이동해야 하는지 조사합니다. 이것은 기능별로 결정할 수 있습니다.
  • Project#namespace를 참조하는 Project로 마이그레이션.
  • Project & ProjectNamespace 간의 라우트 통합.
  • 정책 통합.

Phase 5

우리는 단계를 진행하면서 코드 정리를 해야 합니다. 그러나 모든 것을 개발 중인 동안 정리할 수 있는 것은 아닙니다. 예를 들어, 데이터베이스 열을 삭제하는 것은 모든 것이 작동하는 것을 확신할 때 마지막으로 수행할 수 있습니다. 이 단계에서는 다음에 중점을 둘 것입니다:

  • 코드 정리
  • 데이터베이스 정리

Namespaces로의 기능 마이그레이션

초기 반복은 Namespaces 하위 기능을 수용할 수 있는 프레임워크를 제공할 것입니다. 단계 그룹들은 최종적으로 자체 기능과 기능을 Namespaces로 마이그레이션해야 할 것입니다. 이로 인해 예상치 못한 방식으로 이러한 기능에 영향을 줄 수 있습니다. 따라서, UX 부채를 최소화하고 제품 일관성을 유지하려면, 단계 그룹은 Namespaces로 자신의 기능을 마이그레이션할 때 여러 가지 요소를 고려해야 합니다:

  1. 개념 모델: 이러한 기능의 현재 및 미래 상태 개념 모델은 무엇입니까? (디자이너를 위한 객체 모델링 참조) 이것들은 Pajamas에 문서화되어야 합니다 (예: Merge Request).
  2. Merge 충돌: 프로젝트, 그룹 및 관리자 수준 간에 어떤 불일치가 있나요? 이것들은 어떻게 해결될 수 있을까요? 이는 레이블에 대해 어떻게 이성적으로 판단했는지에 대한 예시를 보려면 이 이슈를 참조하세요.
  3. 상속 및 정보 흐름: 현재 컨테이너 계층구조 전반에 걸친 정보는 어떻게 상속되는가요? 이것은 새로운 상속 동작 프레임워크를 준수할 경우 어떻게 영향을 받을 수 있을까요?
  4. 설정: 이 기능의 설정은 현재 어디에서 찾을 수 있는가요? Namespaces에서 어떻게 영향을 받을 것인가요?
  5. 접근: 누가 이 기능에 액세스할 수 있으며, 이것은 새로운 컨테이너 구조에 영향을 받나요? 역할이나 개인 정보에 관한 고려할 사항이 있나요?
  6. 등급: 프로젝트 및 그룹에서 구분되는 등급 기능이 있나요?
  7. 문서: 이러한 변경으로 문서의 구조 및 내용이 어떻게 영향을 받나요?
  8. 솔루션 제안:
    • 크게 생각해보세요: 이 분석을 통해 기능 UX를 전체적으로 고려할 수 있는 좋은 기회가 제공됩니다. Namespaces가 제공하는 새로운 구조, 상속 및 기능을 고려하여 이 기능을 어떻게 사랑받을 수 있을까요? Pajamas를 준수하지 않는 UI가 있나요?
    • 작게 시작하세요: 마이그레이션을 돕기 위해 필요한 제품 변경 사항은 무엇인가요?
    • 빠르게 움직이세요: 이러한 솔루션 아이디어에 우선순위를 정하고, 이슈에 문서화하고, 구현을 위한 로드맵을 만드세요.

관련 주제