본문으로 건너뛰기

CI/CD 파이프라인

GenD는 GitHub Actions 기반 CI 검증과 ArgoCD/Imperative 기반 CD 배포를 결합합니다. PR 단계에서 모든 테스트가 통과해야 머지가 허용되며, 머지 직후 ACR 이미지 빌드 → AKS 자동 배포가 진행됩니다.

파이프라인 흐름​

주요 GitHub Actions​

워크플로우트리거역할
test.ymlPR · pushAPI/UI/Pipeline 테스트 + ruff + Trivy
deploy-aks.ymlmain pushACR 빌드 → AKS kubectl set image
docs-deploy.ymlPR · main pushdocs-site 빌드 검증(PR) → 프로덕션 SWA 배포(main push)
beta-log-monitor.ymlcron 6h베타 로그 분석 → GitHub 이슈 (Slack 미발송, #3275)
autofix-claude.ymlissue labelClaude CLI 기반 자동 PR
release.ymlvX.Y.Z tag push정확 태그 이미지 4종 + GitHub Release (ADR-0036 Phase 1)

릴리스 (태그 트리거, v1.1.0+)​

main 상시 배포(-dev. 태그)와 별개로, 릴리스는 annotated tag push 로 확정합니다:

# 사전 조건: VERSION bump PR 머지 + release-notes.md 에 "## vX.Y.Z (YYYY-MM-DD)" 섹션 존재
git tag -a vX.Y.Z -m "GenD vX.Y.Z"
git push origin vX.Y.Z

release.yml 이 수행하는 것:

  1. 검증 — 태그 ↔ 루트 VERSION 일치, sync_version.py --check, 릴리스 노트 섹션 존재(scripts/extract_release_notes.py — 없으면 릴리스 실패)
  2. 빌드 — gend-api / gend-ui / gend-pipelines / gend-relay 를 정확 태그 vX.Y.Z 로 빌드·ACR push (api 는 빌드 메타데이터 build-arg 주입 + import smoke)
  3. GitHub Release 생성 — 본문 = 릴리스 노트의 해당 버전 섹션

릴리스는 배포하지 않습니다 — AKS prod 반영은 main 머지의 docker-build.yml 경로, 온프렘 반영은 업그레이드 절차 를 따릅니다. 리허설은 workflow_dispatch (dry-run — push/Release 생성 없음)로 실행합니다.

배포 안전장치​

  • CI 통과 후 머지 — gh pr merge --auto 권장 (--admin 직접 사용 금지)
  • ACR 이미지 태그 — <VERSION>-dev.<YYYYMMDD>-<sha7> (루트 VERSION 파일 파생, ADR-0036). latest 도 병행 push 되지만 배포는 항상 불변 태그로 kubectl set image
  • kubectl apply 주의 — deployment.yaml 적용 시 ACR 이미지 태그가 placeholder로 리셋되는 사례 있음 (참고: feedback 메모)
  • 베타 로그 모니터 — 6시간마다 실행하며 7시간 창의 ERROR 패턴을 수집·분류한다. 창이 실행 간격보다 넓은 것은 의도다 — GitHub Actions 의 schedule 은 지연되므로 창 == 간격이면 그 사이가 어느 실행에도 안 잡힌다 (실측 간격 최대 6.64h, #3275). 결과는 GitHub 이슈로만 발행된다. Slack 사본은 같은 내용의 중복이라 제거했다 — 즉 이 탐지는 push 가 아니라 pull 이다. 이슈 목록을 주기적으로 볼 것.

관련 문서​