CI/CD

 

소프트웨어 개발에서 유지보수로 연결되는 지점은 소스관리, 빌드, 배포의 활동이 됩니다. 물론, 소스코드 수정이 발생되기는 하지만, 소스관리/빌드/배포의 활동이 주로 발생하기 마련이며, 이는 유지보수 시점에 확실한 절차와 방법을 필요로 합니다. 오래 전부터 소프트웨어 개발에 있어서 위험을 줄이는 방식으로 개발 시점에서 이러한 활동을 지원하는 CI (Continuous Integration)가 사용되고 있었습니다. CI란 개발자가 각각 개발한 소스코드를 모아서 한꺼번에 빌드하는 통합 빌드의 과정을 특정 시점이 아니라 주기적으로 수행함으로써 통합에서 발생하는 오류를 사전에 해결하고 이러한 과정들에 소요되는 시간을 줄이기 위한 기법을 말합니다. 더 이상 빌드는 컴파일만을 의미하지 않으며, 소프트웨어가 거대해지고 복잡해지면서 팀 단위로 개발을 하게 되었고, 그 과정에 있어서 분업과 협업은 필수적이 되었습니다. 이 과정에서 소스 버전 관리 툴을 이용한 소스 코드의 merge 과정은 점점 까다로워져 도입한 솔루션이 바로 CI입니다 

 

 

CI/CD (Continuous Integration / Continuous Delivery or Deployment)란?

 

1. 지속적으로 퀄리티 컨트롤(품질 관리)을 적용하는 프로세스를 실행하는 것

 

2. 모든 개발을 완료한 뒤에 컬리티 컨트롤을 적용하는 고전적인 방법에 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 

    걸리는 시간을 줄이는데 초점

 

3. 초기에 그리고 자주 통합해서 통합 시 발생하는 여러가지 문제점을 조기에 발견하고, 피드백사이클을 짧게 하여 소프트웨어 개발의 품질과 

    생산성을 향상시키는 것.

 

 

CI 적용 시 고려할 점

 

1. 모든 소스 코드가 살아있고(현재 실행되고) 어느 누구든 현재의 소스를 접근할 수 있는 단일 지점을 유지할 것

 

2. 빌드 프로세스를 자동화시켜서 어느 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것

 

3. 테스팅을 자동화시켜서 단일 명령어를 통해서 언제든지 시스템에 대한 건전한 테스트 수트를 실핼할 수 있게 할 것

 

4. 누구나 현재 실행 파일을 얻으면 지금까지 최고의 실행파일을 얻었다는 확신을 하게 만들 것

 

 

 

CI/CD의 차이점

 

어디까지 자동화가 되어있느냐에 따라 달라집니다. 빌드 서버로 코드를 푸쉬 한 후 자동으로 빌드가 시작 되는 지점까지는 CI라 하며, 거기서 테스트를 거쳐 디플로이 과정까지 자동화가 되어있으면 CD라 한다 CD에서 또한 Deploy를 자동으로 해주냐, 수동으로 해주냐에 따라 Delivery, Deployment로 나뉘어집니다.

 

 

 

 

CI 시스템 구축을 위한 핵심 구성요소

 

1. CI Server : 빌드 프로세스를 관리하는 서버 

   ex) Jenkins etc..

2. SCM(Source Code Management)  :  소스코드 형상 관리 시스템

   ex) Git, SVN etc..

3. Build Tool : 컴파일, 테스트, 정적 분석 등으로 동작 가능한 소프트웨어를 생성하는 도구 

   ex)Maven, Gradle, Ant etc..

4. Test Tool : 작성된 테스트 코드에 따라 자동으로 테스트를 수행해주는 도구 

   ex) JUnit etc..

 

 

 

CI 자동화 수행 절차

 

1. 소스코드를 바이너리 파일로 컴파일 한다.

 

2. 바이너리 파일을 배포 형태로 패키징 한다.

 

3. 단위 테스트를 수행한다.

 

4. 정적 분석을 수행한다.

 

5. 분석 결과를 리포팅 한다.

 

6. 패키징한 파일을 테스트 서버에 배포한다.