GitLab CI/CD ve Jenkins: Bütünleşik Platform mu, Esnek Otomasyon Sunucusu mu?

Temel fark: Platformun parçası mı, bağımsız sunucu mu?

GitLab CI/CD, GitLab platformunun içine yerleşik sürekli entegrasyon ve sürekli teslimat özelliğidir. Kod deposu, birleştirme istekleri (merge request), konteyner kayıt deposu, ortamlar ve dağıtım geçmişi aynı arayüzde yaşar. Pipeline tanımı deponun kökündeki .gitlab-ci.yml dosyasında YAML olarak yazılır ve işleri runner adı verilen yürütücüler çalıştırır.

Jenkins ise açık kaynaklı, bağımsız bir otomasyon sunucusudur. Herhangi bir kaynak kod sistemiyle (GitLab, GitHub, Bitbucket ya da kurum içi Git sunucusu) çalışabilir. Pipeline'lar depodaki Jenkinsfile dosyasında Groovy tabanlı bir dille tanımlanır; işleri bir denetleyici (controller) dağıtır, ajanlar (agent) çalıştırır. Jenkins'in yetenekleri büyük ölçüde eklentilerle şekillenir.

Bu mimari fark, seçimin özünü belirler: GitLab CI/CD "her şey bir arada" yaklaşımıyla kurulum ve entegrasyon yükünü azaltır; Jenkins ise neredeyse her ortama uyarlanabilen esnekliği, bakım ve yönetişim sorumluluğu karşılığında sunar.

Ortak zemin

• Pipeline as code: Her ikisinde de pipeline tanımı kodla birlikte depoda tutulur, sürümlenir ve kod incelemesinden geçer.
• Aşamalar ve paralellik: Derleme, test, güvenlik taraması ve dağıtım aşamaları tanımlanabilir; bağımsız işler paralel çalıştırılabilir.
• Dağıtık yürütme: GitLab'da runner, Jenkins'te agent yapısıyla işler farklı makinelerde, konteynerlerde ya da Kubernetes üzerinde çalıştırılabilir.
• Kendi sunucunuzda barındırma: GitLab kendi kurulumunuzda (self-managed) da çalışır; Jenkins zaten kurum içinde barındırılarak kullanılır.
• Onay ve ortam yönetimi: Üretim dağıtımından önce elle onay adımı, ortam bazlı değişkenler ve gizli bilgi yönetimi kurulabilir.

Bu nedenle teknik olarak bir araçta yapılabilen pipeline'ın büyük bölümü diğerinde de kurulabilir. Asıl fark, bunun ne kadar emekle kurulduğu ve uzun vadede kimin bakımını yaptığıdır.

Ölçüt ölçüt GitLab CI/CD ve Jenkins

• Kurulum: GitLab CI/CD / GitLab kullanılıyorsa hazırdır, yalnız runner kaydı gerekir. Jenkins / sunucu kurulumu, eklenti seçimi, güvenlik yapılandırması ve ajan bağlantısı gerekir.
• Tanım dili: GitLab CI/CD / bildirime dayalı YAML; include, şablon ve bileşenlerle yeniden kullanım. Jenkins / bildirimsel (declarative) ya da betik (scripted) pipeline sözdizimi, Groovy ile genişletme.
• Yeniden kullanım: GitLab CI/CD / include edilen ortak YAML dosyaları, şablonlar ve CI/CD bileşenleri. Jenkins / paylaşılan kütüphaneler (shared libraries).
• Kaynak kod entegrasyonu: GitLab CI/CD / GitLab deposuyla doğal; birleştirme isteği pipeline'ları ve sonuçlar aynı ekranda. Jenkins / eklentiler ve webhook'larla her Git sağlayıcısına bağlanır.
• Genişletilebilirlik: GitLab CI/CD / platformun sunduğu özelliklerle sınırlı ama tutarlı. Jenkins / geniş eklenti ekosistemi, neredeyse her araçla entegrasyon.
• Bakım yükü: GitLab CI/CD / GitLab.com'da altyapı sağlayıcıda, kendi kurulumda platform güncellemesiyle birlikte. Jenkins / sunucu, Java sürümü, eklenti uyumluluğu ve güvenlik güncellemeleri ekibin sorumluluğunda.
• Görünürlük: GitLab CI/CD / kod, inceleme, pipeline ve dağıtım geçmişi tek yerde. Jenkins / derleme geçmişi Jenkins'te, kod ve inceleme ayrı sistemde.

Hangi durumda hangisi?

GitLab CI/CD şu durumlarda öne çıkar: • Kod zaten GitLab'da tutuluyor ya da GitLab'a taşınması planlanıyor. • Ekip, CI/CD sunucusunu ayrıca işletmek için kaynak ayırmak istemiyor. • Geliştiricilerin pipeline'ı kendi depolarında yönetmesi, sonuçları birleştirme isteği üzerinde görmesi isteniyor. • Güvenlik taramaları ve ortam yönetimi tek platformda toplanmak isteniyor.

Jenkins şu durumlarda öne çıkar: • Kurumda birden fazla kaynak kod sistemi, ana bilgisayar, eski derleme araçları ya da özel donanım gibi heterojen bir ortam var. • Pipeline'larda karmaşık koşullar, özel entegrasyonlar ve standart araçların karşılamadığı adımlar bulunuyor. • Yıllar içinde biriken Jenkins işleri, paylaşılan kütüphaneler ve ekip bilgisi mevcut ve iyi çalışıyor. • Ağdan yalıtılmış ortamlarda, tam denetim altındaki bir otomasyon sunucusu gerekiyor.

Örneğin yeni kurulan bir ürün ekibi kodunu GitLab'da tutuyorsa, Jenkins kurmak yerine .gitlab-ci.yml ile başlamak hız kazandırır. Buna karşılık gömülü yazılım derlemesi için özel donanıma bağlı ajanları olan bir üretim şirketi, mevcut Jenkins altyapısını korumayı tercih edebilir.

Jenkins'ten GitLab CI/CD'ye geçişte dikkat edilecekler

Geçiş kararının arkasında genellikle bakım yükünü azaltma isteği vardır. Sağlıklı bir geçiş şu sırayı izler: • Envanter: Hangi Jenkins işleri gerçekten kullanılıyor, hangi eklentilere bağımlı ve kim sahibi? • Eşleme: Jenkins aşamaları GitLab'da stage ve job yapısına, paylaşılan kütüphaneler include edilen şablonlara ve bileşenlere, kimlik bilgileri GitLab CI/CD değişkenlerine dönüştürülür. • Runner tasarımı: Jenkins ajanlarının karşıladığı özel ihtiyaçlar (donanım, ağ erişimi, araç kurulumu) için uygun runner ve executor seçilir. • Pilot: Az bağımlılığı olan bir proje önce taşınır; süreler, hata oranları ve geliştirici deneyimi karşılaştırılır. • Paralel çalıştırma: Kritik pipeline'lar bir süre eski ve yeni sistemde birlikte çalıştırılarak çıktılar doğrulanır.

En sık yapılan hata, Groovy ile yazılmış karmaşık mantığı satır satır YAML'a çevirmeye çalışmaktır. Bunun yerine pipeline'ın amacını yeniden tasarlamak, daha sade ve okunur bir sonuç verir.

Seçimden bağımsız iyi pratikler

• Pipeline tanımını kodla birlikte tutun; arayüzden elle yapılandırılmış işler bilgi kaybına yol açar.
• Gizli bilgileri pipeline dosyasına yazmayın; maskeli değişkenler ya da harici bir sır yönetimi aracı kullanın.
• Hızlı geri bildirim için testleri katmanlara ayırın: hızlı birim testleri önce, uzun entegrasyon testleri sonra.
• Önbellek ve konteyner imajlarını bilinçli kullanın; her işte bağımlılıkları sıfırdan indirmek pipeline'ı yavaşlatır.
• Kalite kapıları tanımlayın: test kapsamı, statik analiz ve güvenlik taraması sonuçları belirli bir eşiği geçmeden birleştirmeye izin vermeyin.
• Jenkins kullanıyorsanız eklenti sayısını sınırlayın ve sunucu yapılandırmasını kodla yönetin; GitLab kullanıyorsanız ortak şablonları merkezi bir depoda sürümleyin.

Mindset programlarında bu araçları nerede çalışırsınız?

CI/CD Pipeline Tasarımı (GitLab) eğitimi GitLab CI/CD mimarisi ve temelleriyle başlar; gelişmiş pipeline tasarımı, runner yönetimi ve optimizasyon, test ve kalite kapıları, GitLab güvenlik tarama araçları, dağıtım ve ortam yönetimi ile GitOps konularını işler.

CI/CD Pipeline Tasarımı (Jenkins) eğitimi Jenkins mimarisi ve kurulum, bildirimsel pipeline yazımı, derleme, test ve kalite kapıları, paralellik ve performans, dağıtım ve güvenlik ile paylaşılan kütüphaneler modüllerini içerir. Jenkins'i kurum ölçeğinde işletecek ekipler için Jenkins ile Kurumsal CI/CD Platform İşletimi eğitimi ajan mimarisi ve ölçekleme, yapılandırma yönetimi, gözlemlenebilirlik ve yedekleme ile yükseltme planına odaklanır.