programing

GitLab CI 대젠킨스

oldcodes 2023. 9. 16. 09:52
반응형

GitLab CI 대젠킨스

Jenkins와 GitLab CI와 같은 다른 CI와 Git 배포판과 함께 제공되는 drone.io 의 차이점은 무엇입니까?몇 가지 조사에 따르면 GitLab 커뮤니티 에디션은 Jenkins를 추가할 수 없지만 GitLab 엔터프라이즈 에디션은 추가할 수 있습니다.다른 중요한 차이점이 있습니까?

이것이 제 경험입니다.

저희 회사에서는 GitLab EE로 저장소를 관리하고 Jenkins 서버(1.6)를 실행하고 있습니다.

기본적으로 그들은 거의 같은 일을 합니다.서버/도커 이미지에서 일부 스크립트를 실행합니다.

TL;DR;

  • Jenkins는 사용/학습이 더 쉽지만 플러그인 지옥이 될 위험이 있습니다.
  • Jenkins(Jenkins)는 GUI를 가지고 있습니다(다른 사용자가 액세스/유지보수할 필요가 있습니다.
  • GitLab과의 통합은 GitLab CI와의 통합보다 적음
  • Jenkins는 당신의 저장소에서 분리될 수 있습니다.

대부분의 CI 서버는 매우 간단합니다(concourse.ci , gitlab-ci, circle-ci, travis-ci, drone.io , gocd 등이 있습니다.YAML 파일 정의에서 셸/배트 스크립트를 실행할 수 있습니다.Jenkins는 훨씬 더 플러그인이 가능하며 UI와 함께 제공됩니다.이것은 당신의 필요에 따라 장점이 될 수도 있고 단점이 될 수도 있습니다.

Jenkins는 사용 가능한 모든 플러그인 때문에 매우 구성 가능합니다.이것의 단점은 CI 서버가 플러그인의 스파게티가 될 수 있다는 것입니다.

Jenkins에서 작업을 체인하고 조정하는 것은 (UI 때문에) YAML(콜링 컬 명령어)을 통해 하는 것보다 훨씬 간단하다고 생각합니다.이외에도 Jenkins는 특정 이진 파일이 서버에서 사용할 수 없을 때 설치하는 플러그인을 지원합니다(다른 사용자의 경우에는 알 수 없음).

요즘 (Jenkins 2는 또한 더 많은 "적절한 ci"를 지원합니다.Jenkinsfile그리고 Jenkins 2)에서 기본값으로 제공되는 파이프라인 플러그인(pipline plugin), 즉, 저장소에 덜 연결되어 있었습니다.GitLab CI.

빌드 파이프라인을 정의하기 위해 YAML 파일을 사용하는 것이 더 깔끔합니다(결국 순수 셸/배트를 실행하는 것).

Jenkins에서 사용할 수 있는 플러그인을 통해 테스트 결과, 적용 범위 및 기타 정적 분석기와 같은 모든 종류의 보고서를 시각화할 수 있습니다.물론 언제든지 작성하거나 도구를 사용하여 이러한 작업을 수행할 수 있지만 Jenkins(특히 이러한 보고서를 너무 중요하게 여기는 관리자)에게는 분명 이점이 됩니다.

최근에 저는 GitLab CI와 점점 더 많은 작업을 하고 있습니다.GitLab에서 그들은 모든 경험을 재미있게 만드는 일을 정말 잘 하고 있습니다.사람들이 Jenkins를 사용하는 것은 이해하지만 GitLab을 실행하고 사용할 수 있게 되면 GitLab CI를 시작하는 것은 매우 쉽습니다.타사 통합에 상당한 노력을 기울였지만 GitLab CI처럼 원활하게 통합되는 것은 없을 것입니다.

  • 그들의 문서가 곧 당신을 시작하게 할 것입니다.
  • 시작할 임계값이 매우 낮습니다.
  • 유지보수가 간편합니다(플러그인 없음).
  • 러너의 스케일링은 간단합니다.
  • CI는 저장소의 전체 부분입니다.
  • 젠킨스의 직업/뷰는 엉망이 될 수 있습니다.

작성 시 몇 가지 특전:

  • 커뮤니티 에디션에서는 단일 파일만 지원합니다.엔터프라이즈 에디션의 파일을 여러 개 만듭니다.

대부분의 Rik의 노트에 동의하지만, 어떤 것이 더 간단한지에 대한 제 의견은 반대입니다. GitLab은 작업하기에 멋진 도구임을 증명하고 있습니다.

대부분의 기능은 저장소 브라우저, 이슈 보드 또는 빌드 기록에서 배포 도구 및 모니터링에 이르기까지 동일한 브라우저 탭 아래에 있는 모든 제품자체적으로 통합하고 통합하는 데서 비롯됩니다.

애플리케이션이 다양한 Linux 배포 환경에 설치되는 방법을 자동화하고 테스트하는 데 사용하고 있습니다. 구성하는 속도가 매우 빠릅니다(Firefox에서 복잡한 Jenkins 작업 구성을 열고 응답하지 않는 스크립트가 나올 때까지 기다리십시오.편집이 얼마나 가벼운지.gitlab-ci.yml).

러너 바이너리 덕분에 슬레이브를 구성/저장하는 데 걸리는 시간이 상당히 줄어들었습니다. 게다가 GitLab.com 에서 꽤 괜찮은 공유 러너를 얻을 수 있다는 사실도 말입니다.

Jenkins는 GitLab CI의 강력한 사용자가 된 지 몇 주 만에 더 수동적으로 느껴집니다. 예를 들어 지점당 작업 복제, SCP 업로드와 같은 간단한 작업을 수행하기 위한 플러그인 설치 등입니다.오늘날 제가 직면한 유일한 사용 사례는 두 개 이상의 저장소가 관련되어 있는 경우입니다. 아직 잘 파악해야 합니다.

그건 그렇고, 저는 현재 GitLab CI에 대한 시리즈를 작성하고 있는데, 이를 통해 저장소 CI 인프라스트럭처를 구성하는 것이 그리 어렵지 않다는 것을 보여줍니다.지난 주에 출판된 첫 번째 기사는 기본 사항, 장단점 및 다른 도구와의 차이점을 소개하는 것입니다.GitLab CI와 빠르고 자연스러운 연속 통합

우선, 현재 GitLab Community Edition은 Jenkins와 완전히 상호 운용될 수 있습니다.당연하죠.

이하에서는 Jenkins와 GitLab CI를 결합한 성공적인 경험에 대한 피드백을 드립니다.둘 다 사용해야 하는지 아니면 둘 중 하나만 사용해야 하는지, 어떤 이유로 사용해야 하는지에 대해서도 논의하겠습니다.

이것이 당신의 프로젝트에 대한 양질의 정보를 줄 수 있기를 바랍니다.

GitLab CI 및 Jenkins의 장점

깃랩 CI

GitLab CI는 GitLab SCM에 자연스럽게 통합되어 있습니다.다음을 사용하여 파이프라인을 생성할 수 있습니다.gitlab-ci.yml파일을 생성하고 그래픽 인터페이스를 통해 조작합니다.

코드로서의 이러한 파이프라인은 코드 베이스에 저장되어 "코드로서의 모든 것"을 실행할 수 있습니다(액세스, 버전화, 재현성, 재사용성 등).

GitLab CI는 훌륭한 시각적 관리 도구입니다.

  • 비기술 팀을 포함한 팀의 모든 구성원은 애플리케이션 수명 주기 상태에 빠르고 쉽게 접근할 수 있습니다.
  • 따라서 릴리스 관리를 위한 대화형운영 대시보드로 사용할 수 있습니다.

젠킨스

Jenkins는 훌륭한 제작 도구입니다.플러그인이 많은 것이 강점입니다.특히 Jenkins와 다른 CI 또는 CD 도구 사이에서 인터페이스 플러그인을 사용하는 데 큰 행운이 있었습니다.이것은 두 구성 요소 사이의 대화 인터페이스를 재개발하는 것보다 항상 더 나은 옵션입니다.

코드로서의 파이프라인은 다음을 사용하여 사용할 수 있습니다.groovycripts

GitLab CI와 Jenkins를 함께 사용

처음에는 좀 중복적으로 들릴 수도 있지만, GitLab CI와 Jenkins를 결합하는 것은 상당히 강력합니다.

  • GitLab CI 오케스트레이션(체인, 실행, 모니터 등) 파이프라인을 통해 GitLab에 통합된 그래픽 인터페이스를 활용할 수 있습니다.
  • Jenkins는 작업을 실행하고 타사 도구를 사용하여 대화를 용이하게 합니다.

이 설계의 또 다른 장점은 공구 사이의 결합이 느슨하다는 것입니다.

  • 전체 CI/CD 프로세스를 재작업할 필요 없이 빌드 팩토리 구성요소를 교체할 수 있었습니다.
  • Jenkins와 TeamCity를 결합하여 이기종 빌드 환경을 구축할 수도 있습니다(몇 개일 가능성 있음). 하지만 모니터링 툴은 하나만 보유할 수도 있습니다.

트레이드 오프

물론 이 설계에는 비용이 들지만 초기 설정은 번거롭고 많은 도구에 대한 최소한의 이해가 필요합니다.

이러한 이유로, 나는 만일 그렇지 않다면 그러한 셋업을 추천하지 않습니다.

  • 처리해야 할 제3자 도구가 많습니다.그때 젠킨스가 많은 플러그인을 아주 편리하게 사용할 수 있습니다.
  • 이기종 기술을 사용하는 복잡한 애플리케이션을 처리해야 하고, 각 구축 환경이 다르면서도 통합된 애플리케이션 라이프사이클 관리 UI를 가져야 합니다.

만약 당신이 이 두 가지 상황에 있지 않다면, 둘 중 하나만 있는 것이 더 나을지도 모르지만, 둘 다는 아닙니다.

굳이 꼽자면.

GitLab CI와 Jenkins 모두 장단점이 있습니다.둘 다 강력한 도구입니다.그럼 어떤 걸 고를까요?

정답 1

팀(또는 가까운 사람)이 이미 일정 수준의 전문 지식을 가지고 있는 사람을 선택합니다.

정답2

CI 기술 분야에 완전히 입문하신 분들은 한 가지만 선택하고 시작하시면 됩니다.

  • GitLab을 사용하고 코드로서 모든 것에 대한 요령이 있다면 GitLab CI를 선택하는 것이 완전히 합리적입니다.
  • 다른 많은 CI/CD 도구와 대화해야 하거나 작업을 구축하기 위해 해당 GUI가 꼭 필요한 경우 Jenkins를 찾아 보십시오.

GitLab을 사용하고 있지만 앞으로도 계속 사용할 것인지 확신하지 못하는 분들은 GitLab CI를 선택한 경우 모든 CI/CD 파이프라인이 폐기된다는 것을 의미한다는 것을 명심해야 합니다.

마지막으로, 플러그인이 많기 때문에 균형이 약간 Jenkins 쪽으로 기울지만 GitLab CI가 빠르게 그 공백을 메울 가능성이 있습니다.

최근 GitLab CI에 대한 실험 결과를 추가하고자 합니다.11.6과 11.7과 함께 나온 기능들은 정말 멋집니다!

특히 나는 사랑합니다.only기본적으로 당신이 별도의 파이프라인을 건설할 수 있게 해주는 조건.merge_request아니면push(전체 목록이 여기에 있습니다)

그리고 플러그인이 없는 것도 정말 마음에 듭니다.좀 더 복잡한 기능이 필요할 때는 필요한 기능을 처리하는 사용자 정의 도커 이미지를 작성합니다(drone.io 에서 볼 수 있는 개념과 동일함).

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 "era"로 작성되었으니 이 답변을 읽어보면 GitLab CI에 더 많은 기능이 있을 것입니다.

편집(2019-07-10): Gitlab CI에서 여러 개 지원extends예.

extends:
 - .pieceA
 - .pieceB

여러 확장에 대한 자세한 정보를 보려면 공식 문서를 확인하십시오.

빌드/프로그래밍/테스트 작업이 그리 복잡하지 않다면 gitlabci를 사용하면 자연스럽게 이점이 있습니다.

gitlab-ci.yml은 모든 분기에 코드와 함께 존재하므로 ci/cd 단계, 특히 테스트(환경에 따라 다름)를 보다 효과적으로 수정할 수 있습니다.

예를 들어, 개발 지점에 체크인할 경우 장치 테스트를 수행하는 반면 QA 지점에서 본격적인 기능 테스트를 수행하고 gitlabci를 사용하여 쉽게 구현할 수 있는 제한된 유형의 테스트를 수행하는 것을 원할 수 있습니다.

훌륭한 UI와 별개로 두 번째 장점은 어떤 스테이지를 실행할 때 도커 이미지를 사용할 수 있다는 점이며 따라서 호스트 러너가 손상되지 않고 오류가 발생하기 쉽습니다.

게다가 gitlab ci는 자동으로 당신을 위해 체크인 할 것이고 당신은 jenkins master를 따로 관리할 필요가 없습니다.

언급URL : https://stackoverflow.com/questions/37429453/gitlab-ci-vs-jenkins

반응형