Adım Adım CI/CD Pipeline Kurma Yöntemi

CI/CD pipeline ne işe yarar?

Bir pipeline, kod değişikliğinin geliştiricinin bilgisayarından canlı ortama kadar giden yolunu otomatik ve tekrarlanabilir hale getiren iş akışıdır. Sürekli entegrasyon (CI) tarafı, her değişiklik ortak koda katıldığında yazılımın derlenmesini ve testlerin çalışmasını sağlar. Sürekli teslimat ya da dağıtım (CD) tarafı ise doğrulanmış sürümün bir ortama paketlenip çıkarılmasını üstlenir.

Pipeline kurmanın gerçek değeri hız kadar öngörülebilirliktir. Elle yapılan bir yayın, o işi bilen kişinin hafızasına ve o günkü dikkatine bağlıdır. Otomatik akışta ise aynı adımlar her seferinde aynı sırayla ve aynı kontrollerle koşar. Hata çıktığında da hangi aşamada, hangi değişiklikle çıktığı kayıtlı olur.

CI ile CD arasındaki sınırı net tutmak gerekir. CI, kodun birleştirilebilir olup olmadığını söyler. CD, birleşmiş kodun kullanıcıya ulaşmasını yönetir. Bazı ekipler dağıtımda son onayı insana bırakır, bazıları onay beklemeden yayınlar. Bu karar teknik olduğu kadar iş riski kararıdır.

Kurmadan önce: mevcut yayın akışını çıkarın

Pipeline kurmaya araç seçerek başlamayın. Önce bugün kodun canlıya nasıl çıktığını kâğıda dökün. Kim derliyor, testleri kim çalıştırıyor, hangi sunucuya hangi komutla çıkılıyor, geri dönüş nasıl yapılıyor? Bu harita, otomasyona dönüştürülecek adımların listesidir.

Haritayı çıkarırken şu soruları sorun: • Derleme bir makineden bağımsız tekrar edilebiliyor mu, yoksa belirli bir bilgisayardaki kuruluma mı bağlı? • Testler hangi sıklıkla çalışıyor ve ne kadar güveniliyor? • Ortamlar (geliştirme, test, canlı) arasındaki farklar belgelenmiş mi? • Bir yayın başarısız olursa önceki sürüme dönmenin yolu belli mi?

Cevaplardan biri "bilmiyoruz" ise önce o boşluğu kapatın. Otomasyon, bozuk bir süreci hızlandırır; düzeltmez.

Aşama aşama pipeline nasıl kurulur?

En sade ve işe yarar akış şu sırayı izler. Her aşama bir öncekinin başarılı olmasına bağlıdır ve ilk hata akışı durdurur.

• Tetikleme: Ortak dala gönderilen her değişiklik ve her birleştirme isteği pipeline'ı başlatır. Hangi olayın hangi akışı tetikleyeceğini baştan belirleyin; örneğin birleştirme isteğinde yalnız doğrulama, ana dalda ise paketleme ve dağıtım koşsun.
• Bağımlılıkların hazırlanması: Gerekli kütüphaneler temiz bir ortamda indirilir. Sık kullanılan bağımlılıkları önbelleğe almak süreyi belirgin biçimde kısaltır.
• Derleme: Kod, geliştirici makinesinden bağımsız, temiz bir ortamda derlenir. Burada çıkan hata genellikle "bende çalışıyordu" sorununun kaynağını gösterir.
• Hızlı testler: Birim testleri ve statik kod denetimleri önce koşar. Yavaş testlere geçmeden hızlı geri bildirim vermek geliştiricinin bekleme süresini düşürür.
• Paketleme: Derleme çıktısı sürüm etiketli bir pakete ya da konteyner imajına dönüştürülür. Aynı paket tüm ortamlara gider; ortam başına yeniden derleme yapılmaz.
• Dağıtım: Paket önce test ortamına, sonra gerekiyorsa onay sonrası canlıya çıkar.
• Doğrulama: Dağıtım sonrası basit bir sağlık denetimi, hizmetin gerçekten ayağa kalktığını teyit eder.

Bu iskeleti ilk gün tam kurmak zorunda değilsiniz. Yalnız derleme ve birim testiyle başlayıp aşamaları sırayla eklemek hem daha güvenli hem daha öğreticidir.

Test ve kalite kapıları nasıl konumlandırılır?

Kalite kapısı, belirli bir ölçütü sağlamayan değişikliğin ilerlemesini durduran kuraldır. Örneğin testler geçmeden birleştirme yapılamaması, kod denetimi uyarılarının eşik üstüne çıkması halinde akışın kırılması birer kapıdır.

Kapıları test piramidine göre dizin. Hızlı ve çok sayıdaki birim testleri akışın başında, daha yavaş entegrasyon testleri ortada, tam kullanıcı akışını deneyen uçtan uca testler ise dağıtım sonrası test ortamında koşar. Her şeyi baştan koşturmak pipeline'ı yavaşlatır ve ekibi "kırmızıyı görmezden gelme" alışkanlığına iter.

Güvenilmeyen test, pipeline'ın en büyük düşmanıdır. Bazen geçip bazen kalan testleri (kararsız testler) hemen etiketleyin ve izole edin. Aksi halde ekip kırmızı sonucu "yine o test" diye geçiştirmeye başlar ve gerçek hata bu gürültüde kaybolur.

Ortamlar, dağıtım stratejisi ve geri dönüş

Ortam sayısı arttıkça risk azalır ama bakım yükü artar. Çoğu ekip için geliştirme, test ve canlı ortam yeterli bir başlangıçtır. Önemli olan ortamların birbirine mümkün olduğunca benzemesidir; yapılandırma farkları kodla değil ortam değişkenleriyle yönetilmelidir.

Dağıtım biçimini riskinize göre seçin: • Doğrudan değiştirme: En basit yöntemdir, kısa kesinti kabul edilebilen sistemlerde uygundur. • Mavi-yeşil: Yeni sürüm yan ortamda hazırlanır, trafik bir hamlede çevrilir; sorun çıkarsa eski ortama dönmek kolaydır. • Kademeli (canary): Yeni sürüm önce küçük bir kullanıcı grubuna açılır, metrikler sağlıklıysa genişletilir.

Geri dönüşü pipeline'ın içine yerleştirin. "Önceki sürüme dön" komutu elle hatırlanan bir şey değil, bir tuşla ya da otomatik koşan bir adım olmalıdır. Canlıya çıkıştan önce geri dönüşün çalıştığını bir kez prova edin.

Gizli bilgiler ve güvenlik

Parola, erişim anahtarı ve belirteçler kodun içinde ya da pipeline dosyasında açık yazılmaz. Platformların sunduğu gizli değişken (secret) mekanizması kullanılır; bu değerler günlüklerde maskelenir ve yalnız yetkili akışlara verilir.

Güvenlik denetimlerini sona bırakmayın, akışın içine yerleştirin. Bağımlılıklardaki bilinen açıkları tarayan araçlar, kodda sızmış gizli bilgileri arayan taramalar ve konteyner imajı denetimleri tipik adımlardır. Canlıya dağıtım yapan kimliğe yalnız gereken yetkiyi verin; her işi yapabilen bir hesap, ele geçirildiğinde en büyük zarar kapısıdır.

Birleştirme isteklerinden gelen akışlarda dikkatli olun. Dışarıdan gelen kodun gizli değişkenlere erişmesi, pipeline üzerinden bilgi sızdırma yoludur. Gizli bilgilerin yalnız güvenilir dallarda kullanılabilmesini sağlayın.

Sık yapılan hatalar

• Her şeyi dev bir akışa koymak. Aşamaları ayırın; hata olduğunda nerede olduğu görünsün.
• Ortam başına yeniden derleme yapmak. Test edilen paket ile canlıya çıkan paket aynı olmalıdır.
• Pipeline'ı yalnız bir kişinin anlaması. Akış tanımı kodla birlikte sürüm kontrolünde durmalı ve ekip tarafından okunabilir olmalıdır.
• Süreyi izlememek. Yavaşlayan pipeline önce sabrı, sonra disiplini aşındırır. Önbellek kullanın, bağımsız işleri paralel çalıştırın.
• Başarısızlığı sessiz bırakmak. Kırık akış doğru kişiye, doğru kanaldan haber vermelidir.
• Kırık pipeline'ı bekletmek. Kırmızı durum bir önceliktir; ekip alışırsa pipeline güvenilirliğini kaybeder.

Pipeline bir kez kurulup bırakılan bir iş değildir. Süre, başarısızlık oranı ve geri dönüş sıklığı gibi göstergeleri izleyip akışı düzenli iyileştirin.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Mindset kataloğunda bu konunun farklı platformlar üzerinden işlendiği programlar var. CI/CD Pipeline Tasarımı (GitHub Actions) programının modül başlıkları arasında GitHub Actions temelleri, sürekli entegrasyon boru hattı, konteyner ve imaj yönetimi, çok ortamlı dağıtım stratejileri, yeniden kullanılabilir iş akışları, güvenlik ve uyumluluk entegrasyonu ile gözlemlenebilirlik ve optimizasyon yer alır.

GitLab kullanan ekipler için CI/CD Pipeline Tasarımı (GitLab) programında GitLab CI/CD mimarisi, gelişmiş pipeline tasarımı, runner yönetimi, test ve kalite kapıları, güvenlik tarama araçları, dağıtım ve ortam yönetimi ile GitOps başlıkları bulunur. Hangi platformu kullanıyorsanız ona uygun olanı seçebilirsiniz.