[의존성의 방향을 따라 5/5] Evergreen이 가능했던 이유

flex가 50개 레포 전반의 의존성 자동 업그레이드 파이프라인 'Evergreen'을 구축할 수 있었던 구조적 전제를 정리한 시리즈 마지막 편이다. Planner(의존 그래프 자동 구축) → Updater(OpenRewrite recipe 일괄 적용) → Distributer(CI 자동화)가 가능한 이유는 단 하나, '구조적 균질성(Structural Homogeneity)'임을 설명한다.

핵심 포인트

핵심 전제: Convention Plugin이 모든 레포에 동일한 의존성 선언 방식·타입 시스템·CI 파이프라인을 강제 → Evergreen의 세 컴포넌트가 "코드 1개 = 50개 레포 동시 적용" 가능
업그레이드 효과: 긴급 보안 패치 1-2주→1일, 패치 버전 2-4주→1일, 마이너 4-8주→1주, 메이저 1-3개월→2주
Planner 전제: 버전 관리 플러그인이 동일한 의존성 선언 방식을 강제 → 의존 그래프 자동 구축 가능
Updater 전제: 빌드 컨벤션 플러그인이 동일한 타입 시스템 제공 → OpenRewrite recipe가 50개 레포에 동일 적용
Distributer 전제: 동일한 CI 파이프라인·branch protection·퍼블리시 방식 → 자동화 상태 추적 가능
글로벌 선례: Google(Rosie/monorepo), Spotify(Backstage), Airbnb도 동일한 구조적 균질성 원칙 적용

상세 정리

시리즈 컨텍스트: 1편 의존성 방향 개념 → 2편 Planner → 3편 Updater → 4편 Distributer → 5편(본편) 왜 가능했나
Convention Plugin 역할: 레포별 빌드 관습을 플러그인으로 표준화, 새 레포 추가 시 플러그인 상속만으로 전체 규약 자동 준수
recipe 하나 → 50개 레포 동일 적용: OpenRewrite recipe가 AST 기반으로 코드를 직접 변환, 규칙적인 타입 시스템 없으면 레포마다 별도 recipe 필요
파서 하나 → 50개 레포 의존 그래프: Planner가 Gradle 빌드 파일을 파싱해 전체 레포 간 의존 관계 자동 추출, 선언 방식이 다르면 파서 분기 필요
CI 추적 로직 하나 → 50개 레포 모니터링: Distributer가 모든 레포의 PR 상태를 단일 로직으로 추적, CI 파이프라인이 다르면 각각 별도 어댑터 필요
균질성 비용: Convention Plugin 도입 초기에 기존 레포를 표준화하는 작업이 필요, 그러나 1회 투자로 장기 자동화 효과
보안 패치 1일: Evergreen이 취약점 CVE 감지 → 모든 레포에 동시 PR 생성 → CI 통과 → 자동 머지까지 완전 자동화

왜 읽나멀티 레포 환경에서 의존성 업그레이드가 항상 골치라면, Convention Plugin으로 구조적 균질성을 확보하는 것이 모든 자동화의 선행 조건임을 이 글이 설득력 있게 설명한다.

flex 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청