Jenkins와 GitLab CI와 같은 다른 CI, drit.io와 Git 배포판의 차이점은 무엇입니까? 일부 연구에서 GitLab Community Edition으로 Jenkins를 추가 할 수는 없지만 GitLab Enterprise Edition은 추가 할 수 있다고 생각했습니다. 다른 중요한 차이점이 있습니까?
답변:
이것은 나의 경험이다 :
우리는 GitLab EE로 리포지토리를 관리하고 Jenkins 서버 (1.6)를 실행하고 있습니다.
기본적으로 그들은 거의 동일합니다. 서버 / 도커 이미지에서 일부 스크립트를 실행합니다.
TL; DR;
대부분의 CI 서버는 매우 간단합니다 ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd 및 기타 무엇입니까). YAML 파일 정의에서 쉘 / bat 스크립트를 실행할 수 있습니다. Jenkins는 훨씬 더 플러그 가능하며 UI가 제공됩니다. 이는 필요에 따라 장점 또는 단점이 될 수 있습니다.
Jenkins는 사용 가능한 모든 플러그인으로 인해 매우 구성 가능합니다. 이것의 단점은 CI 서버가 플러그인 스파게티가 될 수 있다는 것입니다.
내 의견으로는 Jenkins에서 작업 체인 및 오케스트레이션은 YAML (컬 명령 호출)보다 훨씬 간단합니다 (UI 때문에). 그 외에도 Jenkins는 서버에서 사용할 수없는 특정 바이너리를 설치할 수있는 플러그인을 지원합니다 (다른 것에 대해서는 몰라).
요즘 Jenkins 2 는 Jenkins 2 에서 기본으로 제공 Jenkinsfile되는 pipline 플러그인 과 함께 더 많은 "적절한 ci"를 지원 하지만 GitLab CI보다 저장소에 덜 연결되어있었습니다.
YAML 파일을 사용하여 빌드 파이프 라인을 정의하고 결국 순수 쉘 / 배트를 실행하는 것이 더 깔끔합니다.
Jenkins에 사용 가능한 플러그인을 사용하면 테스트 결과, 적용 범위 및 기타 정적 분석기와 같은 모든 종류의보고를 시각화 할 수 있습니다. 물론 항상 도구를 작성하거나 사용하여이 작업을 수행 할 수 있지만 Jenkins (특히이 보고서를 너무 중요하게 생각하는 관리자)에게는 확실히 도움이됩니다.
최근에 GitLab CI와 함께 점점 더 많은 작업을 해왔습니다. GitLab에서 그들은 전체 경험을 재미있게 만드는 훌륭한 일을하고 있습니다. 사람들이 Jenkins를 사용한다는 것을 알고 있지만 GitLab을 실행하고 사용할 수있는 경우 GitLab CI를 시작하기가 정말 쉽습니다. 타사 통합에 상당한 노력을 기울 였음에도 불구하고 GitLab CI만큼 완벽하게 통합되는 것은 없습니다.
작성 당시 일부 특전 :
나는 Rik의 메모 대부분에 동의하지만, 어느 것이 더 간단한 지에 대한 나의 의견은 반대이다 . GitLab은 훌륭한 도구가 될 수 있음을 증명하고있다.
전력의 대부분은 인에서 제공 자체 포함 하고 모든 것을 통합 동일한 브라우저 탭 같은 제품의를 : 저장소 브라우저, 문제 보드 또는 빌드 역사에서 배포 도구와에 모니터링 .
지금은 다른 Linux 배포판에 응용 프로그램을 설치하는 방법을 자동화하고 테스트하기 위해 지금 사용하고 있습니다. 빠른 구성 (Firefox에서 복잡한 Jenkins 작업 구성을 열고 응답하지 않는 스크립트가 나타날 때까지 기다리십시오) 가벼움 편집 방법 .gitlab-ci.yml).
러너 바이너리 덕분에 슬레이브 구성 / 스케일링에 소요되는 시간이 상당히 줄었습니다 . 또한 GitLab.com 에서는 꽤 괜찮은 무료 공유 러너를 얻을 수 있습니다.
Jenkins는 몇 주 동안 GitLab CI의 파워 유저 (예 : 지점 당 작업 복제, 플러그인 업로드 등 SCP 업로드와 같은 간단한 작업을 수행)를 수행 한 후 더 수동적 인 느낌 을 받았습니다. 오늘 내가 놓쳤던 유일한 유스 케이스는 둘 이상의 저장소가 관련된 경우입니다. 아직 잘 알아 내야합니다.
BTW, 나는 현재 저장소 CI 인프라를 구성하는 것이 어렵지 않은지를 보여주기 위해 GitLab CI에 대한 시리즈를 작성하고 있습니다. 지난주에 발표 된 첫 번째 기사는 다른 도구와의 기본, 장단점 및 차이점을 소개합니다. GitLab CI와의 빠르고 자연스러운 연속 통합
Jenkinsfile. Jenkinsfile코드를 실행할 수있는 groovy (+ 추가 Java 라이브러리)가있는 것이 맞습니다 . .gitlab-ci.yaml파일은 주로 셸을 지원하지만 러너의 위치에 따라 다릅니다. 반면에 쉘 스크립트 에서도이 모든 것을 호출 할 수 있지만 단점은 머신 종속성을 생성한다는 것입니다 (제 의견으로는 투명하지 않습니다).
무엇보다도 오늘날 GitLab Community Edition은 Jenkins와 완벽하게 상호 운용 될 수 있습니다. 질문 없음.
다음은 Jenkins와 GitLab CI를 결합한 성공적인 경험에 대한 피드백입니다. 또한 두 가지 중 하나만 사용해야하는지, 어떤 이유로 사용해야하는지에 대해서도 논의하겠습니다.
이것이 귀하의 프로젝트에 대한 양질의 정보를 제공하기를 바랍니다.
GitLab CI
GitLab CI는 GitLab SCM에 자연스럽게 통합되어 있습니다. gitlab-ci.yml파일을 사용하여 파이프 라인을 생성 하고 그래픽 인터페이스를 통해 파이프 라인을 조작 할 수 있습니다.
이러한 파이프 라인 코드는 분명히 코드베이스에 저장되어 "모든 코드로서"실습 (접근, 버전 관리, 재현성, 재사용 성 등)을 강화할 수 있습니다.
GitLab CI는 훌륭한 시각적 관리 도구입니다.
젠킨스
Jenkins는 훌륭한 빌드 도구입니다. 그것은 많은 플러그인에 강점입니다. 특히 Jenkins와 다른 CI 또는 CD 도구 사이의 인터페이스 플러그인을 사용하면 행운이있었습니다. 이것은 두 구성 요소 사이의 대화 상자 인터페이스를 다시 개발하는 것보다 항상 더 나은 옵션입니다.
groovy스크립트를 사용하여 파이프 라인을 코드로 사용할 수도 있습니다 .
처음에는 약간 중복되는 것처럼 들릴 수 있지만 GitLab CI와 Jenkins를 결합하는 것은 매우 강력합니다.
이 설계의 또 다른 이점은 도구간에 느슨하게 커플 링되는 것입니다.
물론,이 디자인에 대한 대가가 있습니다 : 초기 설정은 번거롭고 많은 도구에 대한 최소한의 이해가 필요합니다.
이러한 이유로, 나는 이러한 설정을 권장하지 않습니다
이러한 상황에 처하지 않은 경우 두 가지 중 하나만 사용하는 것이 좋습니다.
GitLab CI와 Jenkins 모두 장단점이 있습니다. 둘 다 강력한 도구입니다. 어느 것을 선택할까요?
답변 1
팀 (또는 가까운 사람)이 이미 특정 수준의 전문 지식을 보유한 팀을 선택하십시오.
답변 2
CI 기술의 모든 신입생이라면, 하나만 골라 가십시오.
GitLab을 사용하고 있고 계속 그렇게할지 확실하지 않은 사용자는 여전히 GitLab CI를 선택하면 모든 CI / CD 파이프 라인을 휴지통에 버릴 것임을 명심해야합니다.
마지막으로 , 플러그인은 플러그인이 많기 때문에 잔 킨스는 젠킨스 에게 약간 기울어 지지만 GitLab CI가 그 격차를 빠르게 채울 것입니다.
최근 GitLab CI 실험에서 얻은 결과를 추가하고 싶습니다. 11.6 및 11.7과 함께 제공되는 기능은 정말 대단합니다!
특히 나는 only기본적으로 merge_request또는 별도의 파이프 라인을 만들 수있는 조건을 좋아 합니다 push(전체 목록은 여기에 있습니다 )
또한 플러그인이없는 것이 정말 좋습니다. 좀 더 복잡한 기능이 필요할 때 필요한 기능을 처리하는 사용자 지정 Docker 이미지를 작성하기 만합니다 (드론 에서 볼 수있는 것과 동일한 개념입니다). ).
DRY 에 대해 궁금 하다면 요즘 절대적으로 가능합니다! "템플릿"을 작성할 수 있습니다.
.myTemplate:
image: node:10.14.2
script:
- npm install
- npm run test
공개 파이프 라인에 배치하고 기본 파이프 라인에 포함하십시오.
include:
- remote: https://....
그리고 그것들을 사용하여 일을 확장하십시오 :
test:
extends: .myTemplate
only:
refs: ["master"]
variables:
- $CI_PIPELINE_SOURCE == "push"
나는 GitLab CI를 너무 좋아합니다!예, (지금까지) 적용 범위 등으로 멋진 그래프를 그릴 수는 없지만 전반적으로 정말 깔끔한 도구입니다!
편집 (2019-02-23) : 여기 내 게시물이 있습니다 GitLab CI에서 내가 좋아 것에 있습니다. 11.7 "시대"로 작성되었으므로이 답변을 읽을 때 GitLab CI에는 더 많은 기능이있을 것입니다.
편집 (2019-07-10) : Gitlab CI는 이제 여러 extends예를 지원합니다
extends:
- .pieceA
- .pieceB
여러 확장 에 대한 자세한 정보는 공식 문서를 확인하십시오.
빌드 / 게시 / 배포 및 테스트 작업이 크게 복잡하지 않은 경우 gitlab ci를 사용하면 자연스러운 이점이 있습니다.
gitlab-ci.yml은 모든 브랜치에서 코드와 함께 제공되므로 ci / cd 단계, 특히 테스트 (환경에 따라 다름)를보다 효과적으로 수정할 수 있습니다.
예를 들어, 모든 체크인 지점에서 dev 지점으로의 단위 테스트를 수행하는 반면 QA 지점에서 완전한 기능 테스트를 수행하고 생산에 대한 제한된 유형의 테스트 만 gitlab ci를 사용하여 쉽게 얻을 수 있습니다.
뛰어난 UI와 다른 두 번째 장점은 모든 단계를 실행하기 위해 도커 이미지를 사용하는 기능으로 호스트 러너를 손상시키지 않고 오류 발생 가능성을 줄입니다.
또한 gitlab ci가 자동으로 체크인되며 jenkins 마스터를 별도로 관리 할 필요가 없습니다.