CI CD Pipeline
3줄 요약
- CI/CD Pipeline은 코드 변경을 검증하고, 같은 산출물을 통제된 방식으로 배포하게 만드는 운영 장치다.
- 핵심은 “자동으로 배포된다”가 아니라 build, test, package, version, permission, deploy, verify 단계의 실패 지점을 분리하는 것이다.
- 백엔드 개발자는 Spring 테스트 결과, artifact 식별자, Secret 접근, 배포 승인, smoke test, 실패 재실행 기준을 설명할 수 있어야 한다.
핵심 정리
- CI는 코드 변경이 main branch에 들어가도 되는지 검증한다. CD는 검증된 산출물을 특정 환경에 반영하는 운영 변경이다.
- Build, test, package는 같은 입력에서 같은 산출물을 만들 수 있어야 한다. 로컬에서만 통과하는 빌드는 운영 신뢰도가 낮다.
- Artifact version과 image tag는 rollback, 장애 분석, 배포 이력 추적의 기준이다.
latest만 쓰면 어떤 코드가 운영 중인지 잃는다.
- Pipeline Secret은 로그, artifact, image layer, PR 권한을 통해 새어 나갈 수 있다. 최소 권한과 회전 가능성이 중요하다.
- 실패한 pipeline은 무작정 rerun하지 않는다. test flake, dependency 장애, 권한 오류, registry 장애, 배포 후 검증 실패를 분리한다.
- 배포 성공은 job 성공이 아니라 배포 후 health, 핵심 API, 오류율, latency가 기대 범위로 돌아온 상태다.
헷갈리는 지점
- CI가 초록색이면 운영 배포도 안전하다고 생각하기 쉽다.
- 핵심은 CI는 코드 검증이고, CD는 권한, 환경, Secret, 배포 후 검증이 추가되는 운영 변경이라는 점이다.
- tag만 있으면 버전 추적이 된다고 생각하기 쉽다.
- 핵심은 tag, git SHA, artifact checksum, image digest, 배포 환경이 함께 묶여야 재현 가능한 증거가 된다는 점이다.
- 실패한 pipeline은 다시 돌리면 된다고 생각하기 쉽다.
- 핵심은 재실행 전에 실패 단계와 입력 변경 여부를 확인해야 같은 문제를 숨기지 않는다는 점이다.
확인 질문
- CI와 CD를 분리해야 하는 이유는 무엇인가?
- 코드 검증 실패와 운영 변경 실패를 구분해야 권한, 승인, rollback, 배포 후 검증을 다르게 다룰 수 있기 때문이다.
- 운영 배포 artifact를 추적하려면 어떤 값이 필요한가?
- git SHA, build number, semantic version 또는 release tag, artifact checksum, container image digest, 배포 환경과 시간이 필요하다.
- 실패한 pipeline을 재실행하기 전에 확인할 것은 무엇인가?
- 실패 단계, 로그, 입력 commit, dependency 상태, Secret/권한 변경, 이전 성공 run과의 차이다.