GitLab CI 및 Jenkins

GitLab CI 및 Jenkins

---

Jenkins와 GitLab CI와 같은 다른 CI, drit.io와 Git 배포판의 차이점은 무엇입니까? 일부 연구에서 GitLab Community Edition으로 Jenkins를 추가 할 수는 없지만 GitLab Enterprise Edition은 추가 할 수 있다고 생각했습니다. 다른 중요한 차이점이 있습니까?

---

이것은 나의 경험이다 :

우리는 GitLab EE로 리포지토리를 관리하고 Jenkins 서버 (1.6)를 실행하고 있습니다.

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

TL; DR;

• Jenkins는 사용하기 쉽고 배우기 쉽지만 플러그인 지옥이 될 위험이 있습니다.
• Jenkins에는 GUI가 있습니다 (다른 사람들이 액세스하거나 유지 관리 해야하는 경우 선호 할 수 있음)
• GitLab과의 통합은 GitLab CI보다 적습니다.
• Jenkins는 저장소에서 분리 할 수 ​​있습니다

대부분의 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만큼 완벽하게 통합되는 것은 없습니다.

• 그들의 문서는 곧 시작될 것입니다.
• 시작 임계 값이 매우 낮습니다.
• 유지 보수가 쉽습니다 (플러그인 없음).
• 러너 스케일링은 간단합니다.
• CI는 저장소의 일부입니다.
• Jenkins 작업 /보기가 지저분해질 수 있습니다.

작성 당시 일부 특전 :

• Community Edition에서 단일 파일 만 지원합니다. Enterprise Edition의 다중 파일 .

---

나는 Rik의 메모 대부분에 동의하지만, 어느 것이 더 간단한 지에 대한 나의 의견은 반대이다 . GitLab은 훌륭한 도구가 될 수 있음을 증명하고있다.

전력의 대부분은 인에서 제공 자체 포함 하고 모든 것을 통합 동일한 브라우저 탭 같은 제품의를 : 저장소 브라우저, 문제 보드 또는 빌드 역사에서 배포 도구와에 모니터링 .

지금은 다른 Linux 배포판에 응용 프로그램을 설치하는 방법을 자동화하고 테스트하기 위해 지금 사용하고 있습니다. 빠른 구성 (Firefox에서 복잡한 Jenkins 작업 구성을 열고 응답하지 않는 스크립트가 나타날 때까지 기다리십시오) 가벼움 편집 방법 .gitlab-ci.yml).

러너 바이너리 덕분에 슬레이브 구성 / 스케일링에 소요되는 시간이 상당히 줄었습니다 . 또한 GitLab.com 에서는 꽤 괜찮은 무료 공유 러너를 얻을 수 있습니다.

Jenkins는 몇 주 동안 GitLab CI의 파워 유저 (예 : 지점 당 작업 복제, 플러그인 업로드 등 SCP 업로드와 같은 간단한 작업을 수행)를 수행 한 후 더 많은 매뉴얼 을 느꼈습니다. 오늘 내가 놓쳤던 유일한 유스 케이스는 둘 이상의 저장소가 관련된 경우입니다. 아직 잘 알아 내야합니다.

BTW, 나는 현재 저장소 CI 인프라를 구성하는 것이 어렵지 않은지를 보여주기 위해 GitLab CI에 대한 시리즈를 작성하고 있습니다. 지난주에 발표 된 첫 번째 기사는 다른 도구와의 기본, 장단점 및 차이점을 소개합니다. GitLab CI와의 빠르고 자연스러운 연속 통합

---

무엇보다도 오늘날 GitLab Community Edition은 Jenkins와 완벽하게 상호 운용 될 수 있습니다. 질문 없음.

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

이것이 귀하의 프로젝트에 대한 양질의 정보를 제공하기를 바랍니다.

GitLab CI 및 Jenkins의 강점

GitLab CI

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

이러한 파이프 라인 코드는 분명히 코드베이스에 저장되어 "모든 코드로서"실습 (접근, 버전 관리, 재현성, 재사용 성 등)을 강화할 수 있습니다.

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

• 기술적이지 않은 팀을 포함하여 모든 팀원은 응용 프로그램 수명주기 상태에 빠르고 쉽게 액세스 할 수 있습니다.
• therefore it can be used as a interactive and operational dashboard for release management.

Jenkins

Jenkins is a great build tool. It's strength is in its many plugins. Especially, I've had great luck in using interface plugins between Jenkins and other CI or CD tools. This is always a better option than to redevelop (possibly badly) a dialog interface between two components.

Pipeline as code is also available using groovyscripts.

Using GitLab CI and Jenkins together

It might sound a bit redundant at first, but combining GitLab CI and Jenkins is quite powerful.

• GitLab CI orchestrates (chains, runs, monitors...) pipelines and one can benefit its graphical interface integrated to GitLab
• Jenkins runs the job and facilitates dialog with third-party tools.

Another benefit of this design is to have loose coupling between the tools:

• we could replace any of the build factory components without having to rework the entire CI/CD process
• we could have a heterogeneous build environment, combining (possibly several) Jenkins, TeamCity, you name it, and still have a single monitoring tool.

The Trade-off

Well, of course, there is a price to pay for this design: the initial set-up is cumbersome and you need to have a minimal level of understanding of many tools.

For this reason, I don't recommend such a set-up unless

• you have many third-party tools to deal with. That's when Jenkins comes in super handy with its many plugins.
• you have to deal with complex applications with heterogeneous technologies, having each a different build environment, and still need to have a unified application life cycle management UI.

If you are in neither of these situations, you're probably better off with only one of the two, but not both.

If I had to pick one

Both GitLab CI and Jenkins have pros and cons. Both are powerful tools. So which one to choose?

Answer 1

Choose the one that your team (or someone close) has already a certain level of expertise in.

Answer 2

If you're all complete freshman in CI technologies, just pick one and get going.

• If you're using GitLab and have a knack for everything as code, it makes total sens to choose GitLab CI.
• If you have to dialog with many other CI/CD tools or absolutely need that GUI to build your jobs, go for Jenkins.

Those of you that are using GitLab and are not sure they will keep doing so still have to keep in mind that, having chosen GitLab CI would imply to trash all your CI / CD pipelines.

Final word is: the balance leans a little bit towards Jenkins because of its many plugins, but chances are GitLab CI will quickly fill the gap.

---

I would like to add some findings from my recent experimenting with GitLab CI. Features that came with 11.6 and 11.7 are just awesome!

Specifically I love only conditions which basically allow you to build separate pipelines for merge_request or push (the complete list is here)

Also, I really like the absence of plugins. When I need some more complex functionality I just write a custom Docker image that handles required functionality (it's the same concept as you can see in drone.io).

If you are wondering about DRY, it's absolutely possible nowadays! You can write your "templates,"

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

Put them to some public repository, include them in the main pipeline:

include:
  - remote: https://....

And use them to extend some job:

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

I love GitLab CI so much! Yeah, it (so far) can't draw nice graphs with coverage and so on, but overall it's a really neat tool!

Edit (2019-02-23): here's my post about things I love in GitLab CI. It was written in 11.7 "era" so when you're reading this answer, GitLab CI probably has many more features.

Edit (2019-07-10): Gitlab CI now supports multiple extends e.g.

extends:
 - .pieceA
 - .pieceB

Check the official documentation to get more info about multiple extends

---

if your build/publish/deploy and test jobs are not heavily complex then using gitlab ci has natural advantages.

Since gitlab-ci.yml is present alongside your code in every branch, you can modify your ci/cd steps particularly tests(which differs across environments) more effectively.

For an example, you want to do unit testing for any checkin to dev branch whereas you might want carry out full fledged functional testing on QA branch and a limited only get type of tests on production this can be achieved easily using gitlab ci.

second advantage apart from great UI is its ability to use docker images for executing any stage keeps the host runner intact and thus less error prone.

moreover gitlab ci would automatically checkin for you and you dont have to manage jenkins master separately

참고URL : https://stackoverflow.com/questions/37429453/gitlab-ci-vs-jenkins