V1 CICD - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

목차 (펼치기/접기)

• #0. 문서 목적
  
• #1. V1 CI-CD 설계 원칙
  
• #2. 브랜치 전략과 배포 정책
  
• #3. CI 파이프라인
  
• #4. CD 파이프라인
  
• #5. 환경별 배포 전략(NonProd 자동, Prod 수동)
  
• #6. 아티팩트 저장 전략(S3)
  
• #7. 배포 알림(Discord)
  
• #8. SLI-SLO 연계
  
• #9. 운영 시나리오
  

본 문서는 Devths 서비스의 V1 CI/CD 파이프라인을 위키에 기록하기 위한 문서임.
V1에서는 GitHub Actions 기반 CI와 AWS CodeDeploy 기반 CD를 결합하여, 배포 속도와 운영 안정성의 균형을 달성하도록 설계함.
특히 NonProd는 자동 배포 중심으로 개발 속도를 확보하고, Prod는 수동 트리거로 배포를 통제하여 운영 리스크를 낮추도록 구성함.

V1 CI/CD는 “빨리 배포하기”보다 “배포해도 안전한 상태를 보장하기”를 우선 원칙으로 둠.
따라서 배포 전 단계에서 코드 품질을 검증하는 **품질 게이트(quality gate)**를 명확히 두고, 운영 배포는 승인 기반으로 통제함.
모든 배포는 아티팩트(S3) 단위로 기록되어 추적 가능해야 하며, 실패 시 운영자가 즉시 인지할 수 있도록 알림을 연동함.

V1은 브랜치 구조가 배포 정책과 직접 연결되도록 설계함.

• feat/*는 기능 개발 브랜치로 사용함.
  
• develop은 통합 개발 브랜치이며 NonProd 자동 배포 대상임.
  
• release는 배포 전 검증 브랜치이며 NonProd 자동 배포 대상임.
  
• main은 운영 브랜치이며 Prod 배포 대상임.
  
• hotfix/*는 긴급 수정 브랜치이며 필요 시 빠르게 상위 브랜치로 반영함.
  

이 구조를 통해 “개발은 빠르게, 운영은 안전하게”라는 목표가 브랜치 단에서 강제됨.

CI는 PR 및 Merge 시점에 실행되며, 배포 가능한 상태를 만드는 전처리 단계임.
CI의 목표는 코드 품질과 안정성을 보장하고, 배포 산출물을 표준화된 형태로 생성하는 것임.

코드 스타일 및 기본 품질을 빠르게 차단하기 위해 Lint 단계를 수행함.
프런트엔드는 ESLint/Prettier 중심으로, 백엔드는 프로젝트 정책에 맞는 Lint 체계를 적용함.

배포 전 보안 및 결함 가능성을 조기에 발견하기 위해 정적 분석을 수행함.
CodeQL 기반 분석을 통해 위험 패턴을 차단하고, 운영 환경 유입을 줄이는 것을 목표로 함.

기능 회귀를 방지하기 위해 테스트 단계를 수행함.
백엔드는 JUnit 기반 테스트를 실행하고, JaCoCo로 커버리지 지표를 확인 가능하게 함.
테스트 실패 시 이후 단계로 진행되지 않도록 하여 “깨진 코드가 배포되는 상황”을 원천 차단함.

CI의 마지막 단계에서 빌드를 수행하고, CodeDeploy가 사용 가능한 형태로 아티팩트를 패키징함.
아티팩트에는 실행 산출물뿐 아니라 appspec.yml 및 배포 스크립트가 포함되어 배포 재현성을 확보함.

CD는 “아티팩트를 실제 서버에 반영하는 단계”로, AWS CodeDeploy를 사용함.
CodeDeploy는 배포 단계별 로그를 남기고, 동일한 절차로 배포가 반복되도록 표준화하는 역할을 수행함.

• GitHub Actions가 S3에 업로드한 아티팩트를 CodeDeploy가 내려받음.
  
• appspec.yml에 정의된 훅 순서대로 배포 스크립트를 실행함.
  
• 배포 완료 후 애플리케이션을 재기동하거나 전환하여 반영함.
  

배포 결과는 CodeDeploy 이력으로 남아 “언제/무엇이/어디에 배포되었는지”를 추적 가능하게 함.

V1은 환경 특성에 따라 배포 방식을 분리함.

NonProd는 기능 검증이 핵심이므로 자동 배포를 적용함.
develop, release에 Merge되면 CI를 통과한 후 아티팩트가 생성되고, CodeDeploy로 자동 반영됨.

Prod는 서비스 안정성이 최우선이므로 자동 배포를 금지하고 수동 트리거 배포로 통제함.
main 반영 후 GitHub Actions에서 **workflow_dispatch(수동 실행)**로 배포를 시작함.
이를 통해 배포 타이밍을 운영자가 결정하고, 피크 타임 회피 및 점검 창 운영이 가능해짐.

수동 트리거 방식은 “원하지 않는 배포가 운영에 유입되는 사고”를 방지하는 장치로 동작함.

V1은 배포 재현성과 감사 추적을 위해 S3를 아티팩트 저장소로 사용함.

• NonProd용 아티팩트는 Artifact_Dev에 저장함.
  
• Prod용 아티팩트는 Artifact_Prod에 저장함.
  

환경별로 아티팩트를 분리하여 운영 환경이 개발 산출물을 참조하는 사고를 차단함.
또한 S3 객체가 “배포 버전”의 단위가 되어 롤백 및 배포 이력 추적이 쉬워짐.

배포 결과는 즉시 공유되어야 하므로 Discord 알림을 연동함.
GitHub Actions 또는 배포 후처리 단계에서 성공/실패 여부를 Discord로 전송함.
NonProd와 Prod 알림 채널을 분리하여, 환경별로 필요한 사람에게만 정보가 전달되도록 구성함.

NonProd 알림 보기 (펼치기/접기)

Prod 알림 보기 (펼치기/접기)

V1에서는 배포 품질을 운영 관점의 목표로 관리하기 위해 SLI/SLO와 CI/CD를 연결함.

지표 (SLI)	목표 (SLO)	측정 방법
배포 성공률	100%	GitHub Actions 성공 이력

배포 성공률을 명시적으로 관리함으로써 배포 안정성을 운영 지표로 끌어올리는 구조임.

개발자가 PR을 생성하고 develop 또는 release로 Merge함.
CI가 Lint/정적 분석/테스트/빌드를 수행하고, S3에 아티팩트를 업로드함.
CodeDeploy가 NonProd에 자동 배포하고, 결과를 Discord로 알림함.

검증 완료된 변경사항을 main에 반영함.
운영자가 GitHub Actions에서 수동 트리거로 배포를 실행함.
Prod 아티팩트가 S3에 업로드되고, CodeDeploy가 운영 서버에 반영함.
배포 결과가 Discord로 알림되어 운영자가 즉시 확인함.