CI/CD란?

 

내가 잘못 알고 있었다는 것을 알게 되었다..

아무튼 알게 되었으니 좋은 일이다...!!

 

---

 

1. CI/CD란?

 

 

CI/CD란 Continuous Integeration / Continuous Delivery 또는 Continuous Deployment의 약자로, 

지속적 통합, 지속적 전달 또는 지속적 배포를 의미한다.

 

CI/CD가 이루어지는 흐름은 다음과 같다.

https://aws.amazon.com/ko/devops/continuous-delivery/

우선, 개발자가 코드 병합 요청을 하면 CI/CD Tool이 Build와 Test를 진행하고, 이 때, 문제가 발생하지 않으면 병합한다. 이 과정이 CI이다.

그리고 Delivery 또는 Deployment 중 선택하는 단계에 맞게 서버에 배포한다.

 

CI/CD Tool에는 Jenkins, Travis CI, Github Actions가 있다.

 

그렇다면, CI, CD 각각에 대해 알아보자.

 

 

CI (Continuous Integration)

지속적인 통합 이라고 번역하며

CI를 통해 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있어 개발을 진행하면서도 품질을 관리할 수 있다.

 

CI가 없을 때는 Merge Day에 수작업으로 직접 코드를 통합해야 했고, 이에 따라 에러가 발생해도 디버깅이 어려웠다고 한다..

CI를 통해 코드가 완성될 때마다 병합할 수 있게 되었다.

 

마틴 파울러는 다음과 같은 CI의 4가지 규칙을 제시했다.

1. 모든 소스코드가 살아있고 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것

2. 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드할 수 있게 할 것

3. 테스팅을 자동화해서 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것

4. 누구든 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것

 

 

CD (Continuous Delivery / Development)

 

각각 지속적 제공, 지속적 배포라고 한다.

두 가지는 어느 단계까지 릴리스가 자동화되어 있는지에 차이가 있다.

 

 

Continuous Delivery

 

Continuous Delivery는 Staging 단계까지 자동으로 이루어지고 Production 배포는 수동으로 이주어지는 것을 의미한다.

이 때, Staging과 Production은 SW 개발환경을 의미한다.

 

SW 개발환경

 

환경	설명
Local	각 개발자가 개발하는 환경
Development	각 개발자들의 코드를 합쳐서 테스트해 볼 수 있는 환경
Staging	Production 서버와 거의 동일한 환경을 만들어서 비기능적인 부분에 집중해 검증하는 환경
Production	실제 사용자에게 서비스되는 환경

Development와 Staging 사이에 Integration, QA 단계를 포함해 6단계로 나누기도 한다.

- Integration : 여러 개의 컴포넌트를 동시에 개발하는 프로젝트가 있고, 각 컴포넌트가 다른 컴포넌트에 대해서 의존성을 가지고 있을 때, 컴포넌트를 통합 및 테스트하는 환경

- QA : QA 엔지니어에 의해 사용되는 환경으로, short release 주기에 따라 개발환경에서 QA 환경으로 배포되고, 여기에서 기능 및 비기능 등을 QA 엔지니어가 수행

 

 

Continuous Deployment

 

빌드의 결과물을 프로덕션으로 릴리스하는 작업까지 자동화한 것을 의미한다.

이를 통해 배포까지 사람의 개입 없이 자동으로 진행된다.

 

 

2. CI/CD에 사용한 기술

 

프로젝트에서 CI/CD를 담당하며 Jenkins, Docker, Nginx를 사용했다.

 

Jenkins

 

지속적인 빌드와 배포를 자동화해주는 오픈소스 도구이다.

Jenkins Pipeline을 이용해 배포를 위한 Groovy 기반 스크립트를 작성했다.

 

CI/CD를 구축할 때, GitLab Webhook으로 trigger를 받아 Jenkins가 변경을 파악하도록 했고,

이후 스크립트에 따라 배포가 진행되었다.

 

스크립트에서 진행된 과정은 다음과 같다.

: Git Repository Clone → Set Environment : EC2에 필요한 파일 복사 → Docker Down : 기존 컨테이너(서비스) 종료 → Docker Up : 새롭게 Build한 Docker Image로 컨테이너 실행 → Health Check → Docker Clear

 

 

Docker

 

Docker는 컨테이너 기반의 오픈소스 가상화 플랫폼이다.

Java Project를 Docker Image로 만들고 Docker Container로 패키징하여 실행 및 배포하였다.

설정 관리를 간편하게 하기 위해 Docker-Compose를 사용하였다.

 

 

Nginx

 

Nginx는 웹 서버로 로드 밸런싱, 리버스 프록시, 정적 콘텐츠 제공 등의 역할을 한다.

 

주로 리버스 프록시로 사용하였다.

API url의 SSL 설정 후 443(설정 전 80) 포트로 들어오는 요청을 localhost:8080(서버 포트번호)로 넘겨주었다.

 

또한, SSL 설정을 하기 위해 certbot을 이용했는데, certbot이 SSL 적용을 위해 필요한 nginx 설정을 자동으로 해주었다 ㅎ..

443 포트로 접근하면 SSL을 적용한 후, proxy pass에 설정한 포트로 요청을 전달해 주었다.

또한, 80 포트로 접근하면 443 포트로 리다이렉트 시켜주었다.

 

 

---

참고 자료

 

• CI(Continuous Integration) / CD(Continuous Delivery) / CD(Continuous Deployment)
• CI/CD란?
• [10분 테코톡] 찬, 레넌의 CI/CD와 무중단 배포
• SW 개발환경 (dev, staging, production)
• 개발 환경(dev,stage,qa,production)