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

소개

Continuous integration, delivery, and deployment는 개발 속도를 높이고 좋은 테스트를 거친 사용 가능한 제품의 발표를 돕기 위한 전략이다.지속적인 통합은 개발진이 공유 코드 라이브러리에 대한 변경 사항을 가능한 한 빨리 테스트하고 통합하여 통합 충돌을 최대한 줄이도록 장려한다.지속적인 교부는 배치 또는 발표 과정에서의 장애를 없애고 이를 바탕으로 한다.연속 배치는 더욱 진일보하고 테스트 세트의 모든 구축을 통해 자동으로 배치된다.
위의 용어는 주로 전략과 실천에 관련되지만 소프트웨어 도구는 조직이 이러한 목표를 실현하도록 허락하는 데 중요한 역할을 발휘한다.CI/CD 소프트웨어는 팀이 일련의 단계를 통해 새로운 변경을 자동으로 추진하여 피드백 시간을 줄이고 절차에서의 마찰을 없애는 데 도움을 줄 수 있다.
이 안내서에서 우리는 협업 소프트웨어 개발을 간소화하기 위해 일부 유행하는 무료와 오픈소스의 지속적인 통합, 납품과 배치 서버를 비교할 것이다.Jenkins, GitLab CI, Buildbot, Drone, Concourse에 대해 알아보겠습니다.

젠킨스

Jenkins는 최초의 오픈 소스 지속적인 통합 서버 중 하나로 지금까지도 가장 자주 사용되는 옵션이다.처음에는 Hudson 프로젝트의 일부로 지역사회와 코드 라이브러리는 원 개발자인 Sun Microsystems를 인수한 후 Oracle과 상표 충돌을 일으킨 후 분열되었다.Hudson은 2005년에 처음 발표되었고 Jenkins는 2011년에 처음으로 발표되었다.
여러 해 동안 Jenkins는 강력하고 유연한 자동화 소프트웨어 관련 임무를 수행하는 시스템으로 발전했다.Jenkins 자체는 주로 자동화 프레임워크로서 플러그인 라이브러리를 통해 많은 중요한 논리를 실현한다.웹 연결이나 메모리 라이브러리 보기부터 구축 환경과 언어 지원까지 모든 내용은 플러그인으로 처리됩니다.이것은 매우 유연성을 제공하지만, 당신의 CI 과정은 많은 제3자 플러그인에 의존할 수 있으며, 이 플러그인들은 매우 취약할 수 있습니다.
Jenkins의 파이프라인 작업 흐름도 플러그인을 통해 제공된다. 이것은 비교적 새로운 보충으로 2016년부터 제공된다.저장소 자체의 파일에 있는 Groovy language 또는 Jenkins 웹 UI에 있는 텍스트 상자를 통해 CI 프로세스를 선언하거나 강제적으로 정의할 수 있습니다.Jenkins의 흔한 비판은 플러그인 중심의 설정 모델과 저장소 밖에서 파이프를 정의하거나 프로세스를 구축하는 능력이 때때로 서로 다른 Jenkins 실례에서 쉽게 설정을 복제하기 어렵다는 것이다.
Jenkins는 MIT 라이센스에 따라 Java로 작성되었습니다.설명서how to install Jenkins on Ubuntu 16.04에 따라 프로젝트에 Jenkins 서버를 구성합니다.

GitLab CI

GitLab CI은git 메모리 라이브러리 위탁 관리 및 개발 도구 플랫폼GitLab에 내장된 지속적인 통합 도구입니다.GitLab CI는 처음에 독립된 프로젝트로 발표되었는데 2015년 9월에 GitLab 8.0이 발표되면서 주요 GitLab 소프트웨어에 통합되었다.
GitLab CI의 CI/CD 프로세스는 YAML 구성 구문을 사용하여 코드 저장소 자체의 파일에 정의됩니다.그리고 작업을 Runner라는 기계에 분배합니다. 이 기계들은 설치하기 쉬우며 여러 가지 다른 운영체제에서 설정할 수 있습니다.실행 프로그램을 설정할 때 Docker, 셸, VirtualBox 또는 Kubernetes 등 서로 다른 실행기 중에서 선택하여 작업의 실행 방식을 결정할 수 있습니다.
GitLab CI와 GitLab 저장소 플랫폼의 긴밀한 결합은 소프트웨어의 사용 방식에 어느 정도 영향을 미친다.GitLab CI는 다른 저장소 관리 플랫폼을 사용하는 개발자의 선택이 아닙니다.적극적인 측면에서 볼 때, 통합된 기능은 GitLab 사용자가 다른 도구를 설치하고 학습할 필요가 없이 CI/CD 환경을 구축할 수 있도록 한다.자동화 테스트는 웹 인터페이스에서 몇 가지 옵션을 사용하기 시작하여runner 컴퓨터를 등록하고 파이프 정의 파일을 저장소에 추가할 수 있습니다.이러한 밀접한 관계를 통해 프로젝트 간에 운영자를 공유하여 저장소의 현재 구축 상태를 자동으로 보고 생성된 코드를 사용하여 구축 부품을 보존할 수 있습니다.
GitLab과 GitLab CI는 모두 Ruby와 Go로 작성되었으며 MIT 라이센스에 따라 발표되었습니다.GitLab 서버에서 이 기능을 구성하는 방법은 how to set up continuous integration pipelines with GitLab CI 의 지침에 따라 학습할 수 있습니다.

Buildbot

Buildbot는 지속적인 통합 프레임워크로 매우 큰 유연성을 제공한다.Buildbot은 2003년에 처음으로 발표되었고Mozilla Tinderbox 프로젝트의 대체 방안으로서 그 설계는 주로 각종 플랫폼에서 자동화 구축 테스트를 위한 것이다.
Buildbot은 GPL 라이센스를 통해 발표되며 Twisted 라이브러리를 사용하여 Python으로 작성됩니다.Buildbot의 설정은 완전히 Python으로 작성된 것이지 설정을 간소화하기 위해 하위 언어를 추상화한 것이 아니다.이것은 설정이 다른 시스템보다 훨씬 복잡하지만 관리자가 이상적인 작업 흐름과 절차를 설계할 수 있는 공간이 더 많다는 것을 의미한다.구축된 모든 단계는 명확하게 분리되고 프로그래밍할 수 있다.Buildbot은 웹 프레임워크가 사용자 정의 사이트를 구축할 수 있도록 하는 방법과 같은 사용자 정의 프로세스를 구축하는 도구를 가지고 있습니다.
Buildbot은 테스트 플랫폼을 구축한 역사로서 다양한 운영체제와 버전 제어 시스템을 지원한다는 것을 의미한다.마찬가지로 개원 테스트를 고려한 디자인이기 때문에 시스템 구조는 사용자가 프로젝트에 선호하는 플랫폼을 가진 직원을 쉽게 제출하여 사용 가능한 테스트 기반을 확장할 수 있도록 한다.사용자는 시스템에 몇 개의 Python 패키지를 설치한 후에 프로젝트에 증거를 제공하기만 하면 된다.
Buildbot 자동화 구축 프로세스를 시작하려면 설명서how to install Buildbot on Ubuntu 16.04를 따르십시오.

윙윙거리는 소리

Drone는 용기 우선 구조로 구축된 현대 CI/CD 플랫폼이다.위에서 논의한 도구는 모두 Docker를 사용하여 구축을 실행하는 옵션을 포함하지만, 용기 기반 작업 흐름은 Drone 디자인의 핵심이다.Drone은 Go로 작성되어 2014년 Apache 라이센스에 따라 처음 출시되었습니다.
Drone은 Docker와 저장소 공급자 간의 중간 조정 레이어로 사용됩니다.Drone은 CI/CD 서버를 시작한 다음 버전 제어 시스템 관리 서비스에 연결할 필요가 없고, 저장소 계정 정보가 자신의 신분 검증, 사용자 및 권한 모델을 미리 안내해야 합니다.모든 CI 프로세스와 마찬가지로 Drone 자체도 컨테이너로 실행됩니다.여러 데이터베이스 백엔드 및 라이브러리 공급자를 지원하며 TLS/SSL 인증서를 사용하여 암호화를 전송할 수 있도록 내장되어 있습니다.
Drone은 파이프 정의 저장소에서 특수한 YAML 파일을 찾습니다.문법은 라이브러리를 사용하는 누구나 연속적인 통합 과정을 이해할 수 있도록 읽기와 표현이 쉽도록 설계되었다.Drone은 Jenkins와 달리 플러그인 시스템을 제공합니다.Drone에서 플러그인은 일반 워크플로우에 미리 구성된 작업을 넣을 수 있는 특수 Docker 컨테이너입니다.이것은 전체 과정의 스크립트를 수동으로 작성하지 않고 몇 개의 매개 변수를 사용하여 플러그인을 호출하여 일반적인 작업을 완성하는 것을 더욱 쉽게 한다.이런 의미에서 볼 때, Drone 플러그인은 유닉스 유틸리티 명령과 약간 비슷하다. 이 명령들은 좁은 의미의 임무를 잘 수행하기 위한 것이다.
제출을 자동으로 테스트하기 위해 무인기 서버를 설정하는 방법을 알고 싶으시면 저희 Let’s Encrypt 안내서를 따르십시오.

대청

how to install and configure Drone on Ubuntu 16.04는 비교적 새로운 지속적인 통합 플랫폼으로 2014년에 처음 발표되었다.Concourse가 CI/CD 공간에 대한 방법은 우리가 연구한 다른 도구와 현저하게 다르다. 왜냐하면 이것은 가능한 한 자신을 등식에서 벗어나 상태를 최소화하고 모든 외부 요소를 그가 칭하는'자원'으로 추상화하려고 하기 때문이다.이 이념의 목표는 모든 Concourse 서버에서 같은 프로세스를 쉽게 실행할 수 있도록 통합 서버를 완전히 버리는 것이다.
연속 집적 과정의 모든 부분은 기본 원어로 구성되어 있는데 이런 원어는 시스템의 서로 다른 요소를 모델링한다.절차의 모든 부분은 그 의존 관계를 명확하게 정의했다.예를 들어 첫 번째 작업은 VCS 저장소를 최신 제출해야 할 수도 있고, 절차의 후속 부분은 이전 몇 단계의 최신 제출을 거쳐야 할 수도 있다.모든 단계의 정확한 의존 관계를 비추어 파이프를 구축하는 이런 방법은 엄격하게 정의된 행위를 초래했다.
프로세스에서 부대 상태를 삭제하기 위해 Concourse는 작업 간에 어떤 내용도 은밀하게 전달하지 않고 구축 부품을 저장하는 내부 방식도 제공하지 않습니다.다음 단계에 필요한 모든 정보를 명확하게 정의해야 하며, 다음 단계로 넘어가기 위해 외부 저장소로 밀어넣을 수 있습니다.명확한 정의를 요구함으로써 Concourse는 시스템이 고려해야 할 가설과 미지의 변수의 수를 최대한 줄이기를 희망한다.
Concourse는 Go로 작성되었으며 Apache 라이센스에 따라 게시됩니다.Concourse 서버를 설정하여 연속적인 통합 프로세스를 자동화하는 방법을 알고 싶으면 안내서Concourse를 참조하십시오.

결론

지속적인 통합, 제공 및 배포 소프트웨어는 프로세스를 신뢰할 수 있고 반복할 수 있도록 설계된 복잡한 자동화 시스템입니다.위의 설명을 통해 알 수 있듯이 자동화 테스트와 발표를 어떻게 가장 잘 완성하는지에 대해 많은 다른 생각이 있고 등식의 다른 부분에 중점을 두고 있다.모든 프로젝트의 수요를 충족시킬 수 있는 단일한 도구는 없지만, 이렇게 많은 고품질의 소스 개발 솔루션을 사용할 수 있으니, 당신은 팀의 수요를 만족시키는 시스템을 찾을 수 있을 것입니다.