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	`@fabiopitino`				2024-05-08

모듈러 모놀리스 ADR 003: 모듈 스튜어드쉽

맥락

도메인 및 플랫폼 모듈에 스튜어드쉽을 할당하는 방법은 무엇인가요? 우리는 명시적인 스튜어드가 없는 많은 양의 공유 코드를 가지고 있습니다.

결정

모든 사람이 기여할 수 있는 GitLab 원칙에 더 부합하기 위해 소유자 대신 스튜어드라는 용어를 사용합니다. 스튜어드는 코드의 관리자입니다. 특정 기능이 설계된 방식과 그 이유를 알고 있습니다. 또한 아키텍처의 특성과 제한사항을 알고 있습니다. 그러나 변경을 환영하고 기여자들을 성공으로 이끌어줍니다.

도메인 바운디드 컨텍스트나 플랫폼 모듈에서 모듈이든, 최소한 1개의 스튜어드 그룹이 있어야 합니다. 이 그룹은 팀 이름(또는 GitLab 그룹 핸들)일 수 있습니다. 선택적으로, 스튜어드 디렉터리에 단일 IC(Individual Contributor) 항목을 포함할 수 있습니다.

모듈을 추출하는 데 Packwerk 패키지를 사용할 때, package.yml에서 스튜어드쉽을 직접 지정할 수 있게 될 것입니다.

metadata:
  stewards:
    - group::pipeline execution # 팀 이름
    - group::pipeline authoring # 팀 이름
    - @grzesiek  # IC
    - @ayufan    # IC

플랫폼 모듈(예: Gitlab::Redis)의 경우, 모든 플랫폼 코드가 “공유”로 분류되기 때문에 스튜어드로 전담된 전체 팀이 없을 수 있습니다. 그러나 팀원들은 특정 기능의 전문가로서 자신을 추가할 수 있습니다.

결과

코드에서 정의된 스튜어드쉽은 매우 강력할 수 있습니다.

패키지 데이터의 메타데이터에서 CODEOWNERS의 섹션을 자동으로 생성할 수 있습니다.
Review Roulette 또는 Suggested Reviews 기능은 이 디렉터리을 첫 번째로 선호할 수 있습니다.
엔지니어들은 스튜어드를 쉽게 식별하고, 초기에 디자인 대화를 나눌 수 있습니다.
모놀리스에 있는 젬들(gems/)은 Packwerk 패키지로 래핑되어야 하며, 명시적인 스튜어드가 있는 이점을 누릴 수 있습니다.

대안

모듈화 초기 단계에서, Packwerk를 도입하기 전에, 우리에게는 명시적인 소유권 개념이 없습니다. 처음에는 각 팀이 어떤 바운디드 컨텍스트에 책임이 있는지 알고 있는 것에 의존합니다. 플랫폼 모듈의 “공유 코드”에 대해서는 초기에 유지보수자가 스튜어드의 역할을 채우도록 기대합니다.

장점: 수습 유지보수자에게 명확한 개발 경로와 목표를 제시합니다. 오늘날, 어떤 것을 배워 성공적인 유지보수자가 되기 위해 배워야 하는지 불분명합니다.
단점: “공유” 코드의 양이 매우 많으며, 특정 기능을 가장 잘 알고 있는 사람이 여전히 이해하기 어려울 수 있습니다. 또한, 코드를 젬으로 추출해도 명시적인 소유권 부족 문제를 해결하지 못할 수 있습니다.