GitLab CI - Jenkins [kapalı]

Jenkins ile GitLab CI gibi diğer CI'lar arasındaki fark nedir, drone.io Git dağıtımıyla birlikte geliyor. Bazı araştırmalarda, sadece GitLab topluluk sürümünün Jenkins'in eklenmesine izin vermediğini, ancak GitLab kurumsal sürümünün eklediğini bulabildim. Başka önemli farklılıklar var mı?

Bu benim deneyimim:

İşimde depolarımızı GitLab EE ile yönetiyoruz ve çalışan bir Jenkins sunucumuz (1.6) var.

Temelde hemen hemen aynı şeyi yapıyorlar. Bir sunucu / Docker görüntüsü üzerinde bazı betikleri çalıştıracaklar.

TL; DR;

• Jenkins'i kullanmak / öğrenmek daha kolaydır, ancak bir eklenti cehennemi olma riski vardır
• Jenkins'in bir GUI'si vardır (başkaları tarafından erişilebilir / bakımı yapılabilmesi gerekiyorsa bu tercih edilebilir)
• GitLab ile entegrasyon GitLab CI ile olduğundan daha azdır
• Jenkins, deponuzdan ayrılabilir

Çoğu CI sunucusu oldukça basittir ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd ve sizde başka neler var). YAML dosya tanımından kabuk / bat betikleri çalıştırmanıza izin verirler. Jenkins çok daha fazla takılabilir ve bir kullanıcı arayüzü ile birlikte gelir. Bu, ihtiyaçlarınıza bağlı olarak bir avantaj veya dezavantaj olabilir.

Jenkins, mevcut tüm eklentiler nedeniyle oldukça yapılandırılabilir. Bunun dezavantajı, CI sunucunuzun bir eklenti spagetti haline gelebilmesidir.

Benim düşünceme göre, Jenkins'teki işlerin zincirlenmesi ve düzenlenmesi YAML (curl komutlarını çağırmaktan) çok daha basittir (UI nedeniyle). Bunun yanı sıra, Jenkins sunucunuzda mevcut olmadığında belirli ikili dosyaları kuracak eklentileri de destekler (diğerleri için bunu bilmiyorum).

Günümüzde ( Jenkins 2 , Jenkins 2'den itibaren varsayılan olarak gelen Jenkinsfileve pipline eklentisi ile daha "uygun ci" yi de destekliyor ), ancak depoya örneğin GitLab CI'dan daha az bağlıydı.

Derleme ardışık düzeninizi tanımlamak için YAML dosyalarını kullanmak (ve sonunda saf kabuk / bat çalıştırmak) daha temizdir.

Jenkins için mevcut olan eklentiler, test sonuçları, kapsam ve diğer statik analizörler gibi her türlü raporlamayı görselleştirmenizi sağlar. Tabii ki, bunu sizin için yapmak için her zaman yazabilir veya bir araç kullanabilirsiniz, ancak bu kesinlikle Jenkins için bir artıdır (özellikle bu raporlara çok fazla değer verme eğiliminde olan yöneticiler için).

Son zamanlarda GitLab CI ile giderek daha fazla çalışıyorum. GitLab'da tüm deneyimi eğlenceli hale getiren gerçekten harika bir iş çıkarıyorlar. İnsanların Jenkins kullandığını anlıyorum, ancak GitLab çalışırken ve kullanılabilir olduğunda GitLab CI ile başlamak gerçekten çok kolay. Üçüncü taraf entegrasyonlarında epey çaba sarf etseler bile GitLab CI kadar sorunsuz entegre olacak hiçbir şey olmayacak.

• Onların belgeleri, hemen başlamanıza yardımcı olmalıdır.
• Başlama eşiği çok düşük.
• Bakımı kolaydır (eklenti yoktur).
• Koşucuları ölçeklemek basittir.
• CI tamamen deponuzun bir parçası.
• Jenkins işleri / görünümleri dağınık olabilir.

Yazarken bazı avantajlar:

• Topluluk sürümünde yalnızca tek bir dosya için destek. Kurumsal sürümde dosyaları çoğaltır .

Rik'ın notlarının çoğuna katılıyorum, ancak hangisinin daha basit olduğu konusundaki fikrim tam tersi : GitLab, çalışmak için harika bir araç olduğunu kanıtlıyor.

Gücün çoğu, bağımsız olmaktan ve aynı üründeki her şeyi aynı tarayıcı sekmesi altında entegre etmekten gelir : depo tarayıcısından, yayın panosundan veya derleme geçmişinden dağıtım araçlarına ve izlemeye kadar .

Şu anda bir uygulamanın farklı Linux dağıtımlarına nasıl yükleneceğini otomatikleştirmek ve test etmek için kullanıyorum ve yapılandırmak çok hızlı (Firefox'ta karmaşık bir Jenkins iş yapılandırması açmaya çalışın ve yanıt vermeyen komut dosyasının gelmesini bekleyin. . düzenleme ne kadar hafiftir .gitlab-ci.yml).

Koşucu ikili dosyaları sayesinde, slave'leri yapılandırmak / ölçeklendirmek için harcanan zaman önemli ölçüde daha azdır ; artı GitLab.com'da oldukça düzgün ve ücretsiz paylaşılan koşucular elde edersiniz.

Jenkins, birkaç hafta güçlü bir GitLab CI kullanıcısı olduktan sonra, örneğin şube başına işlerin kopyalanması, SCP yüklemesi gibi basit şeyler yapmak için eklentilerin yüklenmesi gibi daha manuel hissediyor . Bugün olduğu gibi özlediğim tek kullanım durumu, birden fazla deponun dahil olduğu zamandır; bunun henüz güzelce çözülmesi gerekiyor.

BTW, şu anda GitLab CI'da depo CI altyapınızı onunla yapılandırmanın ne kadar zor olmadığını göstermek için bir dizi yazıyorum. Geçen hafta yayınlanan ilk makale , temelleri, artıları ve eksileri ve diğer araçlarla olan farklılıkları tanıtıyor: GitLab CI ile Hızlı ve doğal Sürekli Entegrasyon

Öncelikle, bugün itibariyle GitLab Community Edition, Jenkins ile tamamen birlikte çalışabilir. Soru yok.

Aşağıda, hem Jenkins hem de GitLab CI'yı birleştiren başarılı bir deneyim hakkında bazı geri bildirimler vereceğim. Ayrıca ikisini birden mi yoksa yalnızca birini mi kullanmanız gerektiğini ve hangi nedenle kullanacağınızı tartışacağım.

Umarım bu size kendi projeleriniz hakkında kaliteli bilgi verir.

GitLab CI ve Jenkins güçlü yönleri

GitLab CI

GitLab CI doğal olarak GitLab SCM'ye entegre edilmiştir. gitlab-ci.ymlDosyaları kullanarak ardışık düzenler oluşturabilir ve bunları bir grafik arabirim aracılığıyla işleyebilirsiniz.

Kod olarak bu ardışık düzenler açıkça kod tabanında depolanabilir ve "her şeyi kod olarak" uygulamasını (erişim, sürüm oluşturma, yeniden üretilebilirlik, yeniden kullanılabilirlik vb.)

GitLab CI harika bir görsel yönetim aracıdır:

• Ekiplerin tüm üyeleri (teknik olmayanlar dahil) uygulamaların yaşam döngüsü durumuna hızlı ve kolay erişime sahiptir.
• bu nedenle sürüm yönetimi için etkileşimli ve operasyonel bir gösterge paneli olarak kullanılabilir .

Jenkins

Jenkins, harika bir inşa aracıdır. Gücü, birçok eklentisinde yatıyor. Özellikle, Jenkins ile diğer CI veya CD araçları arasında arayüz eklentilerini kullanma konusunda büyük şansım oldu. Bu, her zaman iki bileşen arasında bir iletişim arayüzü geliştirmekten (muhtemelen kötü bir şekilde) daha iyi bir seçenektir.

Kod olarak pipeline, groovykomut dosyaları kullanılarak da kullanılabilir .

GitLab CI ve Jenkins'i birlikte kullanma

İlk başta biraz gereksiz gelebilir, ancak GitLab CI ve Jenkins'i birleştirmek oldukça güçlüdür.

• GitLab CI, ardışık düzenleri (zincirler, çalıştırmalar, monitörler ...) düzenler ve biri GitLab'a entegre grafik arayüzünden yararlanabilir
• Jenkins işi çalıştırır ve üçüncü taraf araçlarla diyaloğu kolaylaştırır.

Bu tasarımın bir başka yararı da aletler arasında gevşek bağlantıya sahip olmasıdır:

• tüm CI / CD sürecini yeniden işlemek zorunda kalmadan fabrika bileşenlerinden herhangi birini değiştirebiliriz
• (muhtemelen birkaç tane) Jenkins, TeamCity'yi birleştiren heterojen bir yapı ortamına sahip olabiliriz, adını siz koyun ve yine de tek bir izleme aracına sahip olabiliriz.

Takas

Elbette, bu tasarım için ödenmesi gereken bir bedel var: ilk kurulum zahmetli ve birçok araç hakkında minimum düzeyde anlayışa sahip olmanız gerekiyor.

Bu nedenle, böyle bir kurulumu önermiyorum

• ilgilenmeniz gereken birçok üçüncü taraf aracınız var. İşte o zaman Jenkins birçok eklentisiyle çok kullanışlı oluyor.
• Her biri farklı bir yapı ortamına sahip olan, heterojen teknolojilere sahip karmaşık uygulamalarla uğraşmanız ve yine de birleşik bir uygulama yaşam döngüsü yönetimi kullanıcı arayüzüne sahip olmanız gerekir.

Bu durumların hiçbirinde değilseniz, muhtemelen ikisinden sadece biriyle daha iyi durumda olursunuz, ikisini birden değil.

Eğer birini seçmek zorunda olsaydım

Hem GitLab CI hem de Jenkins'in artıları ve eksileri vardır. Her ikisi de güçlü araçlardır. Peki hangisini seçmeli?

cevap 1

Ekibinizin (veya yakın birinin) belirli bir uzmanlık seviyesine sahip olduğu birini seçin.

Cevap 2

Hepiniz CI teknolojilerinde birinci sınıf öğrencisiyseniz, birini seçin ve başlayın.

• GitLab kullanıyorsanız ve kod olarak her şeyde ustalığa sahipseniz, GitLab CI'yı seçmek tamamen mantıklıdır.
• Diğer birçok CI / CD aracıyla iletişim kurmanız gerekiyorsa veya işlerinizi oluşturmak için o GUI'ye kesinlikle ihtiyacınız varsa, Jenkins'e gidin.

GitLab kullanan ve bunu yapmaya devam edeceklerinden emin olmayanlarınız, GitLab CI'yi seçmiş olmanın tüm CI / CD ardışık düzenlerinizi çöpe atmanız anlamına geleceğini akıllarında tutmalıdırlar.

Denge eğilir: Nihai kelimedir küçük olması nedeniyle birçok eklentileri Jenkins doğru biraz ama şansı GitLab CI hızla boşluğu dolduracaktır vardır.

GitLab CI ile yaptığım son deneyimin bazı bulgularını eklemek istiyorum. 11.6 ve 11.7 ile gelen özellikler tek kelimeyle harika!

Özellikle only, temelde merge_requestveya için ayrı ardışık düzenler oluşturmanıza izin veren koşulları seviyorum push(tam liste burada )

Ayrıca, eklentilerin olmamasını gerçekten seviyorum. Daha karmaşık bir işlevselliğe ihtiyacım olduğunda, gerekli işlevselliği işleyen özel bir Docker görüntüsü yazıyorum ( drone.io'da görebileceğiniz kavramın aynısı ).

DRY hakkında merak ediyorsanız , bugünlerde kesinlikle mümkün! "Şablonlarınızı" yazabilirsiniz,

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

Bunları bir kamu havuzuna koyun, ana boru hattına ekleyin:

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

Ve bazı işleri genişletmek için bunları kullanın:

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

GitLab CI'yi çok seviyorum! Evet, (şimdiye kadar) kapsama ve benzeri güzel grafikler çizemez, ancak genel olarak gerçekten düzgün bir araçtır!

Düzenleme (2019-02-23): İşte GitLab CI'da sevdiğim şeyler hakkındaki yazım. 11.7 "çağda" yazılmıştır, bu yüzden bu cevabı okurken GitLab CI muhtemelen daha birçok özelliğe sahiptir.

Düzenleme (2019-07-10): Gitlab CI artık birden fazla extendsörn.

extends:
 - .pieceA
 - .pieceB

Birden çok uzantı hakkında daha fazla bilgi almak için resmi belgelere bakın

derleme / yayınlama / dağıtma ve test işleriniz çok karmaşık değilse gitlab ci kullanmanın doğal avantajları vardır.

Her dalda kodunuzun yanında gitlab-ci.yml bulunduğundan, ci / cd adımlarınızı özellikle testlerinizi (ortamlar arasında farklılık gösteren) daha etkin bir şekilde değiştirebilirsiniz.

Örneğin, herhangi bir kontrol devresi için birim testi yapmak istersiniz, oysa QA şubesinde tam teşekküllü işlevsel testler yapmak isteyebilirsiniz ve üretimde yalnızca sınırlı bir alma türü testler gitlab ci kullanılarak kolayca gerçekleştirilebilir.

Harika kullanıcı arayüzünden ayrı ikinci avantaj, herhangi bir aşamayı yürütmek için docker görüntülerini kullanma yeteneğidir, ana bilgisayar çalıştırıcısını sağlam tutar ve dolayısıyla daha az hata eğilimi gösterir.

dahası gitlab ci sizin için otomatik olarak kontrol eder ve jenkins master'ı ayrı ayrı yönetmeniz gerekmez