CI/CD

 

 

 

CI / CD (Continuous Integration/Continuous Deployment)

- 정의 : 지속 적으로 코드를 합치고 지속적으로 코드를 배포한다.

- 필요한 이유 : 만약 CI/CD 프로그램이 없이 개발자들이 수동으로 코드를 합치고 배포한다면 개발자들의 작은 커뮤니케이션 오류 또는 테스트 코드의 부재가 나중에 큰 문제를 일으킬 수 있다.

-> 예를 들어, Dev 서버를 로컬로 불러왔을 때, 동작이 안되는 경우 등을 방지

 

따라서, 여러명의 개발자가 동시에 개발을 하는 환경 속에서 CI/CD 시스템으로 코드를 합치고 배포하는 과정에 안정성을 부여할 수 있다.

 

 

CI

- 원리 : 코드를 Git등에 Commit하는 과정으로 Jenkins등의 CI 툴은 빌드와 테스트를 진행해 문제 발생시 Commit을 막는다.

- 마틴 파울러가 제시하는 CI 규칙

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

 

CD

- 원리 : Jar, War 파일등을 사용하고 있는 서버 AWS EC2 등에 올리고 deploy.sh 배포 스크립트를 실행, 이때 여러 서버를 사용하는 경우를 대비해 배포 스크립의 실행을 수동이아닌 자동화 하는 것

- 정의 : 빌드의 결과물을 프로덕션으로 릴리스하는 것을 자동화 하는 것

 

 

 

무중단 배포

- 기존의 배포 과정 : 서비스 진행 중 -> 기존 서비스 종료 -> 새로운 서비스 배포 -> 새로운 서비스 실행

- 문제 : 과정 중 사용자들이 서비스를 사용하지 못하는 다운타임 발생

- 정의 : 이러한 문제를 해결하기 위해 중단없이 새로운 서비스를 사용자에게 제공하는 것을 의미

- 방법

• AWS의 Blue-Green 무중단 배포
• 도커를 이용한 무중단 배포
• L4,L7 스위치를 이용한 무중단 배포
• Nginx를 이용한 무중단 배포 (많이 사용)

- 리버스 프록시 (Reverse Proxy) : 인터넷과 서버 사이에 위치한 중계서버로써 클라이언트가 요청한 내용을 캐싱하고 서버 정보를 클라이언트로부터 숨길 수 있어 보안에 용이하다는 특징을 가진다.

- 로드 밸런싱 : 서버에 가해지는 부하를 분산하는 역할을 하는 것으로 하나의 서버가 중단되더라도 다른 서버가 동작하고 있기에 문제 발생이 없어지게 되고 이를 통해 무중단 배포가 가능해진다.

 

- 방식

• Rolling Depoly: 가장 기본이 되며 서버를 순차적으로 새로운 서비스 적용, 새로운 서버(인스턴스)를 개통하지 않아도 되지만 배포 과정 중 열려있는 나머지 서버에 부하가 가해질 가능성 존재
• Blue and Green Depoly : 두가지 서버 그룹을 두고 배포를 진행하는 개념으로 Blue(구버전, 현재 실행중인 서버 그룹), Green(신버전, 현재 새로운 버전을 가진 서버 그룹) 두 그룹을 만들고 새로운 버전 출시시 트래픽을 Green으로 변경하고 다음 또다른 새로운 버전에 대해서 Blue를 수정하여 또 적용하는 방식 배포하는 속도가 빠르고 롤백이 가능하지만 서버 그룹을 두개를 사용하기에 자원이 두배로 필요하다는 단점이 있다.
• Canary Depoly : 새로운 서비스에 대해서 소소의 사용자들이 먼저 테스팅을 해보면서 문제없는 것을 확인 후 새로운 버전 배포하는 방식 예를 들어, 3개의 서버에서 한대의 서버만 새로운 버전 동작하고 나머지는 구버전 실행 이 때, 문제 없을 시 나머지 서버에도 적용, 문제 상황을 파악할 수 있다는 장점이 있지만 기존의 버전과 새로운 버전이 함께 서버로써 공존한다는 점에서 호환성 문제 발생 가능

 

 

 

파이프 라인

- 프로젝트의 시작부터 끝을 일련의 과정으로 묶고 이를 CI/CD 파이프라인이라고 일컫는다.

- 총 3단계로 구성

• Continuous Intgeration : 코드를 빌드하고 테스트하고 합친다. (Build -> Test)
• Continuous Delivery : 해당 레포지토리에 릴리즈, Commit 한다. (Build -> Test -> Merge)
• Continuous Depoyment : 프로덕션을 실제 서버에 배포하여 사용자에게 공개한다. (Build -> Test -> Merge -> Deploy)

- 파이프라인은 모든 과정이 강제된다. 따라서 CI/CD 시스템을 사용할 시 위에서 설명한 문제점을 해결할 수 있다.

(예 : 테스트 코드가 없다면 머지(레포지토리에 저장)도 안됨.)

 

 

 

Build

- 여러 모듈들을 정적자원으로 바꿔주는 작업, 컴파일 과정(소스 코드를 기계어로 변환) 포함

- 컴퓨터에서 실행가능한 소프트웨어 산출물로 변경

- 예시 (코드 -> html, css, js, jar, war)

- 도구 : webpack,maven, gradle 등

 

 

 

Test

- 단위 테스트 : 함수 등 작은 단위로 테스팅

- 통합 테스트 : 모듈을 통합하기 위한 테스팅

- 엔드 투 엔드 테스트 : 사용자가 서비스를 사용하는 상황을 가정해서 테스팅

- 보안 테스트 : 공격자 공격시 보안 여부에 대한 테스트

- 도구 : Mocha, Junit 등

 

 

 

Merge

- 모듈들을 깃에 수정하거나 저장.

- 충돌을 최소화 하는것을 목적으로 두어야 함.

- 방식 : 개개인별 담당 폴더 설정, 큰 문제를 작은 issue 단위로 merge(commit), 충돌시 화면 공유를 통한 대화 등으로 충돌 해결

- 도구 : Git

예시) 이슈발생 -> 이슈에 대한 새로운 Branch 생성 -> 해당 Branch에 Commit을 해가면서 작업 -> 이슈 해결시 Main(Master) Branch에 Commit

 

 

 

배포

- 종류

-> 사용자를 위한 서비스 배포

-> QA엔지니어나 관리자 페이지(예시 : 배민 사장님 관리자 페이지)를 위한 배포

-> 데이터 엔지니어가 데이터 웨어하우스로부터 데이터를 가공(의미있는 데이터 생성)하여 백엔드 개발자를 위한 배포

- 도구 : github action, Jenkins, circle ci, Travis ci, heroku(->CI/CD 설정 없이 자동 가능)