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: Contributions: Forks

forking workflow은 사용자가 기존 프로젝트 소스를 자신이 선택한 네임스페이스(개인 또는 그룹)로 복사할 수 있는 작업 흐름입니다.

1. 정의

forking workflow는 다양한 사용 패턴이 있는 일반적인 작업 흐름입니다:

사용자가 상류 프로젝트로 기여할 수 있도록 합니다.
사용자의 개인 네임스페이스에 리포지터리를 지속합니다.
사용자는 프로젝트를 복사하여 변경하고 수정된 프로젝트로 릴리스할 수 있습니다.

포크를 통해 상위 프로젝트에 쓰기 액세스가 없는 사용자도 변경 사항을 만들 수 있습니다. Forking workflow는 공개 프로젝트에 기여하기 위해 오픈 소스 커뮤니티에서 특히 중요합니다. 그러나 일부 회사에서는 책임 분리와 더 엄격한 액세스 제어를 선호하는 경우에도 중요합니다. 프로젝트에 액세스하는 권한은 특정 개발자 디렉터리으로 제한됩니다.

포크를 통해 다음이 가능해집니다:

상류 프로젝트를 수정할 수 있는 사용자를 더 엄격하게 제어합니다.
책임의 분할: 상위 프로젝트는 프로덕션 시스템에 연결된 CI 구성을 사용합니다.
Fork에서 CI 파이프라인을 훨씬 제한적인 환경에서 실행합니다.
모든 포크를 검증되지 않은 것으로 간주하여 프로젝트에 연결된 비밀 정보나 기타 정보의 노출 위험을 줄입니다.

Cells 아키텍처에서 포킹 모델은 다음과 같은 이유로 문제가 됩니다:

포크는 기존 리포지터리의 복사본입니다. 포크는 다른 조직, Cells 및 Gitaly 샤드를 거쳐서 만들어질 수 있습니다.
사용자는 Merge Request을 만들고 상류 프로젝트로 기여할 수 있습니다. 이 상류 프로젝트는 다른 조직 및 셀에 있을 수 있습니다.
Merge Request CI 파이프라인은 소스 프로젝트의 컨텍스트에서 실행되지만 대상 프로젝트의 컨텍스트에서 표시됩니다.

2. 데이터 탐색

데이터 탐색에서 현재의 포크에 관한 다음 정보를 검색했습니다:

현재 gitlab.com에는 대략 180만 개의 포크가 있습니다.
대부분의 포크는 개인 네임스페이스에 있습니다(82%).
동일한 최상위 그룹 또는 조직 내에서 포크를 사용하는 것을 기대했습니다. 포킹은 프로젝트에 액세스할 수 없는 사용자를 위해서만 필요합니다. 기업 내에서는 팀 구성원 간에 다른 권한이 있는 경우가 아니라면 포킹 워크플로우를 사용하지 않을 것으로 예상됩니다. 데이터에 따르면 fork 관계 중 약 9%가 최상위 부모 네임스페이스 식별자(최상위 그룹 및 개인 네임스페이스)가 일치합니다. 나머지 91%의 fork 관계는 서로 다른 최상위 네임스페이스에 포킹되었습니다. 최상위 그룹을 식별 가능한 회사와 일치시키려고 시도할 때 다음을 보았습니다:
- 3%의 포크된 프로젝트는 동일한 조직 내 상류 프로젝트에서 포크되었습니다.
- 포크된 프로젝트 중 83%는 상류 또는 하류 프로젝트와 관련된 식별 가능한 조직이 없습니다.
- 나머지 14%는 다른 회사의 소스 프로젝트에서 포크되었습니다.
지난 12개월간 활동을 한 최상위 그룹 중 9% (95,000)는 포크 관계가 있는 프로젝트가 있고, 지난 12개월간 활동을 하지 않은 최상위 그룹 중 5% (91,000)는 포크 관계가 있는 프로젝트가 있습니다. 이러한 최상위 그룹들이 Cells의 영향을 받을 것으로 예상합니다.

3. 제안

3.1. 포크는 현재 조직의 전용 기여 공간에 생성됩니다

조직 간에 프로젝트를 생성하는 대신 포크는 해당 조직 내에 있는 기여 공간에 생성됩니다. 기여 공간은 기본 조직 내에 있는 것이 아니라 해당하는 조직 내에 존재하는 개인 네임스페이스와 유사합니다. 예:

조직을 볼 수 있는 모든 사용자(공개 조직의 경우 모든 사용자)는 해당 조직 내에서 기여 공간을 생성할 수 있습니다. 이것은 그 조직의 프로젝트의 포크를 만들 수 있는 전용 네임스페이스로, 예를 들어 Produce Inc.의 경우 gitlab.com/organization/produce-inc/@ayufan일 수 있습니다.
기여 공간을 생성하기 위해 사용자가 조직의 구성원일 필요는 없습니다. 이렇게 함으로써 초대되지 않은 기여자가 그룹 또는 프로젝트에 초대받지 않고도 포크를 만들고 Merge Request을 생성할 수 있는 오픈 소스 워크플로우를 가능하게 합니다. 우리는 엄격히 가시성을 준수하므로 사용자는 초대되기 전에 비공개 조직에 포크를 만들 수 없습니다.
프로젝트에 대한 포크를 생성할 때 사용자는 조직 내 그룹에 포크를 생성할 수 있는 옵션만 표시됩니다. 또한 사용자들에게 기여 공간을 만들고 거기에 포크를 놓을 수 있는 옵션을 제공할 것입니다. 오늘날 포크를 만들 때 “그룹 생성” 옵션이 있습니다. 이 기능은 새로운 그룹을 생성하여 해당 조직에 새로운 포크를 저장할 수 있도록 제한될 것입니다.
기여하지 않고 포크만 생성하려는 사용자를 지원하기 위해 권한을 쓰기로 설정할 수 있는 어떤 네임스페이스에서도 링크되지 않은 포크를 생성할 수 있는 옵션을 고려할 수 있습니다.
사용자는 기여하는 조직마다 여러 기여 공간을 가질 수 있습니다.
사용자는 기여 공간 내에서 추가적인 개인 프로젝트를 만들 수 없습니다. 개인 프로젝트는 계속해서 개인 네임스페이스에 만들 수 있습니다.
조직은 기여 공간 사용을 막거나 비활성화할 수 있습니다. 이것은 조직의 그룹에 속하지 않은 사람의 포킹을 비활성화합니다.
현재의 모든 포크는 조직 내 사용자의 기여 공간으로 마이그레이션됩니다. 이는 상류 프로젝트 외부의 데이터에 대한 링크가 있는 경우 데이터 손실을 초래할 수 있으므로, 개인 프로젝트를 보존하고 포크 관계를 제거할 것입니다.
모든 포크는 조직의 일부입니다.
포크는 연합기능이 아닙니다.
기여 공간과 포크된 프로젝트는 부모 프로젝트와 구성을 공유하지 않습니다.
조직이 삭제되면 포크가 포함된 프로젝트는 기본 조직으로 이동하거나 새로운 조직을 생성하여 해당 조직의 유령 조직으로 만들어질 것입니다.
고객 사용량에 기여 공간의 데이터는 고객 사용량에 영향을 주지 않습니다.
현재 조직 범위의 러너가 없지만, 만약 구현한다면 기여 공간 프로젝트에서 어떤 방식으로 사용할 수 있는지에 대한 특별한 설정이 필요할 것으로 예상됩니다.

3.2. 내부 클러스터 포크

이 제안은 모든 신뢰하는 Cells 간에 API를 통해 통신하는 인트라 클러스터 포크로 포크를 구현합니다:

포크는 사용자가 선택한 그룹의 컨텍스트에서 항상 생성됩니다.
포크는 조직과 격리됩니다.
조직 또는 그룹 소유자는 조직간이나 일반적으로 포킹을 비활성화할 수 있습니다.
Merge Request은 대상 프로젝트의 컨텍스트에서 생성되며, 다른 셀에서 외부 프로젝트를 참조합니다.
대상 프로젝트에 대한 Merge 참조가 전송되어 대상 프로젝트의 컨텍스트에 표시하는 데 사용됩니다.
CI 파이프라인은 현재와 같이 소스 프로젝트의 컨텍스트에서 가져오고 결과는 대상 프로젝트의 Merge Request에 표시됩니다.
대상 프로젝트를 보유하는 셀은 내부적으로 소스 프로젝트의 상태를 가져오기 위해 GraphQL을 사용하고 대상 프로젝트 컨텍스트 정보에 포함합니다.

장점:

기존의 모든 포크는 현재와 같이 작동하며, 인트라-클러스터 포크로 처리됩니다.

단점:

조직의 목적은 조직 간 강력한 격리성을 제공하는 것입니다. 모든 조직을 가로질러 포크를 허용함으로써 보안 경계를 깨는 것입니다.
그러나, 현재 사용자가 로컬 컴퓨터에 리포지터리를 복제하고 선택한 어떤 리포지터리로 푸시할 수 있는 능력과는 다르지 않습니다.
소스 프로젝트의 액세스 컨트롤은 대상 프로젝트의 것보다 낮을 수 있습니다. 현재 시스템은 기여를 위해서는 포크와 상류 프로젝트의 액세스 수준이 동일해야 한다고 요구합니다.

3.3. 포크는 현재 프로젝트의 내부 프로젝트로 생성됩니다

프로젝트를 기관을 넘어 이동하는 대신, 포크는 기존 프로젝트에 첨부됩니다. 프로젝트를 포크하는 각 사용자는 고유한 프로젝트를 받습니다. 예시:

프로젝트의 경우: gitlab.com/gitlab-org/gitlab, 포크는 gitlab.com/gitlab-org/gitlab/@kamil-gitlab에 생성됩니다.
포크는 현재 기관의 맥락에서 생성되며 기관을 넘어서 관리되지 않습니다.
사용자(또는 포크의 기타 사용자 제공 이름)에 연결됩니다.
포크는 연합된 기능이 아닙니다.

단점:

모든 기존 포크를 처리하고 이동하는 방법에 대한 해답이 되지 않습니다.
현재 그룹/프로젝트 설정을 공유할 수 있으며 일부 보안 경계를 허락할 수 있습니다.

3.4. 포크는 현재 기관의 개인 네임스페이스에 생성됩니다

모든 사용자는 각 공개 기관에 개인 네임스페이스를 가질 수 있습니다. 사용자가 기관을 처음 방문하면 해당 기관에 대한 개인 네임스페이스를 받게 됩니다. 사용자는 upstream 리포지터리가 개인 네임스페이스와 동일한 기관에 있는 경우에 개인 네임스페이스로 포크를 생성할 수 있습니다. 기관이 제거되면 해당 기관의 개인 네임스페이스도 제거됩니다.

장점:

대부분의 기존 코드 경로를 재사용합니다.
대부분의 기존 제품 디자인 규칙을 재사용합니다.
기관 경계가 자연스럽게 격리됩니다.
여러 개인 네임스페이스는 사용자가 개인 프로젝트를 기관 간에 섞지 않고 나눌 수 있도록 합니다.
대부분의 사용자가 한 기관에서 작업할 것으로 예상되기 때문에 대부분의 사용자가 각각의 개인 프로젝트를 어느 기관에 저장했는지 기억할 필요가 없을 것으로 예상됩니다.

단점:

중복된 개인 네임스페이스가 생성됩니다. 우리는 향후 반복에서 이를 개선할 것으로 예상합니다.
여러 개인 네임스페이스는 특히 많은 수의 기관을 거쳐 작업할 때 탐색하기 어려울 수 있습니다. 이는 예외적인 경우로 예상됩니다.
개인 네임스페이스의 수명 주기는 기존의 경우와 마찬가지로 이미 고유 소유한 사용자 계정(예: 엔터프라이즈 사용자) 및 공개되지 않은 Self-Managed형 설치에 의해 종속될 것입니다.
기관 개인 네임스페이스에 새 URL 경로가 필요합니다.
기존의 개인 네임스페이스 경로를 적용해야 할 필요가 있습니다.

URL 경로 변경은 토론 중입니다.

4. 평가

이미 많은 어려운 문제들을 해결한 3.4. 포크는 현재 기관의 개인 네임스페이스에 생성됩니다를 따를 것입니다. 이 솔루션의 단점인 URL 경로 재작업이나 여러 개인 네임스페이스 다루기는 다른 대안 제안에서 생성된 문제보다 관리 가능하고 중요하지 않습니다.

5. 예시

예를 들어, gitlab-org/gitlab를 다른 기관으로 이동하는 경우, 이 제안의 영향을 설명하겠습니다. gitlab-org/gitlab에는 8천개가 넘는 포크가 있습니다.

이 방향이 이러한 포크들의 정규 URL에 영향을 미치나요?

네, 정규 URL은 포크에 영향을 받을 것입니다. 구체적인 경로 변경은 토론 중입니다. 기존 사용자들이 기존의 개인 네임스페이스에서 포크를 계속해서 기여하고자 하는 경우, 해당 포크를 소스 프로젝트 기관의 개인 네임스페이스로 이전해야 합니다. 예를 들어, https://gitlab.com/DylanGriffith/gitlab의 개인 네임스페이스 포크는 https://gitlab.com/-/organizations/gitlab-inc/@DylanGriffith/gitlab로 이전되어야 합니다. 이를 자동으로 이동시키는 방법을 제공할 수 있지만, 매뉴얼으로 실행하는 경우 다음 단계가 필요합니다:

기여 공간 포크 생성
로컬에서 원래 포크의 브랜치를 새 포크로 푸시
아직 오픈되어 있고 Merge하고자 하는 모든 Merge Request을 다시 생성합니다.

리포지터리 자체의 Git URL에 영향을 미치나요?

네. 구체적인 경로 변경은 토론 중입니다.

기관 내에서 또는 기여 공간으로 포크가 이동하는 것을 수용하기 위해 사용자의 조치가 필요한가요?

아니요. 기관이 공개되어 있다면 사용자는 개인 네임스페이스를 가질 것입니다.

공개된 GitLab.com에서 호스팅되는 기존 포크들이 깨지지 않도록 약속할 수 있나요?

기존 포크 프로젝트는 삭제되지 않지만, 소스 프로젝트가 다른 기관으로 이동될 때 포크 관계가 제거될 것입니다. 오픈 소스 프로젝트 소유자는 해당 프로젝트를 이동할 때 자신의 포크를 분리해야 함을 알게 될 것입니다. 이로 인해 기존 Merge Request의 이력을 유지하는 프로세스가 필요하지만, 이를 협업하거나 Merge하는 능력을 사실상 잃게될 것입니다. gitlab-org/gitlab의 경우, 이 프로젝트를 기관으로 이동할 결정을 내리면 이 프로세스에 대한 가능한 최소한의 자동 이동이 필요한지에 대한 추가 피드백을 구할 것입니다. 그러나 기여자의 작업 흐름은 이동 이후 변경되므로 이는 절점적인 사건이 될 것입니다.