GitLab CI vs. Jenkins [ditutup]

129

Apa perbedaan antara Jenkins dan CI lainnya seperti GitLab CI, drone.io datang dengan distribusi Git. Pada beberapa penelitian saya hanya bisa menemukan bahwa edisi komunitas GitLab tidak memungkinkan Jenkins untuk ditambahkan, tetapi edisi perusahaan GitLab melakukannya. Apakah ada perbedaan signifikan lainnya?

Ravikiran butti
sumber
5
GitLab juga sekarang telah membuat perbandingan GitLab CI vs Jenkins: about.gitlab.com/comparison/gitlab-vs-jenkins.html
bbodenmiller
2
Tautan baru adalah: about.gitlab.com/comparison/pdfs/gitlab-vs-jenkins.pdf
Guillaume Husta

Jawaban:

122

Ini pengalaman saya:

Di tempat kerja saya, kami mengelola repositori kami dengan GitLab EE dan kami memiliki server Jenkins (1.6) yang berjalan.

Pada dasarnya mereka melakukan hampir sama. Mereka akan menjalankan beberapa skrip pada gambar server / Docker.

TL; DR;

  • Jenkins lebih mudah digunakan / dipelajari, tetapi memiliki risiko menjadi plugin hell
  • Jenkins memiliki GUI (ini lebih disukai jika harus dapat diakses / dikelola oleh orang lain)
  • Integrasi dengan GitLab kurang dari dengan GitLab CI
  • Jenkins dapat memisahkan repositori Anda

Sebagian besar server CI cukup lurus ke depan ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd dan apa lagi yang Anda miliki). Mereka memungkinkan Anda untuk mengeksekusi skrip shell / bat dari definisi file YAML. Jenkins jauh lebih pluggable, dan dilengkapi dengan UI. Ini bisa menjadi keuntungan atau kerugian, tergantung pada kebutuhan Anda.

Jenkins sangat dapat dikonfigurasi karena semua plugin yang tersedia. Kelemahan dari ini adalah bahwa server CI Anda dapat menjadi spageti plugin.

Menurut pendapat saya chaining dan mengatur pekerjaan di Jenkins jauh lebih sederhana (karena UI) daripada melalui YAML (memanggil perintah curl). Selain itu Jenkins mendukung plugin yang akan menginstal binari tertentu ketika mereka tidak tersedia di server Anda (tidak tahu tentang itu untuk yang lain).

Saat ini ( Jenkins 2 juga mendukung lebih "ci tepat" dengan Jenkinsfiledan pipline Plugin yang datang default seperti dari Jenkins 2), tetapi digunakan untuk kurang digabungkan ke repositori dari yaitu GitLab CI.

Menggunakan file YAML untuk mendefinisikan pipa bangunan Anda (dan pada akhirnya menjalankan shell / bat murni) lebih bersih.

Plug-in yang tersedia untuk Jenkins memungkinkan Anda memvisualisasikan semua jenis pelaporan, seperti hasil pengujian, cakupan, dan analisis statis lainnya. Tentu saja, Anda selalu dapat menulis atau menggunakan alat untuk melakukan ini untuk Anda, tetapi jelas merupakan nilai tambah bagi Jenkins (terutama bagi manajer yang cenderung menilai laporan ini terlalu banyak).

Akhir-akhir ini saya semakin sering bekerja dengan GitLab CI. Di GitLab mereka melakukan pekerjaan yang benar-benar hebat yang membuat seluruh pengalaman menjadi menyenangkan. Saya mengerti bahwa orang menggunakan Jenkins, tetapi ketika Anda memiliki GitLab berjalan dan tersedia, sangat mudah untuk memulai dengan GitLab CI. Tidak akan ada apa pun yang akan diintegrasikan dengan mulus seperti GitLab CI, meskipun mereka melakukan beberapa upaya dalam integrasi pihak ketiga.

  • Dokumentasi mereka akan membantu Anda memulai dalam waktu singkat.
  • Ambang untuk memulai sangat rendah.
  • Perawatannya mudah (tidak ada plugin).
  • Pelari penskalaan sederhana.
  • CI sepenuhnya bagian dari repositori Anda.
  • Pekerjaan / tampilan Jenkins bisa berantakan.

Beberapa tunjangan pada saat penulisan:

  • Hanya mendukung satu file dalam edisi komunitas. Melipatgandakan file dalam edisi perusahaan .
Rik
sumber
13
Jenkins sekarang bisa mendapatkan GUI yang lebih baik berkat Blue Ocean
Ayoub Kaanich
3
Seperti dari gitlab 9.3 dukungan pipa multi-proyek ditambahkan. Bagi saya ini adalah salah satu alasan utama untuk tetap berpegang pada Jenkins. Saat ini saya sedang melakukan PoC untuk memeriksa apakah saya dapat mengelola dengan gitlab, karena mereka jelas juga memfokuskan hal ini sekarang dan mereka berkembang lebih cepat. Selain itu saya sangat menyukai UI dan bagaimana ia berkembang seiring waktu.
Rik
4
Yang terbaik dengan file yaml adalah, bahwa Anda mendokumentasikan perubahan Anda ke pipa langsung di tempat seharusnya .. di repositori sebagai bagian dari kode sumber. Jadi Anda dapat memiliki cabang dengan file yaml yang berbeda untuk cabang rilis yang berbeda. Tentu, penggabungan yaml bisa berantakan :) Pencitraan menggabungkan dua jalur pipa di jenkins, itu adalah pekerjaan yang jauh lebih sulit.
Christian Müller
jenkins menyediakan lebih banyak alat daripada gitlab ci. gitlab / jenkins Integrasi bersama dimungkinkan dan benar-benar transparan bagi pengguna jika diselesaikan dengan baik. Membuat dua jalur pipa dalam jenkins mudah dilakukan dengan Jenkinsfile di repositori Anda .... Anda membutuhkan plugins cabang gitlab dan gitlab
sancelot
1
Yang dimaksud dengan "Hanya mendukung satu file dalam edisi komunitas. Mengalikan file dalam edisi perusahaan." ? Maaf saya mencoba membaca masalah terlampir tetapi tidak bisa mengaitkan.
Lester
62

Saya setuju dengan sebagian besar catatan Rik, tetapi pendapat saya tentang yang lebih sederhana adalah kebalikannya : GitLab terbukti menjadi alat yang luar biasa untuk bekerja dengannya.

Sebagian besar daya berasal dari menjadi mandiri dan mengintegrasikan segala sesuatu dalam produk yang sama di bawah tab browser yang sama: dari browser repositori, papan masalah atau membangun sejarah hingga alat penyebaran dan pemantauan .

Saya menggunakannya sekarang untuk mengotomatisasi dan menguji bagaimana suatu aplikasi menginstal pada distribusi Linux yang berbeda, dan itu hanya sangat cepat untuk mengkonfigurasi (mencoba untuk membuka konfigurasi pekerjaan Jenkins yang kompleks di Firefox dan menunggu skrip non-responsif muncul vs seberapa ringan untuk mengedit .gitlab-ci.yml).

Waktu yang dihabiskan untuk mengonfigurasi / menskalakan budak jauh lebih sedikit berkat binari pelari ; ditambah fakta bahwa di GitLab.com Anda mendapatkan pelari bersama yang cukup baik dan gratis.

Jenkins merasa lebih manual setelah beberapa minggu menjadi pengguna kuat GitLab CI, misalnya menduplikasi pekerjaan per cabang, memasang plugin untuk melakukan hal-hal sederhana seperti mengunggah SCP. Satu-satunya use case yang saya hadapi di mana saya melewatkannya seperti hari ini adalah ketika lebih dari satu repositori terlibat; yang perlu dipecahkan dengan baik.

BTW, saya saat ini sedang menulis seri pada GitLab CI untuk menunjukkan bagaimana tidak sulit untuk mengkonfigurasi infrastruktur CI repositori Anda dengannya. Diterbitkan minggu lalu, karya pertama memperkenalkan dasar-dasar, pro dan kontra dan perbedaan dengan alat-alat lain: Integrasi Berkelanjutan yang cepat dan alami dengan GitLab CI

Alfageme
sumber
5
Saya sangat setuju dengan Anda tentang Gitlab. Pada saat penulisan gitlab tidak selengkap seperti saat ini. Saya sangat suka Gitlab sebagai alat, dan sangat menghargai semua pekerjaan yang dilakukan orang-orang.
Rik
1
@alfageme: Bagaimanapun, saya akan memeriksa Laporan Anda di situs yang disebutkan: Terima kasih atas semua penjelasan Anda. Pada saat ini saya akan memutuskan apakah kami menggunakan gitlabCI atau Jenkins untuk CI -Stuff kami.
Max Schindler
3
@Rik saya suka Gitlab CI namun saya mendengar argumen dari pihak lain mengatakan sulit untuk mempertahankan file yaml karena tidak ada penggunaan kembali karena banyak file yaml dalam pipa mengikuti struktur yang sama dan Templating tidak dipandang sebagai pilihan yang unggul untuk jenkinsfile karena jenkinsfile menggunakan asyik. jadi ini semua tentang konfigurasi kode vs untuk dapat digunakan kembali. dapatkah Anda membagikan pemikiran Anda tentang ini?
user1870400
1
@ user1870400 Saya tidak sepenuhnya yakin apa yang Anda maksud dengan templating. Karena sejauh yang saya bisa melihatnya, itu hanya file di repositori Anda. Dan itu tidak berbeda dibandingkan dengan Anda Jenkinsfile. Anda benar bahwa di Anda JenkinsfileAnda memiliki groovy (+ lib java tambahan) yang tersedia untuk menjalankan kode, di mana .gitlab-ci.yamlfile tersebut terutama akan mendukung shell, tetapi (tergantung pada lokasi pelari). Di sisi lain Anda dapat memanggil semua ini dari skrip shell juga, tetapi downside adalah bahwa Anda membuat dependensi mesin (yang menurut saya tidak terlalu transparan).
Rik
1
@Alfageme - Saya mulai menggunakan Gitlab CI juga dan menjauh dari Jenkins. Saya menggunakannya pada saat itu untuk membangun otomatis, mengunggah ke Nexus, menggunakan DEV env dan menjalankan tes unit. Urutan tersebut dijalankan pada tingkat proyek (standar). Setelah DEV saya juga perlu mengatur penyebaran multi-proyek (Gitlab group). Saya membuat GUI yang menggunakan Gitlab, API Nexus, dll. Di mana Anda memilih TAG proyek terbaru untuk diterapkan dan grup-proyek tag terbaru dikerahkan juga (naif). Saya bekerja pada ekstensi untuk mendukung definisi versi matriks (projec1v1.1 kompatibel dengan project2v3.2), saya akan meminta satu fitur permintaan di gitlab untuk ini.
kensai
22

Pertama-tama, pada hari ini, Edisi Komunitas GitLab dapat sepenuhnya dioperasikan dengan Jenkins. Tidak ada pertanyaan.

Berikut ini, saya memberikan umpan balik tentang pengalaman sukses menggabungkan Jenkins dan GitLab CI. Saya juga akan membahas apakah Anda harus menggunakan keduanya atau hanya salah satunya, dan untuk alasan apa.

Saya harap ini akan memberi Anda informasi berkualitas tentang proyek Anda sendiri.

Kekuatan GitLab CI dan Jenkins

GitLab CI

GitLab CI secara alami terintegrasi dalam GitLab SCM. Anda dapat membuat saluran pipa menggunakan gitlab-ci.ymlfile dan memanipulasinya melalui antarmuka grafis.

Pipa-pipa ini sebagai kode jelas dapat disimpan dalam basis kode, menegakkan praktik "semuanya sebagai kode" (akses, versi, reproduksibilitas, penggunaan kembali, dll.).

GitLab CI adalah alat manajemen visual yang hebat:

  • semua anggota tim (termasuk yang non-teknis) memiliki akses cepat dan mudah ke status siklus hidup aplikasi.
  • oleh karena itu dapat digunakan sebagai dashboard interaktif dan operasional untuk manajemen rilis.

Jenkins

Jenkins adalah alat membangun yang bagus. Kekuatannya ada di banyak pluginnya. Terutama, saya sangat beruntung menggunakan plugin antarmuka antara Jenkins dan alat CI atau CD lainnya. Ini selalu merupakan pilihan yang lebih baik daripada membangun kembali (mungkin buruk) antarmuka dialog antara dua komponen.

Pipeline sebagai kode juga tersedia menggunakan groovyskrip.

Menggunakan GitLab CI dan Jenkins bersama-sama

Mungkin terdengar agak berlebihan pada awalnya, tetapi menggabungkan GitLab CI dan Jenkins cukup kuat.

  • GitLab CI mengatur jaringan pipa, rantai, monitor ... dan kita dapat memanfaatkan antarmuka grafisnya yang terintegrasi dengan GitLab.
  • Jenkins menjalankan pekerjaan dan memfasilitasi dialog dengan alat pihak ketiga.

Manfaat lain dari desain ini adalah memiliki kopling longgar di antara alat-alat:

  • kita bisa mengganti komponen pabrik apa pun tanpa harus mengerjakan ulang seluruh proses CI / CD
  • kita bisa memiliki lingkungan yang heterogen, menggabungkan (mungkin beberapa) Jenkins, TeamCity, apa saja, dan masih memiliki satu alat pemantauan.

Trade-off

Yah, tentu saja, ada harga yang harus dibayar untuk desain ini: pengaturan awal rumit dan Anda harus memiliki tingkat minimal pemahaman banyak alat.

Untuk alasan ini, saya tidak merekomendasikan pengaturan seperti itu kecuali

  • Anda memiliki banyak alat pihak ketiga untuk ditangani. Saat itulah Jenkins sangat berguna dengan banyak pluginnya.
  • Anda harus berurusan dengan aplikasi kompleks dengan teknologi heterogen, memiliki masing-masing lingkungan yang berbeda, dan masih perlu memiliki UI manajemen siklus hidup aplikasi terpadu.

Jika Anda tidak berada dalam kedua situasi ini, Anda mungkin lebih baik hanya dengan satu dari keduanya, tetapi tidak keduanya.

Jika saya harus memilih satu

Baik GitLab CI dan Jenkins memiliki pro dan kontra. Keduanya adalah alat yang ampuh. Jadi yang mana yang harus dipilih?

jawaban 1

Pilih salah satu yang tim Anda (atau seseorang yang dekat) sudah memiliki tingkat keahlian tertentu.

Jawaban 2

Jika Anda semua mahasiswa baru dalam teknologi CI, pilih satu dan mulai saja.

  • Jika Anda menggunakan GitLab dan memiliki keahlian untuk semuanya sebagai kode, masuk akal untuk memilih GitLab CI.
  • Jika Anda harus berdialog dengan banyak alat CI / CD lainnya atau benar-benar membutuhkan GUI untuk membangun pekerjaan Anda, pilih Jenkins.

Anda yang menggunakan GitLab dan tidak yakin mereka akan tetap melakukannya, harus diingat bahwa, dengan memilih GitLab CI akan menyiratkan untuk membuang semua saluran pipa CI / CD Anda.

Kata terakhirnya adalah: keseimbangan sedikit condong ke arah Jenkins karena banyak pluginnya, tetapi kemungkinan GitLab CI akan dengan cepat mengisi kekosongan tersebut.

avi.elkharrat
sumber
@Peter Mortensen: THX!
avi.elkharrat
6

Saya ingin menambahkan beberapa temuan dari percobaan saya baru-baru ini dengan GitLab CI. Fitur yang datang dengan 11.6 dan 11.7 sungguh luar biasa!

Secara khusus saya suka onlykondisi yang pada dasarnya memungkinkan Anda membangun saluran pipa terpisah untuk merge_requestatau push(daftar lengkapnya ada di sini )

Juga, saya sangat suka tidak adanya plugin. Ketika saya membutuhkan beberapa fungsionalitas yang lebih kompleks, saya hanya menulis gambar Docker khusus yang menangani fungsionalitas yang diperlukan (itu konsep yang sama seperti yang Anda lihat di drone.io ).

Jika Anda bertanya-tanya tentang KERING , itu benar-benar mungkin saat ini! Anda dapat menulis "templat,"

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

Masukkan mereka ke beberapa repositori publik, sertakan dalam saluran pipa utama:

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

Dan gunakan untuk memperpanjang pekerjaan:

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

Saya sangat menyukai GitLab CI! Ya, itu (sejauh ini) tidak dapat menggambar grafik yang bagus dengan cakupan dan sebagainya, tetapi secara keseluruhan itu adalah alat yang sangat rapi!

Sunting (2019-02-23): inilah posting saya tentang hal - hal yang saya sukai di GitLab CI. Itu ditulis dalam 11,7 "era" sehingga ketika Anda membaca jawaban ini, GitLab CI mungkin memiliki lebih banyak fitur.

Sunting (2019-07-10): Gitlab CI sekarang mendukung banyak extendsmis

extends:
 - .pieceA
 - .pieceB

Periksa dokumentasi resmi untuk mendapatkan info lebih lanjut tentang beberapa ekstensi

Stepan Vrany
sumber
0

jika build / publish / deploy dan pekerjaan pengujian Anda tidak terlalu rumit maka menggunakan gitlab ci memiliki keuntungan alami.

Karena gitlab-ci.yml ada di samping kode Anda di setiap cabang, Anda dapat memodifikasi langkah-langkah ci / cd Anda terutama tes (yang berbeda di seluruh lingkungan) lebih efektif.

Sebagai contoh, Anda ingin melakukan pengujian unit untuk setiap checkin ke cabang dev sedangkan Anda mungkin ingin melakukan pengujian fungsional lengkap pada cabang QA dan terbatas hanya mendapatkan jenis tes pada produksi ini dapat dicapai dengan mudah menggunakan gitlab ci.

Keuntungan kedua selain UI yang hebat adalah kemampuannya untuk menggunakan gambar buruh pelabuhan untuk menjalankan setiap tahap menjaga host runner tetap utuh dan dengan demikian lebih sedikit kesalahan.

apalagi gitlab ci akan secara otomatis checkin untuk Anda dan Anda tidak perlu mengelola master jenkins secara terpisah

Rajanikant Patel
sumber