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 (개인 네임스페이스)과 Group에 연관된 Namespace의 하위 클래스로서 기존되었습니다. 우리는 Project와 연관하여 Namespace를 더 연장하는 것으로 이를 더욱 발전시킬 수 있습니다. 각 Project는 그것의 ProjectNamespace로부터 소유되어야 하며, 이 관계는 기존의 Project <-> Group / 개인 네임스페이스 관계를 대체해야 합니다.

또한, 우리는 개인 네임스페이스에 대한 특정 모델이 부족하며, 이를 일반적인 Namespace 모델 대신 사용합니다. 이는 혼란스러울 수 있지만, 이는 UserNamespace라는 전용 서브 클래스를 만들어 문제를 해결할 수 있습니다.

결과적으로 Namespace 계층은 다음과 같이 변화할 것입니다:

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

새로운 기능들은 Namespace에 구현되어야 합니다. 마찬가지로, 기능을 다른 수준의 기능으로 재구현해야 할 경우, Namespace로 이동시킴으로써 기존에 구현되어 있는 모든 수준에서 이를 사용할 수 있습니다.

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

여러 Namespaces에서 그룹 계층을 조회하는 다양한 운행 쿼리들은 이미 사용 가능합니다. Projects는 계층 내의 잎 노드를 나타냅니다. 그러나 ProjectNamespace를 도입하는 것으로 인해, 이러한 운행 쿼리들은 또한 프로젝트를 검색하는 데 사용될 수 있습니다.

이는 또한 우리의 일부 핵심 기능을 좀 더 간소화하는 것을 가능하게 합니다:

  • 루트는 프로젝트에 Namespace 계층을 기반으로 생성되어야 할 것이며, 프로젝트를 그룹 계층과 섞어서 생성할 필요가 없습니다.
  • GroupMembers와 ProjectMembers를 구분할 필요가 없습니다. 모든 Members는 Namespace와 관련되어야 합니다. 이는 간소화된 쿼리 작성으로 이어질 수 있으며, 정책을 중복해서 만들 가능성이 있습니다.

더 많은 기능들이 Namespace로 이동하게 될수록, Project 모델의 역할은 시간이 지남에 따라 기본적으로 리포지터리 관련 기능의 컨테이너로의 퇴화될 것입니다.

단계

우리의 기능을 위한 Namespace로서의 계층을 확립하는 데 필요한 작업은 그룹 및 프로젝트 통합 이픽 아래에서 추적됩니다.

단계 1 (완료)

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

프로젝트 및 프로젝트 네임스페이스가 동등한지 확인해야 합니다.

  • 프로젝트 생성: 각 프로젝트에 대해 새로운 프로젝트 네임스페이스가 만들어지도록 하기 위해 Rails 콜백을 사용합니다. 프로젝트 네임스페이스 레코드는 프로젝트의 created_at/updated_at 속성과 동일한 created_at 및 updated_at 속성을 포함해야 합니다.
  • 프로젝트 업데이트: Rails의 after_save 콜백을 사용하여 프로젝트 및 프로젝트 네임스페이스 간에 일부 속성이 동기화되도록 합니다. 자세한 내용은 project#after_save를 참조하십시오.
  • 프로젝트 삭제: FK(외래 키)가 지렛대 삭제하거나 Rails 콜백을 사용하여 Project 또는 ProjectNamespace이 제거될 때 해당되는 ProjectNamespace 또는 Project도 제거되도록 합니다.
  • 프로젝트를 다른 그룹으로 이전: 프로젝트가 이전될 때 해당 프로젝트 네임스페이스가 동일한 그룹으로 이전되도록 합니다.
  • 그룹 이전: 그룹을 이전할 때 해당 그룹의 모든 서브 프로젝트, 직접적 또는 하위 그룹을 통해, 해당 프로젝트 네임스페이스가 올바르게 이전되도록 합니다.
  • 프로젝트 내보내기/가져오기
    • 프로젝트 내보내기: 이 단계에서는 프로젝트 네임스페이스에 내보낼 특정 정보가 없기 때문에, 프로젝트만 계속해서 내보냅니다. 최종적으로는 프로젝트 네임스페이스도 내보내길 원합니다.
    • 프로젝트 가져오기: 새로운 프로젝트를 만들면, 프로젝트 모델에 대한 Rails after_save 콜백을 사용하여 프로젝트 네임스페이스가 만들어집니다.
  • 그룹 내보내기/가져오기: Group를 가져오거나 내보낼 때 프로젝트가 작업에 포함되지 않습니다. 이 기능이 해당 그룹이 가져오거나 내보낼 때 Project를 포함하도록 변경된다면, 해당 논리는 해당 프로젝트 네임스페이스를 가져오거나 내보내도록해야 합니다.

이러한 사항을 확인한 이후에는, 데이터 마이그레이션을 실행하여 모든 Project에 대해 ProjectNamespace 레코드를 생성합니다. 마이그레이션 중에 생성된 프로젝트 네임스페이스의 created_at 및 updated_at 속성은 마이그레이션 실행 시간으로 설정되어야 합니다. 프로젝트 네임스페이스의 created_at 및 updated_at 속성은 해당 프로젝트 네임스페이스의 created_at 및 updated_at 속성과 일치하지 않아야 합니다. 우리는 필요한 경우 언제든지 생성된 프로젝트 네임스페이스 중의 어떤 것에 대한 감사를 위해 다른 날짜가 필요합니다. 이 작업이 완료된 후, 모든 프로젝트에 대한 ProjectNamespace 백필로 데이터를 마이그레이션해야 합니다.

단계 2 (완료)

  • 단계 2 이픽.
  • 목표: ProjectNamespace을 데이터베이스 수준에서 다른 엔티티에 연결합니다.

이 단계에서:

  • 엔지니어링 수준에서 회사 전체에 변경 사항을 전달합니다. 모든 팀이 활발하게 협력할 것으로 기대되지는 않지만, 3단계 이전에 처리할 수 있는 준비된 프로젝트 또는 중복 작업과의 간섭 또는 중복된 작업으로 인한 회귀를 피하기 위해 엔지니어들이 인식하기를 원합니다.

Phase 3 (진행 중)

이 단계에서는 Project에서 ProjectNamespace 또는 직접 Namespace로 기본 및 우선순위 프로젝트 기능을 이관하고 있습니다. 이 단계의 일환으로 해결해야 할 문제점:

  • 구성원/구성원 작업 통합 - UI 및 API 수준에서.
  • 즐겨찾기: 현재로서는 프로젝트만 즐겨찾기할 수 있습니다. 우리는 이를 그룹 수준으로 가져오고자 합니다.
  • 공통 작업: 삭제, 이전, 복원. 이것은 컨트롤러 수준에서 통합한 다음 아래로 전파될 수 있습니다.
  • 현재로서는 프로젝트 수준에서만 아카이빙이 작동합니다. 이것을 그룹 수준으로 가져올 수 있으며, “보류 중인 삭제” 메커니즘과 유사하게 동작할 수 있습니다.
  • 아바타 서빙 및 작업.

Phase 4

이 단계에서는 Project에서 ProjectNamespace/Namespace로 기능을 추가적으로 이관하고 있습니다:

  • 코드에서 Project를 ProjectNamespace로 대체합니다.
  • 네임스페이스 및 네임스페이스 기능이 노출되는 API 변경사항.
    • groups API를 확장할 것인지 또는 namespaces 엔드포인트를 도입하고 groups 및 projects 엔드포인트를 천천히 폐기할 것인지 조사합니다.
  • Project에서 ProjectNamespace 또는 Namespace로 이관해야 하는 각 기능을 분해합니다.
    • Project -> Namespace로 기능을 직접 이관할 수 있는지 vs 특성별로 판단할 수 있습니다.
  • Project#namespace를 ProjectNamespace로 이관.
  • Project 및 ProjectNamespace 간 라우트 통합.
  • 정책 통합](https://gitlab.com/groups/gitlab-org/-/epics/6689).

Phase 5

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

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

Namespaces로의 기능 이관

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

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

관련 주제