CI/CD 알아보기

CI/CD를 알아보기에 앞서 자주 사용되는 용어들에 대해 정리하고 넘어가고자 한다.

컴파일 - 프로그래머가 작성한 소스코드를 기계어로 변환하는 과정

빌드 - 소스코드 파일을 컴퓨터에서 실행할 수 있는 소프트웨어 산출물로 만드는 과정 (빌드안에 컴파일 과정이 포함되어 있다.)

배포 - 빌드의 결과물을 사용자가 접근할 수 있는 환경에 배치하는 것

 

일반적으로 사용하는 CI/CD의 흐름은 위의 그림과 같다.

CI가 무엇인지, CD가 무엇인지 알아보자.

 

CI - Continuous Integration

지속적 통합이라는 뜻으로, 개발을 진행하면서도 품질을 관리할 수 있도록 여러명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다.

 

CI가 없었을 때로 돌아가보자.

옛날 개발자들은 일명 머지데이라 불리는 날을 정해 모든 소스 코드를 병합해야 했다. 결과적으로 이는 반복적인 수작업을 요구했고, 많은 인력 리소스를 낭비하게 되었다. 또한 코드를 병합했다하더라도 이 코드가 정상적으로 작동하는 코드인지 확신할 수 없었다. 만약 개발자가 실수를 해서 에러가 발생하는 코드를 병합하는 과정이 반복되다 보면, 어디서 에러가 발생하는지 찾기 힘들어져 디버깅하기 업려다는 문제점이 있었다.

 

그래서 CI의 중요성이 커지게 되었다.

 

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

• 단일 소스 저장소 유지(Maintain a Single Source Repository)
• 빌드 자동화(Automate the Build)
• 셀프-테스팅 빌드 만들기(Make Your Build Self-Testing)
• 모든 사람이 매일 커밋하기(Everyon Commits To the Mainline Everyday)
• 모든 커밋은 통합서버의 메인라인으로 빌드되어야 한다.(Every Commit Should Build the Mainline on an Integration Machine)
• 빌드가 빨리 되도록 유지(Keep the Build Fast)
• 운영 환경과 동일한 환경으로 테스트(Test in a Clone of the Production Environment)
• 최신 실행가능한 소스에 누구든 쉽게 접근할수 있게 만들어라(Make it Easy for Anyone to Get the Lastest Executable)
• 모든 사람이 무슨일 일어나고 있는지 알수 있게 하라(Everyone can see what's happening)
• 자동화된 배포(Automate Deployment)

CI는 지속적으로 소스 코드를 Build하고, Test하는 과정을 거친다.

CI를 이루어냈으니, 이제 EC2 서버로 접근해서, 쉘 스크립트를 작성하고 서버를 배포하기만 하면 된다. 

규모가 작은 서비스라 서버를 1대 운영하고 있다면, 수동으로 서버에 접속하여 쉘 스크립트를 실행시키는 것은 어려운 일이 아닐 것이다.

하지만, 서비스 규모가 커져 수십대의 서버를 운영하게 된다면, 수동으로 배포하는 것은 리소스 낭비가 심한 일이 될 것이다.

이를 해결하기 위해, CI의 연장선인 CD가 등장한다.

 

CD - Continuous Deployment

지속적 배포라는 뜻으로, 빌드의 결과물을 프로덕션으로 릴리스하는 작업을 자동화하는 것을 의미한다.

흔히, Continuous Delivery와 혼용되어 사용된다.

어디까지 자동화 하느냐에 따라 지속적 제공과 지속적 배포를 구분할 수 있다고 생각한다. CI 과정이 끝나면 완전히 통합된 코드를 얻을 수 있다. 이 후, 즉시 배포 가능한 코드를 확보하고 이를 운영서버에 배포하는 것 까지 자동화 한 것이 지속적 배포(Continuous Deployment)이고 그렇지 않은 것이 지속적 제공(Continuous Delivery) 이다. (수동으로 배포 가능)

 

CI/CD Tool

Jenkins, Travis CI, Github Actions 등 정말 많은 Tool들이 존재한다.

구글 트렌드를 통해, 근 5년간 CI/CD Tool의 관심도를 확인해보면, Jenkins가 확실히 압도적인 것을 확인할 수 있다.

Jenkins는 사용자가 많아 레퍼런스가 많이 존재하며, 다양한 플러그인들이 존재하여 적용하기 쉽다는 점에서 많이 사용되고 있다.

 

참고

http://pseg.or.kr/pseg/index.php?mid=infotrend&document_srl=1851&listStyle=viewer