[DevOps]CI/CD (지속적 통합/지속적 제공) 개념과 과정/ 툴 별 장단점 비교

[DevOps]CI/CD (지속적 통합/지속적 제공) 개념과 과정/ 툴 별 장단점 비교

애플리케이션 개발은 보통 혼자 모든 기능을 개발하기보다 여러 개발자들이 동일한 애플리케이션의 각기 다른 기능을 맡아 동시에 작업하게 된다. 만약 이러한 상황에서 개발자들이 자신의 로컬환경에 작업하여 완전히 개발이 끝날 때까지 중앙 저장소로 올리지 않는다면,  개발이 종료된 후 전체 코드를 통합하고 배포하는 정말 쉽지않을 것이다. (프로젝트의 규모가 클 수록, 개발과정이 길수록, 많은 개발자들이 함께할 수록 어려움은 클 것이다.)

 

실제로 현대적인 애플리케이션 개발에서는 이렇게 진행하는 경우는 거의 없을 것이다. git과 같은 형상관리 툴을 사용하여 중간중간 커밋과 머지를 통해 코드를 병합하는 과정을 거칠 것이다. 그러나 특정한 날(병합하는 날(merge day))을 정해 소스 코드를 병합하는 경우, 독립적으로 작업하는 개발자가 애플리케이션에 변경 사항을 적용할 때 다른 개발자가 동시에 적용하는 변경 사항과 충돌을 경험하고 이를 해결하는데 많은 시간을 사용하게 될 수도 있다.

 

이럴 때, 지속적인 통합과 배포(CI/CD)를 자동화하여 사용한다면 이러한 문제를 조금이나마 해결할 수 있다.

💡 CI/CD란 무엇일까?

- 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법

- 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공

- 이러한 구축 사례를 일반적으로 "CI/CD 파이프라인"이라 부르며 개발 및 운영의 애자일 방식 협력을 통해 지원

- 지속적인 통합(Continuous Integration), 지속적인 서비스 제공(Continuous Delivery), 지속적인 배포(Continuous Deployment)으로 구성

CI/CD 파이프라인

1.  CI : 지속적 통합(Continuous Integration)

- 개발을 하면서 지속적으로 코드에 대한 통합을 진행함으로써 품질을 유지하자는 것

- 개발자를 위한 자동화 프로세스(개발자간의 코드 충돌을 방지하기 위한 목적)

- 정기적인 빌드 및 테스트(유닛테스트 및 통합테스트)를 거쳐 공유 레포지터리에 병합되는 과정

- 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행

- 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 빠르게 수정 가능

 

2. CD: 지속적인 서비스제공( Continuous Delivery)

- CI 프로세스를 통해 개발중에 지속적으로 빌드와 유닛 및 통합 테스트를 진행하고, 이를 통과한 코드에 대하여 테스트서버와 운영서버에 자동으로 릴리즈

- 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포 가능

- 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 확보하는 것이 목표

 

3. CD : 지속적인 배포( Continuous Deployment)

- CI/CD 파이프라인의 마지막 단계

- 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 릴리스하는 지속적 제공의 확장된 형태

- 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화

- Continuous Delivery로 통칭하여 언급하기도 함

- 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 자동으로 실행할 수 있는 것을 의미

- 테스트와 빌드가 ‘지속적’으로 이루어지기 때문에, 배포 또한 자연스럽게 ‘지속적’으로 이루어지게 됨

 

이러한 모든 CI/CD 적용 사례는 사용자 피드백을 지속적으로 수신하고 통합하는 일이 훨씬 수월해지게 한다. 또한, 애플리케이션 배포의 위험성을 줄여주므로 애플리케이션 변경 사항을 작은 조각으로 세분화하여 더욱 손쉽게 릴리스할 수 있다. 그러나 자동화된 테스트는 CI/CD 파이프라인의 여러 테스트 및 릴리스 단계를 수행할 수 있어야 하기 때문에 많은 선행 투자가 필요하다.

💡 대표적인 CI/CD 제공 툴 장단점 비교(Jenkins / Bamboo)

Jenkins

장점

1. 무료이고 Reference 및 사용자가 많고 정보가 많은 편이다.
2. Hudson core 개발자가 jenkins 를 시작했고 주요 플러그인 개발자도 jenkins 로 전환해서 개발 속도가 빠르고 플러그인 지원이 좋은 편이다.
3. 설치 및 사용이 간단하다. 실제로 maven 으로 build 가 구성되어 있다면 jenkins 설치후 project 만드는데 얼마 안 걸린다.
4. Remote Access API 를 제공하므로 다른 솔루션에서 연계하여 기능 확장이 가능하다.

단점

1. 프로젝트 별 보안 및 권한 설정등이 불편하다. (bamboo 에 비해)
2. JIRA나 redmine 등 Issue tracking 과 연계가 불편하거나 완벽하지 않다.

Bamboo

장점

1. 손쉽고 직관적인 UI를 갖고 있고 상용 SW 에 걸맞게 예쁜 외양을 자랑한다.
2. atlassian 제품군과 완벽한 통합 제공. JIRA 의 대쉬보드나 confluence의 Page에 bamboo build chart 를 붙일수도 있고 JIRA 의 특정 이슈와 관련된 build 내역을 조회하는 등 atlassian 제품을 기존에 사용하고 있다면 각 제품군을 통합해서 더욱 유기적으로 사용할 수 있다.
3. MS의 Visual Studio, Mac OSX 의 XCode 등 Java 이외의 개발 환경을 지원한다. ( Visual Studio 지원은 아직 그리 잘 돌아가지 않고 복잡해서 시행착오를 좀 거쳐야 하고 써본 경험상 bamboo 에 붙이는건 그리 추천하지 않는다.)
4. Jenkins 에 비해 프로젝트 권한 설정이나 분산 빌드가 아주 간편하다.
5. Remote Access API 를 제공하므로 다른 솔루션에서 연계하여 기능 확장이 가능하다.

단점

1. 제법 비싼 비용이 발생한다.  (build 를 할수 있는 remote agent 수 따라 라이센스 비용이 책정되는데 5 remote agent 가 $2,200 이다. 1년후마다 매년 구입가의 50% subscription 비용 추가 발생.)
2. Project, Plan, Stage, Task 의 개념이 복잡해서 익숙해지고 제대로 쓰려면 약간의 시간이 필요하다.

 

참고

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

https://woowabros.github.io/experience/2018/06/26/bros-cicd.html

https://www.lesstif.com/software-architect/jenkins-bamboo-15269892.html