CI & CD
CI란?
CI는 Continuous Integeration(지속적인 통합)의 약자이다. 지속적인 통합이라는 게 무슨 의미일까?
CI를 간단히 표현하자면 "빌드 및 테스트 자동화"라고 할 수 있다.
CI는 새롭게 만들거나 수정을 가한 Service를 빌드하고 테스트하여 서비스가 제대로 작동하는지 확인하는 과정을 자동으로 수행해주는 것이다.
CI는 계속해서 자동화된 빌드와 테스트를 제공하기 때문에 코드의 지속적인 품질 유지 및 상승을 가능하게 한다.
CI는 버전 관리 시스템(ex. Git)에 대한 변경 사항을 정기적으로 커밋하여 모든 사람이 동일한 작업을 수행할 수 있도록 도와주기도 한다. 따라서 CI를 성공적으로 구현한 경우 협업하는 모든 개발자가 충돌 없이 애플리케이션을 개발할 수 있게 되는 것이다.
또한 커밋할 때마다 자동으로 Build 하여 테스트까지 진행하므로 병합으로 인해 애플리케이션에 문제가 생기지 않는 것을 보장한다.
이토록 CI는 작성한 코드가 신뢰 가능한 상태임을 증명하는 과정임과 동시에 협업에 있어 문제가 생기지 않도록 도와주는 방법이기 때문에 개발자는 수정 사항이나 결과물을 생성할 때마다 CI를 수행해야 한다.
CD란?
CD는 Continuous Deploy(Delivery)의 약자로써 지속적 배포라는 의미를 가진다.
CI보다는 확실히 이해가 확 되는 개념인데, 말 그대로 빌드된 서비스를 자동으로 서버에 배포시킨다는 의미이다.
CD 과정은 DevOps 방식을 활용할 수 있게 해주는 기술 중 하나이다.
CD는 CI 과정과 결합하여 수행되는데, CI 과정을 통해 작성한 코드가 신뢰 가능한 상태임이 증명되면 자동으로 서버에 배포까지 수행하는 형식으로 활용된다.
즉 CD를 활용하면 품질의 저하 없이 최대한 빠르게 고객의 요구사항에 대응하는 서비스를 제공할 수 있게 되는 것이다.
그림으로 보는 CI/CD
- 출처: Amazon Web Services
위에 있는 RedHat이 설명하는 CI/CD와 아래 사진의 AWS가 설명하는 CI/CD 형태가 다른 것을 볼 수 있다.
CD 과정을 CI과정과 배포 과정을 모두 포함하는 과정이라고 말하는 사람도 있으며 CI 과정에 Test를 포함하지 않는 사람들도 있다.
누구의 말이 무조건 맞다고 생각하지는 않는다. 단지 CI와 CD의 개념에서 어디에 더 큰 비중을 두느냐에 따라 이런 차이가 생겨난다고 생각한다.
먼저 CD를 "자동화된 배포"라는 개념에서 본다면 CI 과정이 일어난 이후 통합된 Source Code에 대하여 CD 과정을 거쳐 배포가 진행된다라고 이해할 수 있을 것이다.
하지만 CD를 "자동화된 배포에 필요한 과정"이라는 개념으로 생각하자면 코드를 Build 하는 것도 자동화된 배포에 필요한 과정 중 하나이기 때문에 CD 과정에 포함되어야 한다고 생각할 수 있을 것이다.
Test에 대해서도 유사하다.
CI를 "통합"이라는 측면에서 보자면 굳이 테스트를 진행하지 않아도 Source Code의 통합까지는 가능할 것이다. 단지 통합된 Source Code의 품질 보증이 안 되는 것이다.
하지만 CI를 "빌드"라는 측면에서 보자면 테스트도 포함되어야 한다. "빌드"라는 것은 결국 운영 서버에서 실행하기 위한 Application 실행 파일을 만드는 과정이다. 운영 서버에 실행될 파일을 만드는 것이기 때문에 품질이 보증되어야 하며 이런 측면에서는 당연히 Test가 진행되어야 하는 것이다.
Continuous Delivery VS Continuous Deployment
개인적으로 RedHat의 CI/CD 사진은 매우 조심히 봐야 하는 사진이라고 생각하는데 자칫하면 Continuous Delivery와 Continous Deployment를 잘못 이해할 수도 있기 때문이다.
결론부터 말하자면 Continuous Delivery는 운영 서버에 등록하는 과정은 직접 수행하는 것이고 Continuous Deployment는 운영 서버에 빌드된 파일을 등록하는 것까지 자동화된 것이다.
즉 RedHat 사진처럼 Continous Delivery 과정이 끝난 이후 Continuous Deployment가 실행되는 것이 아니라는 것이다.
- 출처 : gocd.org
위 사진이 Deployment와 Delivery의 차이점을 가장 잘 나타냈다고 생각하는 사진이다.
둘의 차이를 이해하기 전 Staging에 대해 먼저 이해할 필요가 있다.
Staging은 운영 환경과 거의 동일한 환경이지만, 실제로 고객에게 서비스를 제공하지는 않는 서버를 말한다.
아무리 Test를 진행한다고 하더라도 Source Code를 바로 운영 서버에 올리기엔 리스크가 존재한다.
따라서 운영 서버와 동일한 설정의 서버에 빌드된 실행 파일을 배포시켜 시범 운영해보고 비기능적인 부분(보안, 성능 및 장애 요소 확인 등)을 검증하는 과정이 필요하며 이를 Staging 환경에서 수행하는 것이다.
Deployment와 Delivery는 Staging 영역까지는 동일하게 자동화를 통해 애플리케이션을 빌드하고 배포한다.
Delivery는 Staging 영역에서 애플리케이션이 제대로 작동할 경우 빌드된 어플리케이션을 실제 운영 서버에 올리는 과정은 사람이 직접 수행한다.
하지만 Deployment에서는 Staging 영역에서 애플리케이션이 제대로 동작된다고 판단될 경우 실제 운영 서버에 올리는 과정까지 자동화되어 있어 사람이 배포에 신경을 1도 쓰지 않아도 된다.
운영 서버에서 실행되는 Application은 고객이 직접 서비스를 사용할 수 있기 때문에 안정적으로 서비스를 제공하는 것이 가장 중요하다.
따라서 고객이 직접 사용하는 부분에 있어서는 사람이 개입함으로써 자동화 과정에서 발생되는 문제를 피하고 싶을 경우 Continuous Delivery를 활용할 것이다.
반대로 사람이 Application을 배포하다 생기는 Human Error를 줄이고 싶거나 운영 쪽에 아예 관심을 가지고 싶지 않을 경우 Continuous Deployment가 좋을 것이다.
CI / CD에 활용하는 툴
Jenkins
최근 시장에서 많이 활용되는 툴 하나를 꼽으라면 Jenkins를 선택할 수 있을 것이다.
Jenkins는 Java 기반 프로그램으로 Windows, macOs, Unix 계열 OS 체계용 패키지가 모두 존재하여 다양한 OS 환경에서 활용할 수 있다.
또한 수백개의 플러그인을 사용할 수 있기 때문에 다양한 기술과 결합하여 CI/CD의 자동화를 수행할 수 있다
사용자가 많기 때문에 레퍼런스가 많다는 장점이 존재한다. 또한 플러그인의 수가 많기 때문에 활용할 수 있는 기술 및 방법의 종류가 많다는 장점을 가져온다.
Build Plugins : Maven, Ant, Gradle,...
VCS Plugins(형상 관리) : Git, SVN,...
Language Plugins(프로그래밍 언어) : Java, Python, Node.js,...
하지만 Jenkins는 플러그인이 많은 만큼 Setting이 복잡하고, 활용하기 어렵다는 단점이 존재한다.
또한 JIRA나 redmine 같은 Issue Tracking 툴과의 연계가 불편하거나 완벽하지 않는다는 단점이 존재한다.
Travis CI
Travis는 Github Warehouse로 Push 되는 이벤트를 자동으로 감지하고 발생한 이벤트에 맞는 동작을 수행할 수 있다.
설정이 매우 쉽고 빠르며 자체 사전 설치된 DB 서비스도 존재한다.
Github와의 연동성이 좋으며 설치가 필요 없는 Open Source Web Service라는 장점이 존재한다. 또한 Yaml 파일 설정을 통해 바로 CI/CD 환경을 손쉽게 구축할 수 있으며 AWS와 잘 연동되는 기술이라는 장점을 가진다.
(실제로 필자는 이런 사용이 쉬운 점 때문에 처음 CI/CD를 사용했을 때는 Travis CI + AWS CodeDeploy를 활용했다)
단점은 Priveate Repositoy일 경우 1달 69달러라는 적지 않은 비용을 내야 한다.
Github Action
Github Repository에서 바로 Workflow를 생성할 수 있게 된다. 이에 따라 한 곳에서 코드를 관리하기 수월해진다.
Github Action은 Github에서 제공하는 서비스인 만큼 Github와 잘 연동되는 기술인데, 깃허브에 존재하는 Source Code를 빌드, 테스트 및 배포하는 과정을 매우 수월하게 해 준다.
Circle CI
신속함이 가장 큰 장점인 Tool이다.
Circle CI는 코드 구축부터 배포까지 CI/CD 과정 전반을 신속하게 수행할 수 있도록 도와준다.
또한 Circle CI는 Github 및 Bitbucket과 통합하여 활용할 수 있다.
Circle CI를 활용하면 디버깅이 매우 추워지고 Test Process가 빠르다는 장점이 존재한다.
또한 설정을 통해 개인화된 Email, IM 공지 등을 활용할 수 있는 서비스를 제공한다.
TeamCity
IntelliJ나 PyCharm을 사용해본 사람이라면 익숙한 디자인일 텐데 예측한 대로 Jetbrains에서 만든 CI/CD 툴이다.
Java 환경에서 실행되며 Visaul Studio 및 IDE와 통합될 수도 있다.
Windows와 Linux 서버에 설치 가능하며 .NET과 개방형 스택 프로젝트도 지원한다.
JetBrains의 가장 큰 장점은 Docker 및 Kubernetes 기반 프로젝트와 매우 잘 통합된다는 점일 것이다.
또한 타 JetBrains 제품처럼 설치가 쉽고 사용자가 원하는 대로 설정할 수 있도록 많은 서비스를 제공한다.
Bamboo
Bamboo는 Git, Mercurial 및 SVM Repos의 Branch 변화를 감지할 수 있으며 수동으로 명령할 필요 없이 중요한 CI 체계를 Branch에 적용할 수 있다.
Bamboo의 가장 큰 장점은 Github와의 연결에만 많은 관심을 쏟은 다른 Tool과는 달리 SVM Repos, Mercurial 등 많은 버전 관리 툴과의 연동을 수행할 수 있다는 것이다.
한눈에 보는 CI/CD Tool 비교
- 출처 : Jenkins를 이용한 CI/CD Pipeline 구축(인프런)
먼저 Jenkins는 Open Source SW이기 때문에 비용상으로 고려할 점이 없으나 다른 Tool들은 무료 버전을 제공하기는 하지만 모든 기능을 활용하기 위해선 비용을 지불해야 한다.
물론 내장되어 있는 기능의 종류는 Jenkins가 다른 Tool에 비해 적지만 Integration(통합이나 Plugin) 같은 경우 Jenkins가 많이 보유하고 있고 Cloud 환경과 On-premise 환경 모든 곳에서 구축할 수 있다는 점에서 때문에 많은 곳에서 활용하고 있다.
