CI (Continuous Integration)

CI는 간단히 요약하자면 빌드/테스트 자동화 과정 과정이다.
CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.

CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로,

여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

CD (Continuous Delivery / Deployment)

CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다.

두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

지속적인 제공(Continuous Delivery)
이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있다.

이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해 준다.

지속적인 제공은 귀찮은 push 작업없이 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.

지속적인 배포(Continuous Deployment)
란 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미한다.

이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다.

지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 제공이 가진 장점을 활용한다.

CI / CD 장점

CI / CD를 실천하면 개발, 테스트, 운영 모범 사례에 팀을 맞춤으로써

다음과 같은 실질적 혜택도 얻을 수 있다.

• 변경 사항을 자주 푸시하고자 하는 개발자와 안정적인 애플리케이션을 원하는 운영 담당자 사이의 마찰을 해결한다.
• 코드 변경을 사용자에게 푸시하기 전에 검증하기 위해 개발 팀은 지속적인 테스트를 실행해야 한다.
• 큰 변경보다 안정적으로 통합 및 테스트가 가능한 더 작은 규모의 증분적 코드 변경을 수행하도록 개발자를 독려한다.
• 새로운 기능을 위한 더 넓은 범위의 개발 작업을 수행하는 동시에 신속한 수정 요청까지 받는 팀에 작업의 유연성을 부여한다.
• 기능, 성능 및 데이터 중심 테스트를 더 많이 실행해서 더 높은 품질의 애플리케이션을 제공하고 프로덕션 결함을 줄일 수 있게 해준다.

CI/CD 종류

• Jenkins
• CircleCI
• TravisCI
• Github Actions

CI/CD 적용 전과후 비교

CI/CD를 적용하기 전의 고전적인 코드 통합 과정을 생각해봅시다.

1. 개발자들이 개발하여 코드를 수정합니다.
2. 각자의 feature 브랜치에 코드를 push합니다. (but, 어느 한 부분에서 에러가 났지만 개발자들은 눈치채지 못합니다.)
3. 각자의 코드를 git에 올리고 통합(Intergration)합니다.
4. 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어디부분에 에러가 있는지 디버깅하고 코드를 수정합니다.
5. (1) ~ (4)의 과정을 반복합니다.
6. 많은 시간을 할애하여 에러가 해결되었으면 배포를 시작합니다. 하지만 배포과정 또한, 개발자가 직접 배포과정을 거치므로 많은 시간을 소요합니다.

코드의 양이 적다면 조금만 시간을 할애해도 에러를 찾아낼 수 있지만, 코드의 양이 많다면 에러 추적이 안되므로 어마어마한 양의 디버깅 과정을 마주하게 될 수도 있습니다.

CI/CD를 적용 후의 과정
(이 과정은 하나의 예시일 뿐 다르게 변경할 수 있습니다. 예를 들면 중간에 PR과정을 추가할 수 있고, sonarqube나 lint를 돌린다던지, git tag를 통해 Deploy를 Trigger 시킬 수 있습니다.)

1. 개발자들이 개발하여 feature브랜치에 코드를 push합니다.
2. git push를 통해 Trigger되어 CI서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송합니다.
3. 개발자들은 결과를 전송받고 에러가 난 부분이 있다면 에러부분을 수정하고 코드를 master 브랜치에 merge합니다.
4. master 브랜치에 코드를 merge하고 Build, Test가 정상적으로 수행이 되었다면 CI서버에서 알아서 Deploy 과정을 수행합니다.

CI/CD Pipeline(파이프라인)

다음 다이어그램은 CI/CD 파이프라인 단계를 자세히 보여준다. 파이프라인이라고 하는 이유는 이러한 배포 자동화 과정들이 물 흐르듯 흘러가는 것을 묘사해서 그렇게 부르게 된다.

파이프 라인이란?
컴퓨터 과학에서 데이터 파이프 라인 (일반적으로 파이프 라인이라고 함)은 제공된 데이터 또는 코드에 대해 사전 정의 된 작업을 수행하는 일련의 처리 단계다.

파이프 라인 사용의 목적은 반복적 인 프로세스를 자동화하여 시간을 절약하고 정밀도를 높이는 것이다.

파이프 라인의 이러한 장점은 CI / CD 인프라와의 호환성과 효율성을 높여준다. 특히 CI / CD 파이프 라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계를 수행할 수 있다.

CI / CD 파이프 라인 구성 요소

• 빌드 (소프트웨어 컴파일),
• 테스트 (호환성 및 오류 검사)
• 릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
• 배포 (개발에서 프로덕션 환경으로의 변환)
• 규정 준수 및 유효성 검사

CI / CD 파이프 라인 목표는 빌드, 테스트 및 제공을 수동 처리보다 더 빠르고 자동화되고 안정적으로 만드는 것이다.

참고
https://inpa.tistory.com/entry/%F0%9F%91%A9%E2%80%8D%F0%9F%92%BB-CI-CD-%ED%8C%8C%EC%9D%B4%ED%94%84-%EB%9D%BC%EC%9D%B8-%EC%9D%B4%EB%9E%80
https://seosh817.tistory.com/104