CI(지속적통합) CD(지속적제공, 지속적배포)란

📌 CI / CD 란?

애플리케이션 개발 단계에서 배포 단계까지 모든 단계를 자동화해서 조금 더 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있도록 만드는 것을 의미한다.

 

📌 CI (Continuous Integration  :: 지속적 통합)

CI는 지속적 통합이라는 뜻으로 개발을 진행하면서도 품질을 관리할 수 있도록 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다.

지속적 통합 = 버그 수정이나 새로 만드는 기능들이 메인 리포지토리에 주기적으로 빌드되고 테스트 되어서 병합(merge) 되는 것

 

CI는 두가지 포인트로 잡고 생각하면 좋다.

 

1. 개발자들은 그들의 코드 변경사항을 메인 리포지토리에 주기적으로 빈번하게 병합(merge)해야 한다.

동일한 소스파일을 위해서 여러 명의 개발자가 서로 다른 코드를 작성하고 있고 오랜 기간 서로 변경을 하다가 나중에 병합(merge)을 하려고 하면 서로 다른 코드를 어떻게 통합해서 적용해 나갈 건지 고생을 하게 될 것이다. 이렇게 되면 새로운 기능을 개발하기 위해서 코드를 작성하는 시간보다 머지 충돌을 해결하기 위해서 더 많은 시간을 사용해야 할 수도 있다. 그렇기 때문에 버그를 수정하거나 또는 새로운 기능을 구현할 때 더더욱 어떻게 작은 단위로 나누어서 내가 메인 리포지토리에 반영하거나 또는 작은 단위로 나눠서 내가 사용자에게 배포할 수 있을지 최대한 작은 단위로 나누어서 개발하고 통합해 나가는 것이 중요하다.

 

2. 통합을 위한 단계(빌드, 테스트, 병합)의 자동화

주기적으로 병합(merge)된 이 코드의 변경사항이 자동으로 빌드가 되어서 코드 변경 사항 이후에도 빌드가 성공적으로 되는지 확인이 되어야 하고 새로 추가된 이 코드의 변경사항뿐 아니라 기존 시스템의 다른 버그를 초래하지는 않는지 자동으로 테스트까지 되어야 한다.

개발자들은 메인 리포지토리에 주기적으로 코드의 변경사항을 병합한다. 병합이 되면 CI 스크립트를 통해 추가된 코드와 함께 리포지토리가 빌드되고 빌드에 이상이 없다면 팀에서 작성한 단위테스트, 통합테스트 등 여러 가지 테스트를 스크립트를 진행한다. 빌드도 이상 없고 테스트에도 이상이 없으면 Green이라는 초록색 사인이 나오면 무사히 통과가 되어 배포할 때 반영이 될 수 있다. 하지만 새로 추가된 코드에 문제가 있어서 빌드 또는 테스트에 실패하면 Red라는 빨간색 사인이 나오고 자동으로 개발자에게 피드백을 해준다.

 

이렇게 CI 원칙을 따라가면 어떠한 장점이 있을까?

1. 주기적으로 병합으로 병합 충돌을 피할 수 있어서 개발에 생산성을 높힐 수 있다.

2. 병합되는 코드들은 자동으로 빌드 → 테스트 되기 때문에 코드의 결함이나 문제점이 빠르게 발견하고 수정 할 수 있다.

3. 주기적으로 병합을 위해 코드의 변경사항이  작기 때문에 문제를 수정할 때도 조금 더 고립된 작은 단위의 문제를 해결할 수 있다.

4. CI를 잘 운영하기 위해서 테스트를 꼭 포함하기에 안정적이고 높은 코드의 퀄리티를 가질 수 있다.

 

참고 : 마틴파울러가 제시하는 CI의 4가지 규칙
- 모든 소스코드는 살아있고 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
- 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드할 수 있게 할 것
- 테스팅을 자동화해서 언제든지 시스템에 대한 건전한 테스트 슈트를 실행할 수 있게 할 것
- 누구든 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 얻게 할 것

 

CI를 통해 코드의 통합을 이뤄냈으니 배포만 하면 사용자들은 본인들이 원하는 요구사항을 만족할 수 있을 것이다.

 

현재 서비스가 작아 1대의 서버에만 배포하면 된다고 가정해 보자.

이때 서버에 접속하여 직접 배포 스크립트를 수동으로 실행시켜 주면 큰 문제가 없어 보인다. 하지만 서버의 규모가 커져 서버가 수십, 수백대로 늘어났다고 가정해 보면 모든 서버에 일일이 접속해 배포스크립트를 수동으로 실행시킨다는 것은 굉장히 어려운 작업일 것이다. 그래서 CI의 연장선의 개념인 CD라는 개념이 등장한다.

 

 

📌 CD(Continuous Delivery : 지속적 제공, Continuous Deployment  : 지속적 배포)

CD는 지속적 제공과 지속적 배포라고 불리며 지속적 제공과 지속적 배포 모두 마지막 배포단계에서 자동화를 통해 배포를 만들어 낼 수 있을지를 고민하는 단계이다.

지속적 제공은 CI를 통해 릴리즈할 준비과정을 거치고 준비된 릴리즈가 정상인지 문제가 없는지 직접 검증한뒤 수동적으로 배포하는 것이다.

지속적 배포는 CI를 통해 릴리즈할 준비과정을 거치고 준비된 릴리즈를 자동으로 배포하는 것이다.

비슷하지만 빌드의 결과물을 프로덕션으로 릴리즈하는 작업을 어떻게 수행하냐에 따라 다르다고 할 수 있다.

 

 

📌 CI/CD라고 불리는 이유

회사마다 어느정도의 자동화를 하냐가 다르기 때문에 CI/CD라고 해서 똑같은 프로세스를 거치는 것은 아니고 회사마다 또는 팀마다 다른 방식으로 적용해서 사용할 수 있다.

CI와 CD가 완벽히 분리된 것이 아니라 대부분의 회사에서 CI와 CD를 거쳐서 배포를 하기 때문에 CI/CD라고 묶어서 불린다.

 

 

📌 CI/CD 파이프라인 정리

개발자가 작은 단위로 기능을 나누어서 개발 후 병합을 하면 자동으로 빌드를 하고 테스트 과정을 거쳐서 릴리즈 준비가 된다.(CI)

여기서 수동적으로 또는 자동적으로 배포를 거치게 된다.(CD)