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를 도입하기 전에, 우리에게는 명시적인 소유권 개념이 없습니다. 처음에는 각 팀이 어떤 바운디드 컨텍스트에 책임이 있는지 알고 있는 것에 의존합니다. 플랫폼 모듈의 “공유 코드”에 대해서는 초기에 유지보수자가 스튜어드의 역할을 채우도록 기대합니다.
- 장점: 수습 유지보수자에게 명확한 개발 경로와 목표를 제시합니다. 오늘날, 어떤 것을 배워 성공적인 유지보수자가 되기 위해 배워야 하는지 불분명합니다.
- 단점: “공유” 코드의 양이 매우 많으며, 특정 기능을 가장 잘 알고 있는 사람이 여전히 이해하기 어려울 수 있습니다. 또한, 코드를 젬으로 추출해도 명시적인 소유권 부족 문제를 해결하지 못할 수 있습니다.