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
proposed -

이 문서는 진행 중인 작업으로 Cells 설계의 매우 초기 상태를 나타냅니다. 중요한 측면들이 문서화되지 않았지만, 향후 추가할 예정입니다. 이것은 Cells에 대한 하나의 가능한 아키텍처이며, 이를 구현할 접근 방식을 결정하기 전에 대안과 대조할 것을 의도하고 있습니다. 우리는 이를 구현하지 않기로 결정해도 이 문서는 보존될 것이며, 이 접근 방식을 선택하지 않은 이유를 문서화할 수 있도록 합니다.

Cells: 개인 네임스페이스

개인 네임스페이스는 Cells 아키텍처의 전반적인 구조에 쉽게 들어맞지 않습니다. 왜냐하면 Cells 아키텍처는 모든 데이터가 단일 조직에 속하도록 의존하기 때문입니다. 사용자가 여러 조직을 걸쳐 작업할 수 있게 되면, 개인 네임스페이스와 해당 프로젝트를 저장할 단일 조직을 선택하는 자연스러운 방법이 없습니다.

Cells에서 중요한 공학적 제약 사항 중 하나는 한 조직에 속하는 데이터가 다른 조직에 속하는 데이터와 연결되어서는 안 된다는 것입니다. 구체적으로, GitLab의 기능은 한 번에 하나의 조직에 대해 범위가 지정되어야 합니다. 이는 개인 네임스페이스에 대한 과제를 제시합니다. 왜냐하면 포크가 개인 네임스페이스의 중요한 워크로드 중 하나이기 때문입니다. 포크 및 사용자에게 포크된 MR을 제시하는 UI와 관련된 기능은 종종 하향 및 상향 프로젝트에서 동시에 데이터가 필요합니다. 이러한 기능을 구현하는 것은 다른 Cells에 저장된 다른 조직의 데이터인 경우 매우 어려울 것입니다. 특히, 이는 MR에 해당하는 경우이며, 이는 GitLab에서 가장 복잡하고 성능이 중요한 기능 중 하나입니다.

오늘날 개인 네임스페이스는 대부분 서로 중첩되지 않는 두 가지 목적을 제공합니다.

  1. 사용자가 기여를 받지 않을 것으로 예상되는 개인 프로젝트를 만들 수 있는 공간을 제공합니다. 이 경우 사용자는 자체 그룹을 만들 필요가 없으므로 시간이 절약됩니다.
  2. 사용자가 분기를 푸시할 권한이 없는 프로젝트에 기여할 때 생성하는 모든 포크를 넣을 기본적인 장소를 제공합니다. 다시 말해서, 사용자의 주된 필요성은 상류 프로젝트로 브랜치를 푸시할 수 없어서 포크를 생성하고 해당 포크에서 MR을 기여할 수 있기 때문입니다.

1. 정의

개인 네임스페이스는 사용자가 계정을 생성할 때 사용자명을 기반으로 제공됩니다. 사용자는 자신의 개인 네임스페이스 아래에 개인 프로젝트를 생성할 수 있습니다.

2. 데이터 흐름

3. 제안

위에서 설명한대로, 현재 개인 네임스페이스는 두 가지 목적을 제공합니다.

  1. 사용자가 그룹을 만들 필요 없이 자신의 프로젝트를 저장할 수 있는 공간입니다.
  2. 사용자가 상류 프로젝트에 기여할 때 생성하는 모든 포크를 저장할 수 있는 공간입니다. 이제 우리는 개인 네임스페이스를 포크를 저장하는 데 사용하는 것에서(2) 적절한 워크플로로 대체될 것으로 가정합니다. 이 때문에 주요 사용자 요구는 상류 프로젝트에 브랜치를 푸시할 수 없기 때문에 포크를 생성하고 포크에서 MR을 기여할 수 있다는 것입니다.

이 제안에서는 (1)에만 초점을 맞출 것이며, (2)는 Cells: 기여: 포크에서 설명된 적합한 워크플로로 대체될 것으로 가정합니다. 개인 네임스페이스를 포크를 저장하는 공간으로 사용하는 것에서 멀어지기로 계획하였기 때문에, 주요 남은 사용 사례는 여러 조직 간 링크 지원이 필요하지 않을 것으로 가정할 수 있습니다.

3.1. 조직 간으로 이동할 수 있는 하나의 개인 네임스페이스

기존 사용자를 위해 개인 네임스페이스는 단기간 내에 기본 조직 내에 존재할 것입니다. 이는 우선적으로 모든 사용자는 개인 네임스페이스를 통해 자신의 기본 조직과 연계될 것을 의미합니다. 새로운 조직이 생성될 때, 새로운 사용자는 해당 조직 내에도 생성될 수 있습니다. 새로운 사용자의 개인 네임스페이스는 기본적으로 새로운 조직과 연계될 것입니다. 또한 사용자는 기본 조직 이외의 다른 조직의 구성원이 될 수 있습니다. 이 경우, 사용자는 개인 네임스페이스에 접근하기 위해 기본 조직으로 전환해야 할 것입니다. 이를 다른 홈 조직으로 이동시키는 방법을 정의할 때까지입니다. 이러한 경우, 개인 네임스페이스가 이동되기 전에 그룹으로 변환되어야 할 수도 있습니다. 조직이 삭제될 때, 해당 조직에 연계된 개인 네임스페이스에 대해 어떻게 처리해야 할 지 결정해야 할 것입니다. 이 경로로 진행할 경우, 그룹이나 프로젝트를 고유한 조직으로 이동시킬 때 발생하는 것과 유사한 중단이 발생할 수 있지만, 전체 영향을 더 조사해야 할 수도 있습니다.

그러나 이 결정은 지금까지 상류 프로젝트에 기여하기 위해 포크로 사용된 기존 개인 네임스페이스가 상류 프로젝트가 조직으로 이동되는 즉시 상류와의 연결이 끊어지게 될 것을 의미합니다. GitLab.com에서 개인 네임스페이스의 모든 프로젝트 중 10%가 포크입니다. 이는 약간의 혼란스러운 워크플로일 수 있지만, 포크가 주로 MR에 사용되는 브랜치를 저장하기 때문에 영향을 받는 사용자에게 재생성하도록 요청하는 것이 타당할 수 있습니다.

우리는 사용자가 상류 프로젝트에 기여하고 싶을 때 포크를 저장할 공간인 기여 공간에 대한 아이디어를 더 탐구할 것입니다. 그 토론은 Cells의 포크에 미치는 영향의 전반적인 토론의 일부로 처리될 것입니다.

장점:

  • 사용자의 기본 조직을 통해 개인 네임스페이스에 쉽게 액세스할 수 있습니다. 대부분의 사용자가 단일 조직에서 작업할 것으로 기대됩니다.
  • 사용자 프로필은, 사용자의 개인 및 조직적 활동이 동일한 조직의 일부로 집약되기 때문에 사용자의 기여 그래프가 유지될 것으로 예상됩니다.

단점:

  • 여러 조직에서 개인 네임스페이스를 이동시키기 위한 전송 메커니즘을 구축해야 하며, 이는 극도로 복잡합니다. 이것은 현재 Cells 아키텍처를 위반하게 될 것이며, 왜냐하면 조직은 다른 Cells에 위치할 수 있기 때문입니다. 이것이 가능하도록 하려면 우리는 조직 격리를 깰 필요가 있을 것입니다.
  • 조직 간 이동에 따른 연결 끊김 및 데이터 손실 가능성이 높습니다.
  • 전송 전에 개인 네임스페이스를 그룹으로 변환하는 것은 간단한 프로세스가 아닙니다.

3.2. 기본 조직에 남아 있는 하나의 개인 네임스페이스

기존 사용자를 위해 개인 네임스페이스는 단기간 내에 기본 조직 내에 존재할 것입니다. 이는 우선적으로 모든 사용자는 개인 네임스페이스를 통해 자신의 기본 조직과 연계될 것을 의미합니다. 기본 조직 이외의 조직에서 GitLab의 일부로서 조직의 일부가 되는 새로운 사용자도 기본 조직에 개인 네임스페이스를 받게 될 것입니다. 기본 조직 이외의 조직에는 개인 네임스페이스가 포함되지 않을 것입니다.

장점:

  • 전송 메커니즘이 필요하지 않음.

단점:

  • 여러 조직의 일부인 사용자는 자신의 개인 콘텐츠가 기본 조직에 저장된다는 것을 기억해야 합니다. 이를 액세스하기 위해 기본 조직로 전환해야 합니다.
  • 새로운 사용자가 기본 조직의 일부인 이유를 이해하지 못할 수 있습니다.
  • 사용자 프로필 페이지에 영향을 미칠 수 있음. 기본 조직 이외의 조직에는 개인 프로젝트가 표시되지 않습니다. 이는 페이지에 많은 공백을 남길 것입니다. ‘개인 프로젝트’ 디렉터리도 재작업해야 할 것입니다.

3.3. 각 조직에 하나의 개인 네임스페이스

기존 사용자를 위해 개인 네임스페이스는 단기간 내에 기본 조직 내에 존재할 것입니다. 새로운 조직이 생성됨에 따라 사용자가 상호 작용하는 각 조직에 대해 추가적인 개인 네임스페이스를 받게 될 것입니다. 예를 들어 사용자가 조직 내에서 그룹이나 프로젝트를 보면 개인 네임스페이스가 생성될 것입니다. 이렇게 함으로써 커뮤니티 기여자들이 회원이 되지 않고도 조직에 계속 기여할 수 있도록 보장할 것입니다.

장점:

  • 개인 프로젝트의 콘텐츠는 조직에 속합니다. 기업들이 조직적 경계를 넘어 콘텐츠를 누설하는 것에 대한 낮은 위험.
  • 전송 메커니즘이 필요하지 않음.
  • 사용자 프로필 페이지를 변경할 필요가 없습니다.
  • 사용자들은 자신이 일하는 각 조직에 개인 프로젝트를 유지할 수 있습니다.
  • 포킹을 위한 기여 공간이 필요하지 않음.
  • 기본 조직을 다른 조직과 달리 다르게 작동하게 만들 필요가 없습니다.

단점:

  • 사용자는 각 조직에 속한 개인 콘텐츠를 기억해야 합니다.
  • 개인 콘텐츠가 조직에 속하게 되지만, 이는 현재 온프레미스가 작동하는 방식과 유사하며 기업들이 원하는 방식일 수 있습니다.

3.4. 개인 네임스페이스 중단

모든 기존 개인 네임스페이스는 그룹으로 변환됩니다. 그룹 경로는 현재 사용자명과 동일합니다. 조직 릴리스 시, 이러한 그룹은 기본 조직의 일부가 될 것입니다. 사용자의 개인 네임스페이스 보유 요구 사항이 해제되어 사용자가 실제로 전역 엔티티가 됩니다.

장점:

  • 사용자들은 개인 프로젝트를 그룹으로 구성할 수 있는 기능을 받게 됩니다. 이 기능은 매우 많이 요청된 기능입니다.
  • 사용자 생성 시 개인 네임스페이스를 만들 필요가 없어집니다.
  • 기존 개인 프로젝트에 대해 경로 변경이 필요하지 않습니다.

단점:

  • 개인 그룹의 개념을 정의해야 합니다.
  • @-멘션의 작동 방식이 불분명합니다. 현재로서는 개별 사용자 및 그룹을 태그하는 게 가능합니다. 기존 논리에 따라 개인 그룹에 속한 그룹 구성원은 모두 태그될 것입니다.
  • 사용자 프로필 페이지에 상당한 영향을 미칩니다. 개인 프로젝트는 사용자 프로필 페이지와 연결이 끊기고 사용자가 선택한 특정 프로젝트를 강조하기 위한 새로운 기능으로 대체될 수 있습니다(별표 표시 또는 고정을 통해).
  • 그룹이 최상위 그룹을 이동할 때 필요한 동일한 메커니즘을 사용하여 조직 간에 그룹을 이동시킬 수 있는 방법이 불분명합니다. 중기적으로는 이러한 기능이 매우 제한될 것으로 예상됩니다. 3.1.절에 설명된 것과 유사한 이전 전송 제한이 예상됩니다.

4. 평가

먼저, 조직에서 개인 네임스페이스를 선택 사항으로 만들기로 시작할 것입니다. 이 반복의 목표는 기본 조직 이외의 조직에서 이미 개인 네임스페이스를 사용하지 않으려는 고객들이 이미 조직으로 옮길 수 있도록 하기 위함입니다. 첫 번째 단계에서는 사용자가 직면하는 수준에서의 추가 변경을 준비하기 위해 루비 온 레일 모델 관계만 변경할 것입니다.

지금은 사용자가 클러스터 전체로, 사용자의 개인 네임스페이스가 셀 내부로 이동할 필요가 있는 만큼 사용자 프로필 및 개인 네임스페이스의 개념을 분리해야 합니다. 개인 네임스페이스를 그룹의 대안으로 중단할 가능성이 높습니다.