[CI/CD] CI/CD란

CI (Continuous Integration)

간단히 요약하자면 빌드/테스트 자동화 과정이며, CI/CD 파이프라인을 구현하기 위한 첫 번째 단계이기도 하다.

개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.

CI를 성공적으로 구현할 경우 새로운 코드 변경 사항이 정기적으로 빌드/테스트되어 공유 리포지토리에 통합된다.

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

 

지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다. 커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다. 

 

CI는 2가지 방법이 있는데 이에 대해 알아보자.

 

1. 코드 변경사항을 주기적으로 빈번하게 merge

가능한 작은 단위로 나누어서 주기적으로 빈번하게 개발하고 계속해서 통합하여 나간다.

 

merge 과정 이후의 흐름

1. 개발자들은 형상관리 툴(github 등)에 작업한 코드를 통합한다
2. 통합한 코드가 제대로 동작하는지 빌드 및 테스트를 진행한다.
3. 버그가 생기면 다음날 해야 할 목록에 정리해두고 다음 날에 버그를 해결한다.

 

2. 통합 단계의 자동화

github에 코드만 올리고 나머지 작업인 테스트와 빌드는 프로그램이 자동으로 해주어 똑같이 반복되는 귀찮은 작업을 하지 않을 수 있고, 문제도 더 적어진다!

 

자동화를 사용한 이후의 흐름

1. 개발자들은 형상관리 툴(github 등)에 작업한 코드를 통합한다
2. 빌드 및 테스트는 자동으로 진행되므로, 버그가 생기면 다음날 온 버그를 확인해서 버그를 해결한다.

 

CI의 장점

• 코드의 검증에 들어가는 시간이 줄어든다.
• 개발 편의성이 증가한다.
• 항상 테스트 코드를 통과한 코드만이 repository에 올라가기에 좋은 코드 퀄리티를 유지할 수 있다.

 

CD (Continuous Deployment)

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

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

 

CI에서 Build되고 Test된 후에 배포 단계에서 release할 준비 단계를 거치고 문제가 없는지 수정할만한 것들이 없는지 검증한다.

사용자들에게 서비스를 제공해도 되겠다고 판단되면 배포를 수동적으로 진행하는 것이 지속적인 서비스 제공이고, 자동화를 통하여 배포를 진행하는 것을 지속적인 배포라 한다.

 

지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올린다. 

코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 해당 변경 사항이 프로덕션에 자동으로 배포된다. 

지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다.

 

또한 성숙하고 입증된 지속적 통합 및 전달 단계를 기반으로 하기에 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포된다.

 

CD를 적용한 후 흐름

1. CI를 적용하여 코드를 검증한다.
2. 배포 환경과 비슷한 곳에서 검증을 진행한다.
3. 검증된 소프트웨어를 실제 프로덕션 환경으로 배포한다.

 

CD의 장점

• 개발자는 배포보다 개발에 더 신경쓸 수 있도록 도와준다.
• 개발자가 원클릭으로 수작업 없이 빌드, 테스트, 배포까지의 자동화를 할 수 있다.

 

CI/CD 종류

• Jenkins
• CircleCI
• TravisCI
• Github Actions
• etc

 

CI/CD  적용 전후 비교

CI/CD를 적용하기 전

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

 

코드의 양이 적다면 조금만 시간 투자해도 에러를 찾아낼 수 있지만,

코드의 양이 많다면 곧바로 에러 추적이 안되므로 어마어마한 양의 디버깅 과정을 마주하게 될 수도 있다.

 

CI/CD를 적용 후

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

 

일일히 빌드와 테스트, 배포과정을 개발자가 직접한다는 것은 리소스낭비이고 심한 경우에는 업무의 대부분을 빌드와 테스트, 배포에 투자해야 할 수도 있다.

 

 

# 레퍼런스

SpringBoot Jenkins 배포 자동화 1

CI/CD란 무엇일까?