GitHub Actions는 성공했는데 배포만 실패할 때 점검 순서

CI/CD 배포 문제의 출발점은 “초록불이 어디까지를 보장하나”다

파이프라인이 성공했다는 건 스텝이 0으로 끝났다는 뜻일 뿐, 새 버전이 실제로 떠서 트래픽을 받는다는 보장이 아니다. 배포 트러블슈팅은 어느 단계까지가 실제로 검증됐는지를 가르는 데서 시작한다.

빌드 → 테스트 → 이미지 푸시 → 배포 → 검증(rollout). 흔한 사각지대는 마지막 두 단계다. 배포 스텝이 apply만 하고 결과를 안 기다리면, 새 버전이 기동에 실패해도 파이프라인은 성공으로 끝난다.

kubectl rollout status deploy/<name> --timeout=120s   # 이 게이트가 없으면 초록불이 거짓말을 한다

같은 태그(:latest)를 재사용하면 “무엇이 배포됐는지”가 모호해지고, 노드가 옛 이미지를 캐시해 반영이 안 된다. 이미지는 커밋 SHA나 digest로 고정해 “이 커밋 = 이 이미지 = 이 배포”가 1:1로 추적되게 한다.

러너의 kubeconfig context, 대상 namespace, 주입되는 secret이 의도와 다르면 “성공했는데 엉뚱한 곳에 반영”된다. 배포 전에 context와 namespace를 명시적으로 출력·고정한다.

배포가 나빠졌을 때 kubectl rollout undo 한 번으로 이전 리비전으로 돌아갈 수 있어야 한다. 롤백 경로가 없으면 장애 시간이 길어진다.

단계 구분 → rollout status 게이트 → 불변 아티팩트 → context/namespace 고정 → 롤백 경로. “왜 CI는 성공했는데 반영이 안 됐지”의 답은 대부분 검증 게이트의 부재다.