CI & CD 에 대해 알아보자.

목차
1. CI/CD에 대해 알아보자.
2. CI/CD 연동 시 구조에 대해 알아보자.

 

1.

CI/CD에 대해 알아보자.

CI (Contious Integration)은 지속적 통합이다.

지속적 통합이라는 것은 어떤 의미일까?
코드 버전 관리를 하는 VCS (Git,SVN 등)에 PUSH를 하면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정이다.

CD (Contious Deployment/Continuos Delivery)는 지속적인 배포/지속적인 서비스제공이다.

지속적인 배포란, 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정이다.

 

이러한 과정이 왜 필요하게 된 것일까?

이를 알아보기 위해 아래에는 Red Hat 문서에 있는 글을 가져와 보았다.

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다.
CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제 (인테그레이션 헬)을 해결하기 위한 솔루션입니다.

특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공합니다.
이러한 구축 사례를 일반적으로 "CI/CD 파이프라인"이라 부르며 개발 및 운영팀의 애자일 방식 협력을 통해 지원됩니다.

 

CI는 왜 필요한거지?

개발은 한 프로젝트를 여러 개발자가 함께 개발을 진행한다.
그렇기 때문에 여러 개발자들의 코드를 병합해야하는데, 이것을 수작업으로 하면 생산성이 떨어진다.
그래서 지속해서 코드가 통합되는 환경인 CI를 구축하게 되었다.
CI 환경에서는 개발자 각자가 원격 저장소로 푸시될 때마다 코드를 병합하고, 테스트코드와 빌드를 수행하면서 자동으로 코드가 통합된다.
결과적으로, 개발자들은 개발에만 집중할 수 있게 되었다.

CI 도구의 도입, 그 후 CI에 대한 4가지 규칙에 대해 알아보자.  (Ref.🧐)

  1. 모든 소스 코드가 현재 실행되고, 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
  2.빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
  3. 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
  4. 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것

 

CD는 왜 필요한거지?

수십대 수백 대의 서버에 배포를 해야하거나 빠르게 배포해야하는 상황에서는 수동으로 배포할 수 없게 된다.
그렇기 때문에 배포역시 자동화를 하게 되었고, 개발자들은 개발에만 집중할 수 있게 되었다.

 

2.

CI/CD 연동시 구조에 대해 생각해보자.

예를 들어, CI는 깃허브에서 제공하는 무료 CI 서비스인 Travis CI를, CD는 AWS CodeDeploy를 사용해보자.

https://jojoldu.tistory.com/265?category=635883 조졸두님 티스토리 😉

1. 개발자는 개발을 한다.

2. 테스트 코드까지 완료한, 빌드하고 하는 파일을 깃허브에 푸시한다.

3. 깃허브 푸시를 하면, 깃허브에서 제공하는 CI 서비스인 Travis CI에서 자동으로 테스트와 빌드를 수행해서 배포 파일을 만든다.
이 과정에서 결과는 사용자가 등록한 이메일이나 슬랙으로 알람이 온다.

4. Travis CI는 생성한 배포 파일을 AWS S3에 전달한다.
  왜? 실제 배포를 하는 AWS CodeDeploy가 아닌 AWS S3에 전달할까?
  Jar 파일을 전달하기 위해서이다.
  AWS CodeDeploy는 저장 기능이 없다.
  그래서 Travis CI가 빌드한 결과를 CodeDeploy가 보관할 수 있는 공간이 필요한데, 보통 AWS S3를 사용한다.
  참고로, CodeDeploy는 깃허브 코드를 가져올 수 있기 때문에 빌드도 하고 배포도 할 수 있지만, 빌드와 배포는 분리하는 것이 좋다.

  왜? 빌드와 배포를 분리하지 않으면, 빌드 없이 배포만 하는 상황에 대응하기 힘들다. 또, 항상 빌드를 해야해서 확장성이 떨어진다.
  반면에 빌드와 배포를 분리하면, 예전에 빌드된 Jar를 재사용할 수 있기때문에 분리하는 것이 좋다.

5. AWS S3에 저장된 빌드파일을 AWS CodeDeploy에서 배포할 파일로 가져간다.
  CodeDeploy는 Jar파일을 인식하지 못하기 때문에, zip파일로 압축되어 있다.

6. AWS CodeDeploy는 EC2 서버에 배포한다.

이렇게 되면 기초적인 빌드/테스트 자동화, 배포 자동화가 완료된다.
무중단 배포까지의 코드 참고 => https://github.com/shin-ga-eun/springboot-boardweb

 

 

Reference
🧐마틴파울러의 블로그
📘스프링부트와 AWS로 혼자 구현하는 웹서비스
😉이해를 도와준 블로그