CI/CD에서 CI와 CD는 각각 무엇일까?
CI는 개발자를 위한 자동화 프로세스인 지속적 통합(continuous integration)을 나타낸다. CI가 성공적으로 이루어지려면 애플리케이션에 대한 코드 변경이 정기적으로 빌드, 테스트되고 공유 저장소에 병합(merge)되어야 한다. 한꺼번에 다수의 브랜치에서 변경된 코드를 통합하려 하다 보면, 서로 충돌이 발생하게 되고, 이를 조정하는데 시간과 비용이 걸린다. CI는 이러한 문제점에 대한 해결책이다.
CD는 지속적 전달(continuous delivery) 또는 지속적 배포(continuous deployment)를 의미한다. 지속적 전달은 개발자의 애플리케이션 소스코드 변경에 대해 버그 테스트와 원격 저장소(GitHub, 도커 컨테이너 레지스트리(contatiner registry) 등) 업로드를 자동화하는 것이다. 이를 통해 변경 이력이 서비스 운영 환경에 배포될 수 있다. 즉, 지속적 배포가 이루어질 수 있다. 지속적 배포는 빌드의 결과물을 프로덕션, 즉 실재서비스로 배포하는 작업을 자동화하는 것을 의미한다.
CI의 세부 단계
- 빌드 : 소스코드 파일을 실행 가능한 소프트웨어 산출물로 만드는 일련의 과정이다. 빌드 (Build) 는 컴파일, 패키징 등 최종 소프트웨어 실행파일을 만들기 위한 일련의 과정을 포함한다.
- 테스트 : 테스트는 함수 등 작은 단위를 테스팅하는 단위테스트, 모듈을 통합할 때 테스트하는 통합테스트, 사용자가 서비스를 사용하는 상황을 가정해서 테스트하는 엔드투엔드테스트가 대표적이다. 이외에 코드 보안 테스트도 포함할 수 있다.
- 병합(merge) : Git을 이용해 코드 병합를 한다. 충돌이라는 것은 대부분 일어나기 때문에 조금 더 작은 단위로 충돌이 일어나게 하는게 중요하다. 이슈 단위로 나눠서 머지를 하는 것도 하나의 방식이다.
CI/CD 예시
- Step 1 : 지속적 통합(continuous integration) - 사용자가 Github main 브랜치에 이슈 하나를 단위로 푸시하면 빌드, 테스트를 진행한다.
- 빌드와 테스트가 성공 시 main 브랜치 레포지토리에 변경된 코드가 반영된다. 이슈 하나를 해결할 때마다 코드가 짧은 주기를 간격으로 점진적으로 병합된다.
- 실패 시 main 브랜치 레포지토리에 변경된 코드가 반영되지 않는다.
- Step 2 : 지속적 전달(continuous delivery) - 소스 코드 변경에 대해 Github main 레포지토리와 도커 컨테이너 레지스트리에 업로드한다.
- Step 3 : 지속적 배포(continuous deployment) - 원격저장소에서 실제서비스 운영환경에 배포한다.
CI/CD 툴 - Github Actions, Jenkins
CI/CD 툴에는 Jenkins, Travis CI, AWS CodePipeline, GitHub Actions 등 여러가지가 있다.
이 중에서 가장 많이 쓰이는 Github Actions와 Jenkins를 비교해보고자 한다.
주요한 차이는 Jenkins는 서버에 기반하는 CI/CD 툴이고, GitHub actions는 Git에 의해 제공되는 서버리스(serverless) CI/CD툴이라는 점이다. 그 밖의 차이점은 표로 정리를 했다.
| Jenkins | GitHub Actions | |
|---|---|---|
| 서버 설치 | 필요 | 클라우드가 있으므로, 별도 설치 필요 없음 |
| 병렬성 | Jenkins는 빌드가 병렬로 실행되도록 할 수 있지만 모든 빌드가 동일한 환경을 공유하고 파일 시스템과 같은 공유 자원에서 문제가 발생할 수도 있다. | 멀티 플랫폼에서도 빌드가 병렬로 실행되도록 할 수 있다. |
| 동작 | 계정과 트리거(trigger) 기반으로 빌드를 하며 GitHub 이벤트를 따르진 않는다. | 모든 GitHub 이벤트에 액션을 제공하며 많은 언어와 프레임워크를 지원한다. |
| 컨테이너 지원 | 지원되지 않는다. Jenkins는 동일한 환경에서 빌드하고 실행한다. 이슈를 해결하기 위해 도커 이미지에서 실행하는 등 따로 처리를 해야 한다. | Linux, macOS, Windows 및 컨테이너를 사용하거나 가상 머신에서 직접 실행할 수 있다. |
| 캐싱 | 캐싱 매커니즘을 지원하기 위해 플러그인 사용 가능 | 캐싱이 필요한 경우 자체 캐싱 매커니즘을 만들어야 한다. |
| 정보 | 전세계 많은 사람들이 이용하여 문서 다양 | Jenkins에 비해 문서 없음 |
| 공유 | 공유할 수 있는 곳이 없었으나 최근에는 IaC 플러그인과 IaC 스캔을 이용해서 공유를 하는 추세이다. | GitHub 마켓 플레이스에서 공유 가능 |
Jenkins는 서버 설치와 컨테이너 설정과 같이 따로 설정해야할 요소들이 많지만 GitHub Actions에 비해 다양한 플러그인을 제공하고, 관련 문서가 많다. GitHub Actions는 서버 설치를 할 필요가 없고, 설정이 간편하고, GitHub와 연동된다. Jenkins는 CI/CD 파이프라인을 직접 관리해야 하고, 따로 서버까지 설치해야 하기 때문에 서버 비용도 발생하게 된다. 따라서 다음 글에서는 좀 더 간편한 CI/CD 툴인 GitHub Actions를 실습해보고자 한다.
[참고자료]
https://blog.bitsrc.io/github-actions-or-jenkins-making-the-right-choice-for-you-9ac774684c8
https://www.redhat.com/en/topics/devops/what-is-ci-cd
https://knapsackpro.com/ci_comparisons/jenkins/vs/github-actions
https://plugins.jenkins.io/qualys-iac-security/
댓글