CI/CD 개념

1. CI/CD 배경

• 전통적인 배포 파이프라인 단계는 다음과 같다.

1. Version control : 일반적으로 코드를 가지고 일을 하는 소프트웨어 개발자들은 코드 변경사항을 커밋한다.
2. Acceptance tests : 미리 컴파일/빌드된 코드에 대해 테스트 묶음을 실행한다.
3. Independent Deployment : 독립 배포는 컴파일되고 테스트된 아티팩트를 개발환경에 배포한다. 개발 환경은 이상적으로 프로덕트 환경과 아주 비슷해야 한다.
4. Production Deployment : 일반적으로 운영팀(Operations)이나 데브옵스팀에 의해서 다루어진다. 이것은 Independent Deployment 프로세스와 매우 유사해야 하고, 프로덕션 서버에 코드를 배포한다.
5. 이러한 기존 방식으로, 휴먼에러(Human error)가 발생할 수 있다. 지루하고 반복적인 작업을 수동으로 하게되면 발생할 수 있고 결국 잘못된 배포로 인해 영향을 미칠 수 있다.

• 소프트웨어가 거대해지고 복잡해지면서 팀 단위로 개발하게 되었고, 그 과정에서 분업과 협업은 필수가 되었다. 이 분업과 협업의 과정에서 코드의 Merge 과정은 까다롭고, 테스트하는데 큰 자원을 소비되게 된다. 이 문제를 해결하기 위해 도입되었다.
• 개발 브랜치가 일정 기간 이상 이용되면, 통합의 어려움은 커지고 충돌 해결에 들어가는 시간이 길어지고 오류 발생 위험이 커진다. 이러한 단점을 극복하고자 변동 내용의 반영 빈도를 늘리는 자동화가 등장하였다.
• 빌드와 기능성을 검증하는 새로운 방법을 확보하고 기능의 개발과 배치 속도를 큰 폭으로 개선하기 시작하였다.

2. CI/CD 정의

• CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법이다.
• 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포를 가능하게 한다.
• 새로운 코드의 통합으로 인하여 개발 및 운영팀에 발생하는 문제를 해결하는 솔루션이다.

2.1 CI (Continuous Integration)

• Build & Packaging
• 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 병합되는 것이다.
• Build, Test를 실시하는 프로세스를 말하며 이러한 통합 프로세스를 상시로 실시하는 것이다.
• 다수의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우, 서로 충돌할 수 있는 문제를 해결하기 위함이다.
• 언제든 최신 Build를 고객에게 바로 제공 가능하게 한다.

2.2 CD (Continuous Delivery) & (Continuous Deployment)

• Deployment
• 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드되는 것이다.
• 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것이다.
• 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포된다.
• 개발팀과 운영팀의 커뮤니테이션 부족 문제를 해결한다.

3. CI/CD 필요성

CI/CD 방법론을 적용함으로써 다음과 같은 이점을 얻을 수 있다.

• 모든 분기의 소스 코드를 병합하는 경우, 결과적으로 반복적인 수작업에 많은 시간이 소요된다.
• 병합하는 수작업을 하지 않는다면, 개발자가 애플리케이션에 변경 사항을 적용할 때 다른 개발자가 동시에 적용하는 변경 사항과 충돌할 수 있다.
• 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수 있다.
• 여러 사람이 작성한 코드가 병합되었을 때 생기는 문제를 미리 감지한다.
• System과 Application을 최대한 최신 상태로 유지할 수 있다.