CI/CD에 대해

간단한 CRUD API를 배포한다고 가정해보자. 일반적으로 아래와 같은 과정으로 제작 및 배포를 진행할 것이다.

API 작성 ->  빌드 -> 테스트(단위, E2E, 통합) -> 배포

 

위 과정은 모두 사람이 수기로 해도 별 영향이 없다. 하지만 사람들은 왜 CI/CD라는것을 도입할까? 위 과정을 기준으로 어떠한 과정에서 CI와 CD가 활용되는지 알아보자.

 

CI

CI란 Continuous Integration의 약자이다. 흔히 지속적 통합이라고 부르며, 위 과정에서 세가지 단계의 관점에 대한 개념으로 짧게 말하면 빌드&테스트 자동화이다.

API 작성 ->  빌드 -> 테스트(단위, E2E, 통합)

 

우리는 git 혹은 svn을 사용하여 소스코드의 버전관리를 진행한다. 그리고 소스코드를 Github, Gitlab등 원격 저장소에 올리게 된다. CI가 의미하는 "지속적 통합"은 이 원격 저장소에 코드를 통합하는 상황에 대해 이야기를 하는것이다. CI가 필요한 대표적인 상황을 살펴보자

 

위 상황에서 3명의 사람이 협업한다는 추가 가정을 해보자. 협업할때 되게 오랜기간동안 작업을 하고 한번에 Merge를 하게 된다면 Merge Conflict가 일어날 가능성은 높아진다. 만약 Merge Conflict가 발생하게 된다면 이를 해결하는데 드는 시간적, 인적 자원이 낭비되게 된다. 

 

이러한 문제점을 억제하기 위해서는 짧은 기간내에 작업 후 지속적인 Merge를 해야한다. 그리고 Merge를 하기 전에 작업한 내용이 잘 동작되는지에 대한 검증을 해야하므로 테스트는 필수이다. 하지만 사람도 가끔 실수를 한다. 테스트를 깜빡하고 병합을 진행할 수 있으며, 테스트를 일일히 진행하기에는 생각보다 많은 시간이 소요된다.  만약 Development, Production 브랜치 각각에 Merge를 하기위해서 아래 과정을 거쳐야한다고 가정하자.

컴파일 통과
단위테스트 통과
E2E테스트 통과

 

CI를 설정한다면, 특정 브랜치에 대해 PR을 열었을때 위 테스트를 모두 자동으로 진행되게 되며, 통과하면 Merge가 가능하도록, 통과하지 못하면 Merge를 못하도록 처리한다. 사람이 일일히 테스트를 실행하는 번거로움이 많이 줄어들게된다. 

CI가 적용되면 프로젝트를 진행하면서 여러번의 Merge가 발생되더라도 테스트 후 빌드가 모두 자동화되어 훨씬 안전하고, 활발환 운영이 가능해진다.

 

CD

CD란 Continuous Delivery를 의미하며 위 과정들중 배포의 관점이다. 다른 말로 지속적인 서비스 배포 또는 제공을 의미한다. 위에서 보았던 CI과정이 완료되어 Development, 혹은 Production 브랜치에 Merge가 되면 자동으로 변경사항이 감지된다. 이전 단계에서 문제가 없는경우 변경사항이 적용된 애플리케이션이 각각의 환경에 배포되는것을 의미한다.

사람이 수동적으로 서버에 접속하여 기존 애플리케이션 프로세스를 종료하고 다시 배포를 진행한다면, 이로 인해 오류 발생의 위험이 있으며, 실사용중인 서비스라면 이는 애플리케이션 만족도 혹은 수입측면에까지 영향을 줄 수 있다. 무엇보다 가장 큰 문제는 시간적인 자원도 많이 소모된다는것이다.

CD를 사용한다면 이러한 위험 요소 없이 안전하게 배포가 가능하며, 시간, 인적 자원에 대한 절약이 가능하다. 또한 사용자는 지속적으로 서비스를 사용할 수 있게된다.