GitLab CI so với Jenkins [đã đóng]

Sự khác biệt giữa Jenkins và các CI khác như GitLab CI, drone.io đi kèm với bản phân phối Git. Trong một số nghiên cứu, tôi chỉ có thể đưa ra rằng phiên bản cộng đồng GitLab không cho phép Jenkins được thêm vào, nhưng phiên bản doanh nghiệp GitLab thì có. Có sự khác biệt đáng kể nào khác không?

Đây là kinh nghiệm của tôi:

Trong công việc của mình, chúng tôi quản lý kho lưu trữ của mình với GitLab EE và chúng tôi có máy chủ Jenkins (1.6) đang chạy.

Trong cơ sở họ làm khá nhiều như nhau. Họ sẽ chạy một số tập lệnh trên hình ảnh máy chủ / Docker.

TL; DR;

• Jenkins dễ sử dụng / học hỏi hơn, nhưng nó có nguy cơ trở thành một địa ngục plugin
• Jenkins có GUI (cái này có thể được ưa thích nếu người khác có thể truy cập / duy trì)
• Tích hợp với GitLab ít hơn với GitLab CI
• Jenkins có thể được tách ra khỏi kho lưu trữ của bạn

Hầu hết các máy chủ CI là khá thẳng về phía trước ( concourse.ci ), gitlab-ci , vòng tròn-ci , Travis-ci , drone.io , gocd và những gì khác có bạn). Chúng cho phép bạn thực thi các tập lệnh shell / bat từ định nghĩa tệp YAML. Jenkins dễ cắm hơn nhiều, và đi kèm với giao diện người dùng. Điều này có thể là một lợi thế hoặc bất lợi, tùy thuộc vào nhu cầu của bạn.

Jenkins rất cấu hình vì tất cả các plugin có sẵn. Nhược điểm của việc này là máy chủ CI của bạn có thể trở thành một spaghetti của plugin.

Theo tôi, việc xâu chuỗi và sắp xếp các công việc trong Jenkins đơn giản hơn nhiều (vì UI) so với qua YAML (gọi các lệnh curl). Bên cạnh đó, Jenkins hỗ trợ các plugin sẽ cài đặt một số nhị phân nhất định khi chúng không có sẵn trên máy chủ của bạn (không biết về các plugin đó).

Ngày nay ( Jenkins 2 cũng hỗ trợ nhiều hơn "ci thích hợp" với Jenkinsfilevà pipline Plugin mà đi kèm mặc định, kể từ Jenkins 2), nhưng sử dụng được ít cùng với kho hơn tức là GitLab CI.

Sử dụng các tệp YAML để xác định đường ống xây dựng của bạn (và cuối cùng chạy shell / bat thuần) sẽ sạch hơn.

Các plugin có sẵn cho Jenkins cho phép bạn hình dung tất cả các loại báo cáo, chẳng hạn như kết quả kiểm tra, phạm vi bảo hiểm và các máy phân tích tĩnh khác. Tất nhiên, bạn luôn có thể viết hoặc sử dụng một công cụ để làm điều này cho bạn, nhưng nó chắc chắn là một điểm cộng cho Jenkins (đặc biệt đối với những người quản lý có xu hướng coi trọng các báo cáo này quá nhiều).

Gần đây tôi đã làm việc nhiều hơn với GitLab CI. Tại GitLab họ đang làm một công việc thực sự tuyệt vời làm cho toàn bộ trải nghiệm trở nên thú vị. Tôi hiểu rằng mọi người sử dụng Jenkins, nhưng khi bạn có GitLab đang chạy và có sẵn thì thực sự dễ dàng để bắt đầu với GitLab CI. Sẽ không có bất cứ thứ gì sẽ tích hợp hoàn hảo như GitLab CI, mặc dù họ đã nỗ lực khá nhiều trong việc tích hợp của bên thứ ba.

• Tài liệu của họ sẽ giúp bạn bắt đầu trong thời gian không.
• Ngưỡng để bắt đầu là rất thấp.
• Bảo trì dễ dàng (không có plugin).
• Runners quy mô là đơn giản.
• CI hoàn toàn là một phần của kho lưu trữ của bạn.
• Công việc / lượt xem của Jenkins có thể trở nên lộn xộn.

Một số đặc quyền tại thời điểm viết:

• Chỉ hỗ trợ cho một tệp duy nhất trong phiên bản cộng đồng. Nhiều tập tin trong phiên bản doanh nghiệp .

Tôi đồng ý với hầu hết các ghi chú của Rik, nhưng ý kiến ​​của tôi về việc đơn giản hơn thì ngược lại : GitLab đang chứng tỏ là một công cụ tuyệt vời để làm việc.

Hầu hết sức mạnh đến từ việc khép kín và tích hợp mọi thứ trong cùng một sản phẩm trong cùng một tab trình duyệt: từ trình duyệt kho lưu trữ, bảng phát hành hoặc lịch sử xây dựng đến các công cụ triển khai và giám sát .

Tôi đang sử dụng nó ngay bây giờ để tự động hóa và kiểm tra cách ứng dụng cài đặt trên các bản phân phối Linux khác nhau và nó rất nhanh để định cấu hình (thử mở cấu hình công việc Jenkins phức tạp trong Firefox và đợi tập lệnh không phản hồi xuất hiện so với Làm thế nào nhẹ để chỉnh sửa .gitlab-ci.yml).

Thời gian dành cho việc cấu hình / chia tỷ lệ nô lệ ít hơn đáng kể nhờ các tệp nhị phân của người chạy ; cộng với thực tế là trong GitLab.com bạn có được những người chạy chia sẻ khá tốt và miễn phí.

Jenkins cảm thấy thủ công hơn sau vài tuần là người sử dụng năng lượng của GitLab CI, ví dụ: sao chép công việc trên mỗi chi nhánh, cài đặt plugin để thực hiện các công việc đơn giản như tải lên SCP. Trường hợp sử dụng duy nhất tôi gặp phải khi tôi bỏ lỡ nó như ngày nay là khi có nhiều hơn một kho lưu trữ; cần phải được tìm ra độc đáo chưa.

BTW, tôi hiện đang viết một loạt bài về GitLab CI để chứng minh rằng không khó để cấu hình cơ sở hạ tầng CI lưu trữ của bạn với nó. Được xuất bản vào tuần trước, phần đầu tiên sẽ giới thiệu những điều cơ bản, ưu và nhược điểm và sự khác biệt với các công cụ khác: Tích hợp liên tục nhanh chóng và tự nhiên với GitLab CI

Trước hết, tính đến hôm nay, GitLab Community Edition có thể tương thích hoàn toàn với Jenkins. Không có câu hỏi.

Trong phần tiếp theo, tôi đưa ra một số phản hồi về trải nghiệm thành công khi kết hợp cả Jenkins và GitLab CI. Tôi cũng sẽ thảo luận về việc bạn nên sử dụng cả hai hoặc chỉ một trong số họ, và vì lý do gì.

Tôi hy vọng điều này sẽ cung cấp cho bạn thông tin chất lượng về các dự án của riêng bạn.

Điểm mạnh của GitLab CI và Jenkins

GitLab CI

GitLab CI được tích hợp tự nhiên trong GitLab SCM. Bạn có thể tạo đường ống bằng gitlab-ci.ymlcác tệp và thao tác chúng thông qua giao diện đồ họa.

Các đường ống dưới dạng mã rõ ràng có thể được lưu trữ trong cơ sở mã, thực thi thực hành "mọi thứ như mã" (truy cập, phiên bản, độ tái lập, khả năng sử dụng lại, v.v.).

GitLab CI là một công cụ quản lý hình ảnh tuyệt vời:

• tất cả các thành viên của các nhóm (bao gồm cả những người không có kỹ thuật) có quyền truy cập nhanh chóng và dễ dàng vào trạng thái vòng đời của ứng dụng.
• do đó, nó có thể được sử dụng như một bảng điều khiển tương tác và vận hành để quản lý phát hành.

Jenkins

Jenkins là một công cụ xây dựng tuyệt vời. Sức mạnh của nó nằm ở nhiều plugin. Đặc biệt, tôi đã rất may mắn khi sử dụng các plugin giao diện giữa Jenkins và các công cụ CI hoặc CD khác. Đây luôn là một lựa chọn tốt hơn là phát triển lại (có thể là xấu) giao diện hộp thoại giữa hai thành phần.

Đường ống dưới dạng mã cũng có sẵn bằng cách sử dụng groovycác tập lệnh.

Sử dụng GitLab CI và Jenkins cùng nhau

Thoạt nghe có vẻ hơi dư thừa, nhưng kết hợp GitLab CI và Jenkins khá mạnh mẽ.

• Các đường ống GitLab CI (chuỗi, chạy, giám sát ...) và người ta có thể hưởng lợi giao diện đồ họa của nó được tích hợp với GitLab
• Jenkins điều hành công việc và tạo điều kiện cho hộp thoại với các công cụ của bên thứ ba.

Một lợi ích khác của thiết kế này là có khớp nối lỏng lẻo giữa các công cụ:

• chúng tôi có thể thay thế bất kỳ thành phần nào của nhà máy xây dựng mà không phải làm lại toàn bộ quy trình CI / CD
• chúng ta có thể có một môi trường xây dựng không đồng nhất, kết hợp (có thể một vài) Jenkins, TeamCity, bạn đặt tên cho nó và vẫn có một công cụ giám sát duy nhất.

Sự đánh đổi

Tất nhiên, có một cái giá phải trả cho thiết kế này: thiết lập ban đầu rất cồng kềnh và bạn cần có mức độ hiểu biết tối thiểu về nhiều công cụ.

Vì lý do này, tôi không khuyên bạn nên thiết lập như vậy trừ khi

• bạn có nhiều công cụ của bên thứ ba để giải quyết. Đó là khi Jenkins trở nên siêu tiện dụng với nhiều plugin.
• bạn phải đối phó với các ứng dụng phức tạp với các công nghệ không đồng nhất, có mỗi môi trường xây dựng khác nhau và vẫn cần phải có giao diện người dùng quản lý vòng đời ứng dụng thống nhất.

Nếu bạn không ở trong cả hai tình huống này, có lẽ bạn tốt hơn chỉ với một trong hai, nhưng không phải cả hai.

Nếu tôi phải chọn một

Cả GitLab CI và Jenkins đều có ưu và nhược điểm. Cả hai đều là công cụ mạnh mẽ. Vậy nên chọn cái nào?

trả lời 1

Chọn một nhóm mà nhóm của bạn (hoặc ai đó thân thiết) đã có trình độ chuyên môn nhất định.

Trả lời 2

Nếu bạn hoàn toàn là sinh viên năm nhất về công nghệ CI, chỉ cần chọn một và bắt đầu.

• Nếu bạn đang sử dụng GitLab và có sở trường về mọi thứ dưới dạng mã, sẽ hoàn toàn hợp lý khi chọn GitLab CI.
• Nếu bạn phải đối thoại với nhiều công cụ CI / CD khác hoặc hoàn toàn cần GUI đó để xây dựng công việc của bạn, hãy tìm Jenkins.

Những người bạn đang sử dụng GitLab và không chắc họ sẽ tiếp tục làm như vậy vẫn phải ghi nhớ rằng, việc chọn GitLab CI sẽ ám chỉ rác tất cả các đường ống CI / CD của bạn.

Lời cuối cùng là: cán cân nghiêng một chút chút về phía Jenkins vì nhiều plugin của nó, nhưng rất có thể là GitLab CI sẽ nhanh chóng lấp đầy khoảng trống.

Tôi muốn thêm một số phát hiện từ thử nghiệm gần đây của tôi với GitLab CI. Các tính năng đi kèm với 11.6 và 11.7 thật tuyệt vời!

Cụ thể, tôi thích các onlyđiều kiện về cơ bản cho phép bạn xây dựng các đường ống riêng cho merge_requesthoặc push(danh sách đầy đủ có ở đây )

Ngoài ra, tôi thực sự thích sự vắng mặt của các plugin. Khi tôi cần một số chức năng phức tạp hơn, tôi chỉ cần viết một hình ảnh Docker tùy chỉnh xử lý các chức năng cần thiết (đó là khái niệm giống như bạn có thể thấy trong drone.io ).

Nếu bạn đang tự hỏi về DRY , ngày nay điều đó hoàn toàn có thể! Bạn có thể viết "mẫu" của bạn

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

Đặt chúng vào một số kho lưu trữ công cộng, bao gồm chúng trong đường ống chính:

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

Và sử dụng chúng để mở rộng một số công việc:

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

Tôi yêu GitLab CI rất nhiều! Vâng, nó (cho đến nay) không thể vẽ các biểu đồ đẹp với độ bao phủ và vân vân, nhưng nhìn chung nó là một công cụ thực sự gọn gàng!

Chỉnh sửa (2019-02-23): đây là bài viết của tôi về những điều tôi yêu thích trong GitLab CI. Nó được viết vào 11.7 "thời đại" nên khi bạn đọc câu trả lời này, GitLab CI có thể có nhiều tính năng hơn.

Chỉnh sửa (2019-07-10): Gitlab CI hiện hỗ trợ nhiều extendsví dụ:

extends:
 - .pieceA
 - .pieceB

Kiểm tra tài liệu chính thức để có thêm thông tin về nhiều phần mở rộng

nếu công việc xây dựng / xuất bản / triển khai và thử nghiệm của bạn không phức tạp lắm thì sử dụng gitlab ci có lợi thế tự nhiên.

Vì gitlab-ci.yml hiện diện cùng với mã của bạn ở mọi chi nhánh, bạn có thể sửa đổi các bước ci / cd của mình, đặc biệt là các thử nghiệm (khác nhau giữa các môi trường) hiệu quả hơn.

Ví dụ, bạn muốn thực hiện kiểm tra đơn vị cho bất kỳ chi nhánh đăng ký nào trong khi bạn muốn thực hiện kiểm tra chức năng đầy đủ trên nhánh QA và chỉ có thể thực hiện một loại thử nghiệm giới hạn trong sản xuất bằng cách sử dụng gitlab ci.

Ưu điểm thứ hai ngoài giao diện người dùng tuyệt vời là khả năng sử dụng hình ảnh docker để thực hiện bất kỳ giai đoạn nào giữ cho máy chủ lưu trữ nguyên vẹn và do đó ít bị lỗi hơn.

hơn nữa gitlab ci sẽ tự động đăng ký cho bạn và bạn không phải quản lý jenkins master riêng