CI/CD 도구 비교: Jenkins, GitLab CI, Buildbot, Drone 및 Concourse

소개

지속적인 통합, 제공 및 배포는 개발 속도를 높이고 충분히 테스트되고 사용 가능한 제품의 출시를 촉진하도록 설계된 전략입니다. 지속적인 통합은 개발 팀이 통합 충돌을 최소화하기 위해 초기에 변경 사항을 공유 코드베이스에 테스트하고 통합하도록 권장합니다. 지속적 배포는 배포 또는 릴리스 과정에서 장벽을 제거하여 이 기반을 구축합니다. 지속적인 배포는 테스트 스위트를 통과하는 모든 빌드를 자동으로 배포함으로써 한 단계 더 나아갑니다.

위의 용어는 주로 전략 및 관행과 관련이 있지만 소프트웨어 도구는 조직이 이러한 목표를 달성할 수 있도록 하는 데 큰 역할을 합니다. CI/CD 소프트웨어는 팀이 일련의 단계를 통해 새로운 변경 사항을 자동으로 진행하여 피드백 시간을 줄이고 프로세스에서 마찰을 제거하도록 도울 수 있습니다.

이 가이드에서는 협업 소프트웨어 개발을 보다 쉽게 하도록 설계된 인기 있는 무료 및 오픈 소스 연속 통합, 제공 및 배포 서버를 비교할 것입니다. Jenkins, GitLab CI, Buildbot, Drone, Concourse에 대해 살펴보겠습니다.

젠킨스

Hudson 프로젝트, 커뮤니티 및 코드베이스는 원래 개발자인 Sun Microsystems를 인수한 후 Oracle과 상표권 분쟁으로 분리되었습니다. Hudson은 원래 2005년에 출시되었으며 Jenkins로 첫 번째 출시는 2011년에 만들어졌습니다.

수년에 걸쳐 Jenkins는 소프트웨어 관련 작업을 자동화하는 강력하고 유연한 시스템으로 발전했습니다. Jenkins 자체는 주로 플러그인 라이브러리를 통해 구현된 중요한 로직의 대부분을 포함하는 자동화 프레임워크 역할을 합니다. 웹 후크 수신 또는 리포지토리 보기에서 환경 및 언어 지원 구축에 이르기까지 모든 것이 플러그인에서 처리됩니다. 이것은 상당한 유연성을 제공하지만 CI 프로세스는 취약할 수 있는 수많은 타사 플러그인에 의존하게 될 수 있습니다.

플러그인을 통해서도 제공되는 Jenkins의 파이프라인 워크플로는 2016년부터 사용할 수 있는 비교적 새로운 기능입니다. CI 프로세스는 저장소 자체 내의 파일에서 또는 Jenkins 웹의 텍스트 상자를 통해 Groovy 언어를 사용하여 선언적으로 또는 명령적으로 정의할 수 있습니다. UI. Jenkins에 대한 일반적인 비판 중 하나는 플러그인 중심 구성 모델과 리포지토리 외부에서 파이프라인을 정의하거나 프로세스를 구축하는 기능으로 인해 때때로 다른 Jenkins 인스턴스에서 구성을 쉽게 복제하기 어려울 수 있다는 것입니다.

Jenkins는 Java로 작성되었으며 MIT 라이선스에 따라 출시되었습니다. 프로젝트에 Jenkins 서버를 구성하려면 Ubuntu 16.04에 Jenkins를 설치하는 방법에 대한 가이드를 따르세요.

깃랩 CI

GitLab은 Git 저장소 호스팅 및 개발 도구 플랫폼입니다. 원래 독립 실행형 프로젝트로 출시된 GitLab CI는 2015년 9월 GitLab 8.0 출시와 함께 주요 GitLab 소프트웨어에 통합되었습니다.

GitLab CI의 CI/CD 프로세스는 YAML 구성 구문을 사용하여 코드 리포지토리 자체의 파일 내에서 정의됩니다. 그런 다음 작업은 설정하기 쉽고 다양한 운영 체제에서 프로비저닝할 수 있는 러너라는 시스템으로 발송됩니다. 러너를 구성할 때 Docker, shell, VirtualBox 또는 Kubernetes와 같은 다양한 실행기 중에서 선택하여 작업 수행 방법을 결정할 수 있습니다.

GitLab CI와 GitLab 리포지토리 플랫폼의 긴밀한 결합은 소프트웨어 사용 방법에 명확한 영향을 미칩니다. GitLab CI는 다른 리포지토리 호스팅 플랫폼을 사용하는 개발자를 위한 옵션이 아닙니다. 긍정적인 측면은 통합 기능을 통해 GitLab 사용자가 추가 도구를 설치하고 배우지 않고도 CI/CD 환경을 설정할 수 있다는 것입니다. 자동 테스트는 웹 인터페이스에서 몇 가지 옵션을 활성화하고 러너 머신을 등록하고 저장소에 파이프라인 정의 파일을 추가하여 시작할 수 있습니다. 긴밀한 관계를 통해 프로젝트 간에 러너를 공유하고, 리포지토리 내에서 현재 빌드 상태를 자동으로 확인하고, 빌드 아티팩트를 생성한 코드와 함께 유지할 수 있습니다.

GitLab 및 GitLab CI는 Ruby 및 Go로 작성되었으며 MIT 라이선스에 따라 배포됩니다. GitLab CI로 지속적인 통합 파이프라인을 설정하는 방법에 대한 가이드를 따라 GitLab 서버에서 이 기능을 구성하는 방법을 배울 수 있습니다.

빌드봇

Buildbot은 엄청난 유연성을 제공하는 지속적인 통합 프레임워크입니다. Mozilla의 Tinderbox 프로젝트의 대안으로 2003년에 처음 출시된 Buildbot은 주로 다양한 플랫폼에서 빌드 테스트를 자동화하는 방법으로 설계되었습니다.

Buildbot은 GPL 라이선스로 출시되었으며 Twisted 라이브러리를 사용하여 Python으로 작성되었습니다. 단순화된 구성을 위해 기본 언어를 추상화하는 대신 Buildbot의 구성은 전적으로 Python으로 작성됩니다. 이는 구성이 다른 시스템보다 훨씬 더 복잡한 경향이 있지만 관리자가 이상적인 워크플로 및 프로세스를 설계할 수 있는 범위가 더 넓다는 것을 의미합니다. 빌드의 각 단계는 명확하게 구분되고 프로그래밍 가능합니다. Buildbot은 웹 프레임워크를 통해 사용자 정의 사이트를 구축할 수 있는 방법과 비교할 수 있는 사용자 정의 프로세스를 구축하는 도구가 있는 프레임워크로 자리매김합니다.

빌드 테스트 플랫폼으로서의 Buildbot의 역사는 다양한 운영 체제 및 버전 제어 시스템을 지원한다는 것을 의미합니다. 마찬가지로 오픈 소스 테스트를 염두에 두고 설계되었기 때문에 아키텍처를 통해 사용자는 선호하는 플랫폼을 가진 작업자를 프로젝트에 쉽게 제출하여 사용 가능한 테스트 기반을 확장할 수 있습니다. 사용자는 시스템에 몇 가지 Python 패키지를 설치한 다음 프로젝트에 자격 증명을 제공하기만 하면 됩니다.

Buildbot을 사용하여 빌드 프로세스를 자동화하려면 Ubuntu 16.04에 Buildbot을 설치하는 방법에 대한 가이드를 따르세요.

무인 비행기

Drone은 컨테이너 우선 아키텍처로 구축된 최신 CI/CD 플랫폼입니다. 위에서 논의한 모든 도구에는 Docker로 빌드를 실행하는 옵션이 포함되어 있지만 컨테이너 기반 워크플로우는 Drone 디자인의 핵심입니다. Drone은 Go로 작성되었으며 Apache 라이선스로 2014년에 처음 출시되었습니다.

Drone은 Docker와 리포지토리 공급자 간의 중간 조정 레이어 역할을 합니다. CI/CD 서버를 시작한 다음 나중에 서비스를 호스팅하는 버전 제어 시스템에 연결하는 대신 Drone은 자체 인증, 사용자 및 권한 모델을 부트스트랩하기 위해 사전에 리포지토리 계정 정보가 필요합니다. 모든 CI 프로세스와 마찬가지로 Drone 자체는 컨테이너로 실행됩니다. 여러 데이터베이스 백엔드 및 리포지토리 공급자를 지원하며 전송 암호화를 위해 Let's Encrypt로 TLS/SSL 인증서 설정을 기본적으로 지원합니다.

Drone은 파이프라인 정의를 위해 리포지토리 내에서 특수 YAML 파일을 찾습니다. 구문은 리포지토리를 사용하는 모든 사람이 지속적 통합 프로세스를 이해할 수 있도록 읽기 쉽고 표현력이 있도록 설계되었습니다. Drone은 플러그인 시스템을 제공하지만 Jenkins에서와는 다르게 사용됩니다. Drone에서 플러그인은 사전 구성된 작업을 일반 워크플로에 드롭하는 데 사용되는 특수 Docker 컨테이너입니다. 이렇게 하면 전체 프로세스를 수동으로 스크립팅하는 대신 몇 가지 매개 변수로 플러그인을 호출하여 일반적인 작업을 더 쉽게 수행할 수 있습니다. 이러한 의미에서 Drone 플러그인은 좁은 범위의 작업을 잘 수행하도록 설계된 Unix 유틸리티 명령과 다소 유사합니다.

커밋을 자동으로 테스트하도록 Drone 서버를 설정하는 방법을 알아보려면 Ubuntu 16.04에서 Drone을 설치하고 구성하는 방법 가이드를 따르세요.

집합

Concourse는 2014년에 처음 출시된 비교적 새로운 지속적 통합 플랫폼입니다. CI/CD 공간에 대한 Concourse의 접근 방식은 우리가 살펴본 다른 도구와 크게 다릅니다. 상태를 유지하고 모든 외부 요소를 "리소스\라고 부르는 것으로 추상화합니다. 이 철학의 목표는 동일한 프로세스가 모든 Concourse 서버에서 쉽게 실행될 수 있도록 통합 서버를 완전히 일회용으로 만드는 것입니다.

지속적인 통합 프로세스의 모든 부분은 시스템의 다양한 요소를 모델링하는 기본 프리미티브로 구성됩니다. 프로세스의 각 부분은 종속성을 명시적으로 정의합니다. 예를 들어, 첫 번째 작업에는 VCS 저장소에 대한 최신 커밋이 필요할 수 있고 프로세스의 후반 부분에는 이전 단계를 통과한 최신 커밋이 필요할 수 있습니다. 각 단계의 정확한 종속성을 매핑하여 파이프라인을 구성하는 이 방법은 엄격하게 정의된 동작으로 이어집니다.

프로세스에서 부수적인 상태를 추가로 제거하기 위해 Concourse는 작업 간에 아무 것도 암시적으로 전달하지 않으며 빌드 아티팩트를 저장하는 내부 방법을 제공하지 않습니다. 다음 단계에 필요한 모든 정보는 명시적으로 정의되어야 하며 잠재적으로 다음 단계로 가져오기 위해 외부 저장소로 푸시되어야 합니다. 명시적인 정의를 요구함으로써 Concourse는 시스템이 고려해야 하는 가정 및 알 수 없는 변수의 수를 최소화하기를 희망합니다.

Concourse는 Go로 작성되었으며 Apache 라이선스에 따라 출시되었습니다. 지속적인 통합 프로세스를 자동화하기 위해 Concourse 서버를 설정하는 방법을 알아보려면 Ubuntu 16.04에 Concourse CI를 설치하는 방법에 대한 가이드를 확인하세요.

결론

지속적인 통합, 제공 및 배포 소프트웨어는 프로세스를 신뢰할 수 있고 반복 가능하게 만들기 위해 설계된 복잡한 자동화 시스템입니다. 위의 설명에서 알 수 있듯이 방정식의 다른 부분에 중점을 두고 자동화된 테스트 및 릴리스가 가장 잘 수행되는 방법에 대한 다양한 아이디어가 있습니다. 단일 도구가 모든 프로젝트의 요구 사항을 충족하지는 못하지만 사용할 수 있는 고품질 오픈 소스 솔루션이 많기 때문에 팀의 요구 사항을 충족하는 시스템을 찾을 수 있는 좋은 기회가 있습니다.