CI/CD?
CI/CD는 Continuous Integration과 Continuous Deployment/Delivery 를 합친 말이다.
CI는 애플리케이션에 대한 코드 변경 사항을 정기적으로 빌드 및 테스트하여 공유 리포지토리에 통합한다. 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 발생하는 충돌 문제를 해결할 수 있다.
지속적 제공(Continuous Delivery)은 개발자가 애플리케이션에 적용한 변경 사항이 리포지토리에 자동으로 업로드 되는 것을 뜻한다. 운영팀은 이 리포지토리에서 애플리케이션을 실시간 배포할 수 있다.
지속적 배포(Contunuous Deployment)는 애플리케이션 변경 사항을 리포지토리에서 고객이 사용 가능한 production 환경까지 자동으로 릴리즈 하는 것을 의미한다. 이를 통해 운영팀의 프로세스 과부하 문제를 해결한다.
그래서 CI/CD는 뭐라는거지?
CI/CD는 지속적 통합 및 지속적 제공의 구축 사례만을 지칭할 수도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미할 수 도 있다.
결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적 자동화와 모니터링을 추가하는 것을 의미한다. 이 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라진다. 대부분의 경우 CI를 먼저 추가한 다음 배포 및 개발 자동화를 구현한다.
CI
현대적인 애플리케이션 개발에서는 여러 개발자들이 동일한 애플리케이션의 각기 다른 기능을 농시에 작업할 수 있도록 하는 것을 목표로 한다. 그러나 조직에서 merge day를 정해 모든 분기 소스 코드를 병합하는 경우, 반복적인 수잡업으로 인해 많은 시간을 소모하게 된다. 반복적인 수작업을 하는 이유는 merge conflict 발생 가능성이 항상 존재하기 때문. (우리 팀이 하고 있는 방식)
CI 프로세스를 통해 코드 병합 과정을 수월하게 수행할 수 있다. 개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 자동화 테스트를 실시한다. 이를 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인한다. 다시 말해, 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행한다. CI는 이러한 일련의 과정을 통해 버그를 더 빠르게, 자주 수정할 수 있다.
CD(지속적 제공)
지속적 제공의 프로세스에서는 유효한 코드를 리포지토리에 자동으로 릴리즈한다. 효과적인 CD(delivery) 프로세스 실현을 위해서는 CI가 먼저 구축되어 있는 것이 좋다.
CD(지속적 배포)
지속적 제공의 확장된 형태인 지속적 배포는 애플리케이션을 프로덕션으로 릴리즈하는 작업을 자동화한다. 프로덕션 이전의 파이프라인 단계에는 수동 작업이 없으므로, 지속적 배포가 제대로 이루어지려면 테스트 자동화가 제대로 설계되어있어야 한다.
실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 자동으로 실행할 수 있는 것을 의미한다. 결과적으로 CI/CD 적용 사례는 애플리케이션 배포를 작은 단위로, 지속적으로 수행한다. 따라서 애플리케이션 배포 중 발생할 수 있는 문제를 줄일 수 있다.
느낀 점?
현재 우리 프로젝트는 아날로그로 서버를 업데이트하고 있다...... 파일질라로 소스코드 업데이트.... CI/CD를 단순히 배포 자동화정도로 알았는데 생각보다 준비해야 할 것이 많아보인다. 우리는 심지어 모듈 테스트도 진행 안 했는데!!!
CI/CD는 단순히 개발 편의성을 위한 것이 아닌 그 이상의 의미를 가지는 것 같다.
