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

이 문서는 진행 중인 작업이며 Cells 디자인의 매우 초기 상태를 나타냅니다. 중요한 측면들이 문서화되지 않았지만, 우리는 나중에 이를 추가할 예정입니다. 이것은 Cells에 대한 하나의 가능한 아키텍처이며, 우리는 이를 구현할 접근 방법을 결정하기 전에 대안과 비교할 것을 의도합니다. 우리가 이를 구현하지 않기로 결정하더라도, 이 문서는 우리가 이 접근 방법을 선택하지 않은 이유를 문서화하기 위해 유지될 것입니다.

Cells: 개인 네임스페이스

Cells에서 전반적인 아키텍처와 쉽게 어울리지 않는 개인 네임스페이스는, Cells 아키텍처가 모든 데이터가 단일 조직에 속해있는 것에 의존하기 때문입니다. 사용자가 여러 조직을 통해 작업할 수 있도록 허용되는 경우, 개인 네임스페이스 및 해당 프로젝트를 저장할 단일 조직을 선택하는 것에는 자연스러운 위치가 없습니다.

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

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

사용자가 기대하는 바가 없는 개인 프로젝트를 생성할 수 있는 장소를 제공합니다. 사용자는 그룹을 자신만을 위해 만들 필요가 없으므로 사용자들을 이것으로부터 구할 수 있습니다.
사용자가 브랜치를 푸시할 권한이 없는 프로젝트에 기여할 때 만들어지는 포크를 놓을 수 있는 기본 위치를 제공합니다. 이것은 다시, 사용자들이 상위 프로젝트로 브랜치를 푸시할 수 없어서 포크를 만들고 포크된 MR을 기여하기 때문에 그들을 방어합니다.

1. 정의

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

2. 데이터 이동

3. 제안

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

사용자가 그룹을 만들 필요 없이 자신의 프로젝트를 저장할 수 있는 장소.
사용자가 브랜치를 푸시할 권한이 없는 프로젝트에 기여할 때 만들어지는 포크를 저장할 수 있는 장소.

이 제안에서는 (1)에만 초점을 맞추고, (2)는 Cells: Contributions: Forks에서 설명된 적절한 워크플로우로 대체될 것으로 가정합니다. 개인 네임스페이스를 포크를 저장하는 곳으로 사용하는 것에서 이동할 계획이기 때문에 이 두 가지 목적 중 주요한 경우는 교차 조직 연결을 지원할 필요가 없다고 가정할 수 있습니다.

3.1. 여러 조직간에 이동할 수 있는 개인 네임스페이스

기존 사용자의 경우, 단기간 내에 개인 네임스페이스는 기본 조직 내에 존재할 것입니다. 이는 모든 사용자가 일단 자신의 개인 네임스페이스를 통해 기본 조직에 연결될 것을 의미합니다. 새로운 조직이 생성될 때, 새로운 사용자 또한 해당 조직에서 생성될 수 있습니다. 새로운 사용자의 개인 네임스페이스는 기본값이 아닌 해당 새로운 조직과 연관될 것입니다. 또한 사용자는 기본 조직 외에도 다른 조직의 구성원이 될 수 있습니다. 이 경우, 그들은 개인 네임스페이스에 접근하기 위해 기본 조직으로 전환해야 할 것입니다. 이는 그들이 자신의 개인 네임스페이스를 다른 홈 조직으로 이동할 수 있는 방법을 정의할 때까지의 문제입니다. 이를 수행하기 위해서는 개인 네임스페이스가 이동되기 전에 그룹으로 변환되어야 할 수 있습니다. 조직이 삭제될 때, 해당 조직과 연관된 개인 네임스페이스에 대한 처리 방법을 결정해야 할 것입니다. 이런 길을 택하게 될 경우, 그룹이나 프로젝트를 자체 조직으로 이동할 때 발생할 것으로 예상되는 문제와 유사한 문제가 발생할 수 있으나, 전체적인 영향에 대한 추가 조사가 필요할 수 있습니다.

그러나 이러한 결정은, 상위 프로젝트가 조직으로 이동되는 즉시 상류에서 기여로 사용된 기존 개인 네임스페이스가 분리되게 될 것을 의미합니다. GitLab.com의 모든 프로젝트 중 10%가 개인 네임스페이스에 속한 포크일 수도 있습니다. 이것은 약간의 변화를 초래할 수 있지만, 포크가 주로 MR에 사용되는 브랜치들을 저장하기 때문에 영향을 받는 사용자들에게 해당 포크를 조직의 맥락에서 다시 만들도록 요구하는 것이 합리적일 수 있습니다.

그러나 관여할 수 있는 Cells의 영향에 관한 논의 중에서, 사용자가 브랜치를 푸시할 권한이 없는 프로젝트에 기여하기 위해 포크를 저장할 공간인 기여 공간에 관한 아이디어를 더 탐구할 것입니다.

장점:

사용자의 홈 조직을 통한 개인 네임스페이스 쉬운 접근. 대부분의 사용자가 하나의 조직에서 작업할 것으로 예상됩니다.
사용자가 하나의 조직에서만 작업하는 경우, 기여 그래프는 동일한 조직의 일부로서 사용자의 개인 및 조직적 활동이 집계될 것으로 기대됩니다.

단점:

다양한 조직 간에 개인 네임스페이스를 이동할 수 있는 전송 메커니즘을 구축해야 한다는 것은 매우 복잡합니다. 이것은 기존 Cells 아키텍처를 위반할 것으로 생각되며, 이는 조직이 다른 Cells에 위치할 수 있기 때문입니다. 이것을 가능하게 하기 위해서는 조직의 격리를 깨야 할 것입니다.
다양한 조직 간의 이동이 연결 해제와 데이터 손실을 유발할 위험이 매우 높습니다.
이전에 언급한 대로 개인 네임스페이스를 그룹으로 변환하는 것은 간단한 프로세스가 아닙니다.

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

기존 사용자의 개인 네임스페이스는 단기간 동안 기본 조직 내에 존재할 것입니다. 이는 모든 사용자가 먼저 개인 네임스페이스를 통해 기본 조직과 연결될 것을 의미합니다. 기본 조직 이외의 조직의 구성원으로 GitLab에 가입하는 새로운 사용자도 기본 조직에 개인 네임스페이스를 받을 것입니다. 기본 조직 이외의 조직에는 개인 네임스페이스가 없을 것입니다.

장점:

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

단점:

여러 조직의 구성원인 사용자들은 개인 콘텐츠가 기본 조직에 저장된다는 것을 기억해야 합니다. 접근하기 위해, 기본 조직으로 다시 전환해야 합니다.
새로 가입한 사용자들은 왜 기본 조직의 일부인지 이해하지 못할 수 있습니다.
사용자 프로필 페이지에 일부 영향을 미칩니다. 개인 프로젝트는 기본 조직 이외의 조직에서 표시되지 않을 것입니다. 이로 인해 페이지에 많은 공백이 생길 것입니다. 개인 프로젝트 목록도 재작업되어야 할 것입니다.

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

기존 사용자의 개인 네임스페이스는 단기간 동안 기본 조직 내에 존재할 것입니다. 새로운 조직이 생성될 때마다, 사용자는 해당 조직마다 추가적인 개인 네임스페이스를 받게 됩니다. 예를 들어, 사용자가 조직의 그룹이나 프로젝트를 보는 경우 개인 네임스페이스가 생성됩니다. 이는 커뮤니티 기여자들이 회원이 되지 않고도 조직에 계속 기여할 수 있도록 보장하기 위함입니다.

장점:

개인 프로젝트의 콘텐츠가 조직에 의해 소유됩니다. 기업이 조직적 경계 외부로 콘텐츠를 누설하는 위험이 낮습니다.
전환 메커니즘이 필요하지 않음.
사용자 프로필 페이지에 대한 변경사항이 없습니다.
사용자는 작업하는 각 조직에 개인 프로젝트를 유지할 수 있습니다.
포크(forking)에 대한 기여 공간이 필요하지 않습니다.
기본 조직을 다른 조직과 다르게 기능하도록 만들 필요가 없습니다.

단점:

사용자는 각 조직에 저장된 개인 콘텐츠를 기억해야 합니다.
개인 콘텐츠는 조직에 소유될 것입니다. 그러나 이는 현재 자체 운영 방식과 유사하며 기업에서 원하는 방식일 수 있습니다.

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

모든 기존 개인 네임스페이스는 그룹으로 변환됩니다. 그룹 경로는 현재 사용자 이름과 동일합니다. 조직 릴리즈 시, 이러한 그룹은 기본 조직의 일부가 될 것입니다. 우리는 사용자가 개인 네임스페이스를 보유할 필요가 없게 만들어, 사용자를 정말로 전역적인 엔티티로 만듭니다.

장점:

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

단점:

개인 그룹의 개념이 수립되어야 합니다.
@-mentions가 어떻게 작동할지 알 수 없습니다. 현재로선 개별 사용자와 그룹을 태그하는 것이 가능합니다. 기존 논리에 따라 개인 그룹에 속한 모든 그룹 구성원이 태그될 것입니다.
사용자 프로필 페이지에 상당한 영향을 미칩니다. 개인 프로젝트는 사용자 프로필 페이지에서 분리되어, 사용자가 선택한 특정 프로젝트를 강조하기 위한 새로운 기능으로 대체될 수 있습니다(별표 표시 또는 고정을 통해).

4. 평가

우리는 조직을 위한 개인 네임스페이스를 선택사항으로 만드는 것으로 시작할 것입니다. 이 반복의 목표는 개인 네임스페이스를 기본 조직 이외의 모든 조직에 대해 비활성화하여, 개인 네임스페이스를 사용하고 싶지 않은 고객들이 이미 조직으로 이동할 수 있도록 하는 것입니다. 첫 번째 단계는 사용자가 직면하는 레벨에서의 변경에 대비하여 루비 온 레일즈 모델 관계를 변경할 것입니다.

이제 사용자가 클러스터 전역적이고 사용자의 개인 네임스페이스가 셀 지역적이어야 한다는 사실을 사용자 프로필과 개인 네임스페이스의 개념을 분리해야 한다. 사용자를 클러스터 전역적 엔티티로 만들고, 그룹을 선호하는 방향으로 개인 네임스페이스를 중단할 가능성이 높습니다.