GitOps 하시면서, 배포 전에 뭐가 바뀔지 알고 계신가요

GitOps 환경에서 PR만 봐서는 실제 쿠버네티스 매니페스트 변경이 무엇인지 알기 어렵다는 문제와, 공유 Helm Chart 구조로 인해 단일 변경이 모든 서비스에 즉시 반영되던 문제를 강남언니 팀이 두 가지 독립적 자동화로 해결한 사례다. ChartMuseum + Release Please로 Helm Chart 버전 관리를 도입하고, GitHub Actions + dyff로 PR마다 before/after 매니페스트 diff를 자동 생성해 PR 리뷰 시간을 10분에서 1분으로 단축했다. 50개 서비스 Helm Chart 업그레이드 PR에서 "No manifest diff found" 전체 확인 후 안심하고 머지할 수 있게 됐다.

핵심 포인트

공유 Helm Chart 디렉터리 구조 → ChartMuseum + 버전 명시로 서비스별 독립 업그레이드 일정 확보
Release Please(Conventional Commits 기반)로 Helm Chart 자동 시맨틱 버전 관리 + CHANGELOG 생성
GitHub Actions paths-filter + matrix strategy로 변경된 앱만 병렬 diff 실행
dyff: 쿠버네티스 시맨틱 인지 diff 도구, 리소스·env 순서 무시, 의미있는 스펙 변경만 표시
PR 리뷰 시간 10분 → 1분, 월 1-2건 Helm 배포 장애 → 0건

상세 정리

기존 문제 1: 모든 서비스가 main 브랜치 shared chart 참조, 플랫폼 변경 시 전 서비스 동시 재배포
기존 문제 2: values.yaml false→true 변경만 보이는 PR에서 실제 K8s 매니페스트 변경 수동 확인 필요
수동 확인 절차: 브랜치 체크아웃 → kustomize build → after.yaml 생성, main에서 before.yaml 생성 → 별도 diff
해결책 A: ChartMuseum을 K8s에 배포(S3 백엔드, 내부 네트워크 전용), kustomization.yaml에 repo + version 명시
Release Please: Conventional Commits 기반 semver 자동 결정(feat:→minor, fix:→patch, feat!:→major), CHANGELOG 자동 생성
해결책 B: PR CI 자동화 — paths-filter로 변경 앱 감지 → matrix로 앱별 병렬 실행
CI 단계: Helm Chart tarball 다운로드 → kustomize build(브랜치·main 각각) → dyff diff → sticky-pull-request-comment로 PR 댓글 자동 업데이트
dyff 선택 이유: plain diff는 리소스·env 순서 변경을 diff로 표시, dyff는 K8s 시맨틱 인지로 의미없는 변경 필터링
50개 서비스 Helm Chart 업그레이드 PR에서 "No manifest diff found" 50개 확인 → 안심하고 머지 가능
매니페스트 변경이 있을 때: dyff가 변경된 필드만 before/after 형태로 PR 댓글에 표시
성과: PR 리뷰 시간 10분→1분, 배포 장애 월 1-2건→0건