CI/CD PIPELINE NEDİR?

İki ekibi yan yana koyun. Birincisi cuma akşamı manuel deploy yapıyor: kodu zip'leyip sunucuya SFTP ile atıyor, veritabanı script'ini elle çalıştırıyor, log'lara bakıp dua ediyor. İkincisi commit mesajını push ettikten on iki dakika sonra otomatik olarak production'da çalışan sürümü görüyor — hiç kimse müdahale etmiyor. İkinci ekibin elindeki şey bir CI/CD pipeline'dır. Modern yazılım üretiminde manuel deploy'un yeri kalmadı; rekabet artık kaç saatte canlıya alabiliyorsun sorusuyla ölçülüyor. Bu yazı pipeline kavramını sıfırdan açıklar; geliştirici, sistem yöneticisi, ürün yöneticisi veya teknik karar alıcı pozisyonunda olan herkesin net bir zihin haritası taşıması için yazıldı.

CI ve CD Ayrımı

Kısaltma sık karışır. CI, continuous integration — sürekli entegrasyondur. Geliştiricilerin yazdığı kodun günde birden çok kez merkez branch'e birleştirilmesi ve her birleştirmede otomatik build + test yapılması anlamına gelir. CD'nin iki anlamı vardır: continuous delivery her geçen build'in deploy edilmeye hazır hale getirilmesi, continuous deployment ise her başarılı build'in insan müdahalesi olmadan production'a çıkması demektir.

Pratikte çoğu ekip continuous delivery'de durur — son aşamada manuel onay tutar. Continuous deployment'a geçmek için test kapsamı, monitoring ve rollback otomasyonunun olgun olması şart. Bu kavramların kökeni ve gelişimi sürekli entegrasyon kavramının tarihsel arka planı üzerinden anlaşıldığında pipeline'ın neden bu kadar değer kazandığı netleşir.

Pipeline Nasıl Çalışır?

Pipeline, kodun commit edildiği andan production'a vardığı ana kadar geçtiği otomatik adımların zinciridir. Her adım önceki adımın başarısına bağlıdır; herhangi biri kırılırsa zincir orada durur, ekip uyarılır.

Klasik tetiklenme akışı şu şekildedir:

1. Geliştirici kodu push eder veya pull request açar
2. CI sunucusu push event'ini algılar ve pipeline başlar
3. Bağımlılıklar yüklenir, kod derlenir (build)
4. Birim testleri, entegrasyon testleri, statik analiz koşar
5. Başarılıysa container image üretilir ve artifact deposuna yazılır
6. Staging ortamına otomatik deploy yapılır, smoke test çalışır
7. Onay veya otomatik kural ile production'a deploy gerçekleşir

Tüm bu adımların tanımı pipeline as code ilkesiyle YAML dosyasına yazılır ve repo ile birlikte versiyonlanır. Yani pipeline'ın kendisi de bir kod artefaktıdır — değişiklik geçmişi, kod review'u, rollback hepsi mümkün.

Tipik Pipeline Aşamaları

Endüstride farklı isimlerle anılsalar da çoğu pipeline benzer aşamalardan geçer. Aşağıdaki üç temel grup yapının iskeletini oluşturur.

Build Aşaması

Kaynak kod buradan çıktıya dönüşür. Java projesinde Maven veya Gradle ile JAR üretilir, JavaScript projesinde npm install ardından webpack/vite çalışır, Go projesinde tek komutla binary derlenir. Build adımı reproducible olmalı — aynı commit her zaman aynı çıktıyı vermeli. Bunu sağlamak için bağımlılık versiyonları lock dosyalarına sabitlenir ve build container içinde koşulur.

Test Aşaması

Pipeline'ın gerçek değeri büyük ölçüde buradadır. Test piramidi mantığıyla katmanlanır: tabanda hızlı ve bol unit test, ortada entegrasyon testleri, tepede yavaş end-to-end testler. Bazı ekipler bu aşamaya security scanning, license check, performance benchmark gibi ek kontroller de ekler. Test süresi pipeline'ın darboğazıdır; paralelleştirme ve test ortamı hazırlığı buradaki süreyi belirler.

Deploy Aşaması

Doğrulanmış artefakt hedef ortama dağıtılır. Modern pratikte deploy stratejileri çeşitlidir: blue-green deployment iki paralel ortam tutar, anlık geçiş yapar. Canary release yeni sürümü önce kullanıcının %5'ine, sonra %25'ine açar. Rolling update Kubernetes'in varsayılan davranışıdır — pod'ları kademeli yeniler. Hangi stratejinin seçileceği uygulamanın kritikliği ve trafik desenine bağlıdır.

Yaygın CI/CD Araçları

Pazarda olgun ve birbirinden farklı felsefelere sahip seçenekler var:

• Jenkins: En eski ve en esnek; on-premise kurulumlarda hâlâ baskın. Eklenti ekosistemi geniş ama bakım yükü ağır
• GitHub Actions: Repo ile aynı yerde, YAML dosyası bazlı, marketplace üzerinden hazır action paylaşımı kolay
• GitLab CI: Tek platformda hem repo hem pipeline hem registry; .gitlab-ci.yml dosyasıyla deklaratif
• Azure Pipelines: Microsoft ekosistemiyle entegre, multi-stage YAML desteği
• CircleCI / Travis CI / Drone: SaaS odaklı, hızlı kurulum, küçük-orta projelerde popüler
• ArgoCD / Flux: GitOps yaklaşımıyla deploy tarafına özelleşmiş, Kubernetes için

Araç seçimi teknolojiden çok ekosisteme bağlıdır. Repo'yu GitHub'da tutan bir ekip için GitHub Actions sürtünmesizdir; air-gapped enterprise ortamda Jenkins hâlâ en pratik. GitHub Actions resmi belgeleri başlangıç için iyi referans sağlar. Sıfırdan kurulum, pipeline mimarisi ve gerçek senaryolar üzerinden uygulamalı çalışmak isteyenler CI/CD ve DevOps eğitimi kapsamında konuyu uçtan uca işleyebilir.

CI/CD Pipeline'ın Faydaları

Pipeline'ın sağladığı kazanım yalnızca "hızlı deploy" değildir; toplam yazılım kalitesini bütünleyen birkaç farklı boyutta etki yapar:

• Erken hata yakalama: Bug üretime sızmadan, geliştirme yaparken yakalanır. Düzeltme maliyeti katlanarak azalır
• Deploy korkusunun yok olması: Manuel deploy stresli ve hata yüklüdür. Otomasyon, "deploy = rutin" haline getirir
• Tekrarlanabilir süreç: Her sürüm aynı adımlardan geçer. "Sadece o sunucuda çalışıyor" tipi sorunlar ortadan kalkar
• Hızlı geri alma: Sorunlu bir sürüm tespit edildiğinde bir önceki artefakta dakikalar içinde dönülür
• Audit ve uyumluluk: Her deploy'un kim, ne, ne zaman, hangi commit cevabı log'larda durur. Regülasyona tabi sektörler için kritik
• Geliştirici verimliliği: Test ve build otomatik olduğu için kod review odaklı hale gelir

Yaygın Hatalar ve Anti-Pattern'ler

Pipeline kurmak kolay; doğru kurmak öyle değil. En çok rastlanan hatalar:

Yavaş pipeline. Push'tan üretim'e 90 dakikalık akış geliştiricileri rutinden uzaklaştırır. Hedef genellikle 10-15 dakika altıdır. Çözüm: test paralelleştirme, cache stratejisi, gereksiz adımları temizleme.

Çevresel kayma. Staging başka, production başka davranıyorsa pipeline'ın doğrulama değeri düşer. Container ve infrastructure-as-code ile ortamlar aynı tanımdan üretilmeli.

Test kapsamı yokluğu. Otomatik deploy ama hiçbir test yoksa pipeline yalnızca "hızlı bozma makinesi"dir. Önce test piramidi kurulmalı.

Flaky testler. Bazen geçen bazen kalan testler ekibin pipeline'a güvenini sıfırlar. İnsanlar kırmızıyı görüp "yine sallandı, bypass et" demeye başladığı an kalite kapısı çöker. Flaky testler ya düzeltilir ya silinir.

Secret'lerin pipeline'a sızması. API anahtarı veya parolaların düz metin olarak YAML'a yazılması, log'lara basılması yaygın güvenlik açığıdır. Vault, sealed-secret veya pipeline native secret store kullanılmalı.

Pipeline bir defa kurulup unutulan bir araç değildir. Test süresi büyüdükçe paralel hale getirilmesi, deploy stratejisi değiştikçe pipeline'ın da güncellenmesi gerekir. Olgun bir ekip pipeline'ına ürün gibi davranır — kendi backlog'u, kendi metriği, kendi sahibi vardır.