CI지속적 통합는 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것이라고 정의가 쓰여있습니다. 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어서 하나의 레포지토리로 관리되는 것을 의미합니다.
SCMSource Code Management의 과정도 CI에 속합니다.
Git을 사용해 Github 레포 하나로 여러명의 개발자가 소스코드를 올리고 충돌을 처리하는 모든 과정도 CI에 속합니다.
Git이 아닌 SVN도 마찬가지입니다.
빌드 후 작성된 테스트 코드를 통해 유효성을 검증하는 것도 CI에 속합니다.
아주 간단한 예시로 Pull Request를 생성했을 때, 소스코드가 Conflict나는 경우 Merge 버튼이 비활성화 되는 경험을 해보셨을 겁니다. 그것 또한 유효성 검사에서 실패한 것으로 CI에 속합니다.
더 나아가, CI 툴을 사용해 소스코드가 컨벤션에 준수하는지 등을 체크하는 린터linter로 검증을 하도록 할 수 있는 등 다양한 일이 가능합니다.
CI를 하면 뭐가 좋은가요?
지속적 통합을 하게되면 소스코드는 항상 Ready-to-run 상태(배포가 가능한 상태는 아닙니다.)가 됩니다. 즉, 중간에 누군가 합류를 해도 빌드가 되는 코드를 받을 수 있습니다.
혼자서 개발할 때는 이런 문제를 겪어보지 못해서 중요성을 체감하지 못합니다.
하지만, 회사 프로젝트나 오픈소스 프로젝트 등 여러명이서 개발을 하는 상태라면 이 문제는 더욱 중요해집니다.
중간에 합류해서 새로운 기능을 개발하려고 하는데 누군가 작업하고 있는 코드가 아직 공유 레포upstream에 올라가 있어서 빌드가 안된다.
이런 경우가 발생하면 그 사람과 얘기해서 해결하던가, 직접 소스코드를 보고 돌아가도록 디버깅을 하던가 해야합니다. 하지만, 이 자체로도 시간이 소요되므로 생산성이 매우매우 떨어지게 됩니다.
게다가, 특정한 날을 정해서 각자 개발한 소스코드를 병합하도록 하게되면 그에 따르는 많은 시간을 소모하게 됩니다.
만약, 기존 코드와 Merge한 코드가 에러가 난다면 이를 처리하는 과정에도 많은 시간이 소요될 것입니다.
항상 양질의 코드 퀄리티를 유지할 수 있습니다.
테스트의 자동화를 이루게되면 항상 테스트 코드를 통과하는 코드만 공유 레포에 올라갈 수 있기 때문에 상당한 퀄리티의 소스코드로 유지되게 됩니다.
CD란?
CD는 지속적 제공Continuous Delivery과 지속적 배포Continuous Deployment를 모두 의미합니다.
지속적 제공Continuous Delivery : CI 과정이 모두 끝난 뒤 유효성 검증이 된 코드를 레포지토리에 올리는 것을 자동화합니다. (프로덕션 레벨로 배포하는 것과는 별개입니다.)
항상 프로덕션 레벨로 배포할 수 있는 준비가 되어있는 소스코드를 자동으로 올라갈 수 있도록 합니다.
지속적 배포Continuous Deployment : CI/CD 과정의 마지막 단계입니다. 지속적 제공을 통해 배포 가능한 소스코드를 프로덕션 레벨로 릴리즈하는 것을 의미합니다.
실제 사례에서 지속적 배포는 개발자가 애플리케이션을 수정한 뒤 몇 분 이내에 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다.
CD를 하면 뭐가 좋은가요?
개발부터 배포까지 과정이 번거롭지 않고 간소화 되기 때문에 사용자 피드백을 빠르게 반영할 수 있습니다.
장애 대응이 빨라집니다. 릴리즈를 했는데 굉장히 크리티컬한 이슈가 발견되었을 때, 개발부터 배포까지의 과정이 복잡하면 반영에 오래걸리게 됩니다.
만약, 로드밸런서로 수십대의 서버를 동시에 운용한다면?
자동화를 하지않으면 직접 서버에 들어가서 일일이 실행해야하기 때문에 하루종일 배포를 할 수도 있습니다.
