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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality 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 모델을 기능의 컨테이너로 사용합니다. 이미 Namespace는 User (개인 네임스페이스)과 Group (Namespace의 하위 클래스)에 연결되어 있습니다. 이를 더 확장하여 Namespace를 Projects와 연결함으로써 ProjectNamespaces를 소개할 수 있습니다. 각 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를 기능의 컨테이너로 설정하기 위해 필요한 작업은 Consolidate Groups and Projects epic에 따라 추적됩니다.

Phase 1 (완료)

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

프로젝트 및 프로젝트 네임스페이스가 동등하도록 보장해야 합니다:

  • 프로젝트 생성: 각 프로젝트에 대해 새로운 프로젝트 네임스페이스가 생성되도록 Rails 콜백을 사용합니다. 프로젝트 네임스페이스 레코드에는 프로젝트의 created_at/updated_at 속성과 동일한 created_at 및 updated_at 속성이 포함되어야 합니다.
  • 프로젝트 업데이트: 레일즈의 after_save 콜백을 사용하여 프로젝트 및 프로젝트 네임스페이스 간에 일부 속성이 동기화되도록합니다. 자세한 내용은 project#after_save을 참조하십시오.
  • 프로젝트 삭제: 외부 키(FK) cascade delete 또는 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까지 기간 동안 엔지니어에게 다가오는 변경 사항을 알려주고 싶습니다. - 단계 3까지 처리할 수 있는 회귀 및 충돌 또는 중복 작업을 피하기 위해 인식을 높입니다.

Phase 3 (진행 중)

이 단계에서는 기본 및 고우선순위 프로젝트 기능을 Project에서 ProjectNamespace 또는 직접 Namespace로 마이그레이션합니다. 이 단계의 일환으로 해결해야 할 문제: - 멤버/멤버 작업 통합 - UI 및 API 수준에서. - 스타 등록: 현재로서는 프로젝트만 스타 등록할 수 있습니다. 이를 그룹 수준으로 확장하고자 합니다. - 일반 동작: 삭제, 이전, 복원. 이는 컨트롤러 수준에서 통합시킨 후 하위로 전파될 수 있습니다. - 현재로는 아카이빙이 프로젝트 수준에서만 작동합니다. 이를 “대기 중인 삭제” 메커니즘과 유사하게 그룹 수준으로 가져올 수 있습니다. - 아바타 제공 및 동작.

Phase 4

이 단계에서는 Project에서 ProjectNamespace/Namespace로 추가 기능을 마이그레이션합니다: - 코드에서 Project 사용을 ProjectNamespace로 교체합니다. - Namespace 및 Namespace 기능을 노출하기 위한 API 변경 - groups API를 확장할 것인지 또는 namespaces 엔드포인트를 도입하고 점진적으로 groups 및 projects 엔드포인트를 폐지할 것인지 조사합니다. - Project에서 ProjectNamespace 또는 Namespace로 마이그레이트해야 하는 각 기능을 분해합니다. - 이를 기능 단위로 결정할 수 있는지 여부에 대한 조사입니다. - Project#namespace를 ProjectNamespace 참조로 마이그레이션. - Project 및 ProjectNamespace 간 라우트 통합. - 정책 통합.

Phase 5

우리는 단계를 진행하는 동안 코드 정리를 목표로 해야 합니다. 그러나 모든 것이 개발 중일 때 정리할 수 있는 것은 아닙니다. 예를 들어, 데이터베이스 열을 삭제하는 것은 모든 것이 작동하는 것을 확인한 후에 수행될 수 있습니다. 이 단계는 다음에 초점을 맞춥니다: - 코드 정리 - 데이터베이스 정리

Namespaces로의 기능 마이그레이션

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

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

관련 주제