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의 기능은 한 번에 단일 조직에 대해 범위가 지정되어야 합니다. 이는 fork가 개인 네임스페이스의 중요한 작업 부하 중 하나이기 때문에 개인 네임스페이스에 대한 기능과 사용자에게 fork된 MR을 제시하는 UI는 종종 하향 및 상향 프로젝트의 데이터를 동시에 필요로 할 것입니다. 이러한 기능을 구현하는 것은 데이터가 다른 조직에 저장되어 있는 경우 매우 어려울 수 있습니다. 특히, MR의 경우에는 GitLab에서 가장 복잡하고 성능에 중점을 둔 기능 중 하나입니다.

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

사용자가 기여를 기대하지 않는 개인 프로젝트를 작성할 수 있는 장소를 제공합니다. 이 사용 사례는 사용자가 자신만을 위한 그룹을 만들 필요가 없게 합니다.
사용자가 브랜치를 푸시할 권한이 없는 프로젝트에 기여할 때 만들어진 fork를 저장할 기본 위치를 제공합니다. 이는 다시 원격 프로젝트에 브랜치를 푸시할 수 없는 사용자가 fork를 만들어 Merge Request을 기여할 수 있게 해줍니다.

1. 정의

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

2. 데이터 흐름

3. 제안

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

사용자가 그룹을 생성하지 않고 개인 프로젝트를 저장할 수 있는 장소를 제공합니다.
사용자가 브랜치를 푸시할 수 있는 권한이 없는 프로젝트에 기여할 때 만든 fork를 저장할 수 있는 장소를 제공합니다.

이 제안에서는 (1)에만 초점을 맞출 것이며, (2)는 Cells: Contributions: Forks에서 설명되는 적절한 워크플로우로 대체될 것이라고 가정할 것입니다. 개인 네임스페이스를 fork를 저장하는 곳에서 이동할 계획이므로, 선행조직 간 연결을 지원할 필요가 없다고 가정할 수 있습니다.

3.1. 여러 조직 사이에서 이동할 수 있는 하나의 개인 네임스페이스

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

그러나 이러한 결정은 일단 상하게 움직이는 경우에는 기존 개인 네임스페이스가 상하자의 조직으로부터 즉시 분리될 것을 의미합니다. GitLab.com에서 개인 네임스페이스에 있는 프로젝트 중 10%는 fork입니다. 이것은 약간의 혼란스러운 워크플로우일 수 있지만, fork가 주로 Merge Request에서 사용되는 브랜치만 저장하기 때문이라면, 영향을 받는 사용자들에게 그 fork를 조직의 맥락에서 다시 생성할 것을 요청하는 것이 합당할 수 있습니다.

사용자가 브랜치를 푸시할 수 없는 프로젝트에 기여하고자 할 때 fork를 저장하는 공간을 제공하여 기여 공간에 대한 아이디어를 더 자세히 탐구할 것입니다. 그 논의는 Cells에 미치는 영향의 큰 논의의 일부로 처리될 예정입니다.

장점:

사용자의 홈 조직을 통해 쉽게 개인 네임스페이스에 액세스할 수 있습니다. 대부분의 사용자가 하나의 조직에서만 작업할 것으로 예상합니다.
사용자 그래프는 하나의 조직에서만 작업하는 사용자의 경우 모든 조직 활동이 동일한 조직의 일부로 집계될 것이기 때문에 유지될 것입니다.

단점:

조직끼리 이동하는 전달 메커니즘이 구축되어야 하며, 이는 매우 복잡할 것입니다. 이는 현재 Cells 아키텍처를 위반할 것이며, 조직이 서로 다른 Cells에 위치할 수 있기 때문입니다. 이를 가능하게 하려면 조직의 고립을 깨야 할 것입니다.
조직 간 전송은 연결의 붕괴와 데이터 손실을 유발할 가능성이 매우 높습니다.
잘못된 조직으로 이동하기 전에 개인 네임스페이스를 그룹으로 변환하는 것은 간단한 프로세스가 아닙니다.

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

기존 사용자들은 단기간 동안 개인 네임스페이스를 기본 조직 내에 가지고 있을 것입니다. 이는 모든 사용자가 처음에는 개인 네임스페이스를 통해 기본 조직과 연관이 있을 것을 의미합니다. 기본 조직이 아닌 조직의 일부로 GitLab에 합류하는 새로운 사용자들 또한 기본 조직 내에서 개인 네임스페이스를 받게 될 것입니다. 기본 조직이 아닌 조직은 개인 네임스페이스를 포함하지 않을 것입니다.

장점:

전달 메커니즘이 필요하지 않습니다.

단점:

여러 조직의 구성원이 기본 조직에 개인 콘텐츠가 저장됨을 기억해야 할 것입니다. 그것에 접근하려면, 기본 조직으로 다시 전환해야 할 것입니다.
새로운 사용자들이 왜 기본 조직의 일부인지 이해하기 어려워할 수 있습니다.
사용자 프로필 페이지에 일부 영향을 미칠 수 있습니다. 기본 조직 이외의 조직에서는 개인 프로젝트가 표시되지 않을 것입니다. 이로 인해 페이지에 많은 여백이 발생할 것입니다. 개인 프로젝트 디렉터리도 다시 작업해야 할 것입니다.

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

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

장점:

개인 프로젝트의 콘텐츠는 조직에 의해 소유됩니다. 기업이 조직적 경계 외부로 콘텐츠가 유출될 가능성이 낮습니다.
전송 매커니즘이 필요하지 않습니다.
사용자 프로필 페이지에 변경 사항이 필요하지 않습니다.
사용자들은 근무하는 각 조직에서 개인 프로젝트를 유지할 수 있습니다.
포킹에 대한 기여 공간이 필요하지 않습니다.
기본 조직을 다른 조직과 다르게 작동하게 만들 필요가 없습니다.

단점:

사용자는 각 조직에 어떤 개인 콘텐츠를 저장했는지 기억해야 합니다.
개인 콘텐츠는 조직에 의해 소유될 것입니다. 그러나 이는 현재 Self-managed가 작동하는 방식과 유사하며 기업에서 원하는 방식일 수 있습니다.

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

모든 기존 개인 네임스페이스는 그룹으로 변환됩니다. 그룹 경로는 현재 사용자 이름과 동일합니다. 조직 릴리스 시, 이러한 그룹들은 기본 조직의 일부가 될 것입니다. 우리는 사용자가 개인 네임스페이스를 갖는 의무에서 벗어나 전역적인 개체가 되도록 사용자를 분리합니다.

장점:

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

단점:

개인 그룹의 개념이 정의되어야 합니다.
@-언급이 어떻게 작동할지 명확하지 않습니다. 현재 개별 사용자와 그룹을 태그하는 것이 가능합니다. 기존 로직에 따르면 개인 그룹에 속한 그룹 구성원은 모두 태그될 수 있습니다.
사용자 프로필 페이지에 상당한 영향을 미칩니다. 개인 프로젝트는 사용자 프로필 페이지에서 분리되며 사용자가 선택한 특정 프로젝트를 강조하기 위한 새로운 기능으로 대체될 수 있습니다(별도로 선택하거나 고정해서).
그룹이 최상위 그룹을 이동해야 하는 경우와 유사한 메커니즘을 사용하여 그룹을 조직 간에 이동할 수 있는지가 명확하지 않습니다. 이러한 기능은 당초에는 극히 제한될 것으로 예상됩니다. 3.1절에서 설명한 것과 유사한 전송 제한이 예상됩니다.

4. 평가

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

우리는 이제 사용자가 클러스터 전체적이고 사용자의 개인 네임스페이스가 셀 로컬이어야 한다는 개념을 분리해야 합니다. 아마도 우리는 사용자 프로필 페이지와 개인 네임스페이스를 중단하고 그룹으로 대체하게 될 것입니다.