[회고] 09/08 회고 CI와 CD

새로운 프로젝트를 시작하면서 이전 프로젝트에서 진행했던 부분을 자체 피드백하고자 한다.

현재 CI/CD를 구축하고자 하는데,

이전에 나는 CI/CD를 어떻게 구축했을까?

아니, CI/CD에 대해서 어떻게 이해하고 있었을까?

 

지금의 생각은 이렇다.

CI  => 지속적인 통합

CD => 지속적인 배달, 지속적인 배포

 

크게 생각하지 않았고, CI를 통해서 도커 이미지를 빌드하고,

CD를 통해서 배포된 이미지를 배포했다.

 

조금 더 정확하게, 배포된 이미지를 docker-hub에서 다운로드 받아서,

이를 docker-compose를 통해서 배포했다.

 

과연 이게 전부일까?

 

일부 사실이고, 많이 부족하다고 생각한다.

그렇게 생각하는 이유는 목적을 위해서 사용했기 때문이라 생각한다.

 

조금 더 솔직하게 말하자면 내게 있어 CI/CD는 "commit, MR(PR) 후 배포된 결과를 보는 자동화 방식"이라고 생각한다.

 

하지만 이게 전부일까?

 

조금 더 정리해보고 아쉬웠던 점을 트래킹 해보자.

 

한번은 이런 일이 있었다. 

단위 테스트가 통과하지 못한 코드가 파이프라인을 지나 배포되려 했었다.

이를 젠킨슨이 이미지를 빌드하던 과정에서 발견해서 멈추었고, 빌드에 실패하였다.

 

이 때는 빠르게 확인해보고 싶었기 때문에, 빌드시 멈추는 이 방식을 그만두었고, 테스트 코드의 의미를 잃어버렸다.

많이 아쉬웠고, 조금 불편했지만(이렇게 무시해버린다는 사실이 많이 잘못되었다고 생각했다) 그래도 빠르게 개발해 나가야하는 상황이였기 때문에 무시해버렸다.

 

이런 상황이 조금씩 더 겹치고, 다른 CI를 더 깊게 적용했어야 하는 부분에서 어느정도(혹은 많이) CI의 목적을 많이 잃었다고 생각했다.

 

그렇다면 다시 돌아와서 CI/CD는 무엇일까?

 

CI는 테스트와 빌드 자동화이다.

자동으로 테스트 해서  단위에 문제가 없는지, 통합테스트를 통해서 conflict는 없는지 확인한다.

그리고 자동으로 이를 이미지를 빌드한다.

그리고 어쩌면 다시 cd에게 tirgger를 주거나, 이어서 CD 작업을 한다.

 

CD는 약간 복잡한데,

지속적인 전달, 지속적인 배포를 함께 뜻한다.

지속적인 전달의 경우 이를 스테이징 환경(실제 환경과 비슷하거나 같은 환경)에서 마지막 QA를 거친 후 수동배포 할 수 있는 상황,

지속적인 배포의 경우 바로 변경사항을 적용해서 실시간으로 서버에 적용하는 일.

 

이번에는 쿠버네티스를 선택한만큼 CI와 CD를 구분해서 사용해보고자 한다.

CI는 젠킨스, CD는 Argo를 통해서

 

그 이유는 다음 회고때 자세히 서술해보겠다.