개요

Continuous Integration, Continuous Deploy
지속적 통합, 지속적 배포의 준말이다.
여기에서 CD는 경우에 따라 Continuous Delivery를 뜻하기도 한다.

지속적이라 표현하지만, 사실 자동화라는 측면이 강조된 개념이다.
자동으로 코드를 합치고, 자동으로 빌드를 배포하고.
수작업으로 하던 일을 줄이는데 그 의의가 있다.

DevOps 한 축을 이루는 개념

자동화에 대한 주의점

주의할 것이, CICD라고 해서 무조건 자동화라고 이해하면 안 된다.
모든 것을 자동화하는 것은 가능하다.
기술적으로 못한다고 이야기하는 사람이 있다면 그 사람의 역량을 의심해봐야 한다.
그러나 기술적으로 못하는 것을 떠나서 실제 서비스 운영 간에는 훨씬 다양한 고려사항과 문제가 도사리고 있다.
코드를 올렸어, 코드 빌드됐어, 빌드된거 배포했어, 근데 장애가 터졌어, 어쩔래? 책임은 누가 질래?
단순히 모든 것을 자동화시켜버리는 데에만 급급하면 오히려 발생하는 문제들을 대처하기 어렵고 책임 관계를 명확히 하기도 힘들어질 수 있다.
그래서 개발과 운영 사이 복잡한 워크플로우에서 핵심 결정이라는 행위 이외의 다른 것들을 자동화하는 것을 CICD의 핵심 개념이라고 이해하는 것이 좋다.

CI - 지속적 통합

지속적 통합은 개발 코드의 통합을 의미한다.
여러 개발자와 팀이 코드를 만들고 수정하는 작업을 거칠 것이다.
그러나 코드를 만든 것만으로 모든 게 끝나는 게 당연히 아니다!
이것이 실제 서비스가 되기 위해서는 빌드되고, 테스트를 거치는 등의 추가 작업이 필요하다.
이 작업들을 하나의 파이프라인으로서 인식하고 자동으로 플로우가 이어질 수 있도록 하는 작업이 바로 지속적 통합이다.

대략적인 흐름을 정리해봤다.
어떤 식으로 흐름을 잡을지, 전략을 세울지는 전부 운영 조직의 계획과 선택에 달렸음을 참고하자.

• a 개발자가 팀 레포 자신의 브랜치에 코드를 푸시한다.
• 푸시가 되는 순간 자동으로 코드 빌드 후 기능 테스트가 이뤄진다.
• 기능 테스트가 완료된 이후 알아서 메인 브랜치로 풀리퀘가 발생한다.
• 다른 개발자들이 리뷰를 한다.
• 리뷰 이후 수정사항이 있어 다시 푸시를 하면 이것 역시 기능 테스트가 이뤄진다.
• 책임자가 승인을 하면 메인 브랜치로 코드가 통합된다.
• 메인 브랜치 코드가 변화하면 자동 워크 플로우가 발동하여 버저닝을 넣어 빌드된 이미지가 이미지 레지스트리로 올라간다.
• 자동으로 이미지 취약점 스캔을 진행하고, 테스트 환경에 배포되어 서비스 테스트가 이뤄진다.

중간 중간 자동이라는 말이 들어가는데, 이런 것들을 하는 게 CI라고 보면 된다.

CD - 지속적 배포

두 가지 용어로 쓰인다고 했는데, 이 둘 간의 엄청난 차이가 있는 것은 아니다.
Continous Delivery라고 한다면 실제 운영 환경에 배포되기 이전까지의 과정을 통틀어 말하는 것이다.
Continous Deployment라고 한다면 실제 운영 환경에 배포되는 과정까지 통틀어 말하는 것이다.
이런 차이는 있지만 솔직히 그냥 부르기 나름이다 ㅋ

배포에 있어서도 몇 가지 플로우가 있다.
어느 곳에서는 코드의 통합까지만 CI라고 부르고 코드를 빌드하여 빌드물을 저장하는 것부터 CD로 보기도 한다.
당장 설명에서는 이미 만들어진 빌드물을 활용하는 단계부터 시작한다고 보고 설명하겠다.

• 빌드된 이미지를 테스트 환경에 배포하여 자동 테스트가 이뤄진다.
• 테스트가 완료되면 자동으로 운영자에게 알림이 간다.
• 어떤 변경 사항이 담긴 이미지냐에 따라, 운영자를 거치지 않고 바로 운영 환경으로 배포된다.
• 이때 배포는 배포 전략을 여러 개 둘 수도 있고, 하나만 둘 수도 있다.
• 이 배포 전략의 적용 역시 자동으로 이뤄진다.

참고