Yazılım projelerinde en zor başlıklardan biri kodu üretmek değil, onu güvenle canlı ortama taşımaktır. Geliştirme ekibi bir özelliği tamamladığında iş bitmiş sayılmaz; test, paketleme, onay, dağıtım ve geri alma gibi adımlar da en az bunun kadar kritiktir. Tam bu noktada ci cd nedir sorusu öne çıkar. CI/CD, yazılım değişikliklerini daha sık, daha kontrollü ve daha izlenebilir biçimde yayınlamayı mümkün kılan bir teslim modelidir.

CI, yani Continuous Integration, geliştiricilerin kod değişikliklerini gün içinde sık aralıklarla ortak depoya birleştirmesini ifade eder. CD ise bağlama göre Continuous Delivery ya da Continuous Deployment anlamına gelir. İlki, yazılımı canlıya hazır hale gelene kadar otomatik olarak taşır; son adımda insan onayı kalabilir. İkincisi ise testleri geçen sürümü doğrudan üretim ortamına alır. Aradaki fark çoğu zaman tek bir onay kapısıdır, ancak etkisi oldukça büyüktür.

Manuel yayın süreçlerinde 12 adımlı bir kontrol listesi, 2 saatlik gece mesaisi ve birden fazla ekip onayıyla karşılaşmak şaşırtıcı değildir. İyi kurgulanmış bir CI/CD hattı ise aynı akışı dakikalar içinde ve her seferinde aynı standartla çalıştırabilir. Bu yalnızca hızla ilgili değildir. Hata oranı düşer, yayın stresinin seviyesi azalır, geri dönüş süresi kısalır.

CI/CD nedir? Temel mantık ve iki kritik kavram

CI/CD’yi anlamanın en pratik yolu, kodun yazıldığı an ile müşterinin kullandığı an arasındaki hattı düşünmektir. Bu hat üzerinde derleme, test, güvenlik kontrolü, paketleme ve dağıtım adımları bulunur. Hedef, her değişiklikte aynı akışın çalışmasıdır. Bir geliştirici saat 10:15’te yeni kod gönderdiğinde sistem 1-2 dakika içinde derleme yapabilir, birim testlerini çalıştırabilir, Docker imajı üretebilir ve test ortamına dağıtımı başlatabilir.

Continuous Integration ne yapar?

Continuous Integration yaklaşımında küçük ve sık kod birleştirmeleri esas alınır. Haftada 1 büyük merge yerine günde 5-10 küçük commit çok daha sağlıklıdır. Çünkü bir hata varsa kaynağını bulmak kolaylaşır. CI aşamasında genellikle şu kontroller otomatik olarak çalışır:

  • Kodun derlenmesi veya build alınması
  • Birim testleri
  • Statik kod analizi
  • Bağımlılık ve güvenlik taramaları
  • Artefact üretimi

Buradaki kritik nokta tutarlılıktır. Aynı testin bir geliştiricinin bilgisayarında geçip sunucuda kalması istenmez. Pipeline, her seferinde aynı ortam mantığıyla çalışır.

Continuous Delivery ve Continuous Deployment farkı

Bu iki kavram sık sık karıştırılır. Continuous Delivery modelinde yazılım her an yayınlanabilir durumda tutulur; yine de canlıya geçiş için ürün yöneticisi, operasyon ekibi veya müşteri onayı gerekebilir. Continuous Deployment ise testi geçen her sürümün otomatik olarak canlıya çıkmasıdır. Örneğin B2C bir SaaS ürününde günde 20 dağıtım makul olabilir. Finans, sağlık veya kamu entegrasyonları içeren sistemlerde ise son onayın insan tarafından verilmesi daha gerçekçi bir tercihtir.

CI/CD pipeline nasıl çalışır?

Bir pipeline, çoğu şirkette benzer bir omurgaya sahiptir; ancak detaylar teknoloji yığınına göre değişir. Node.js tabanlı bir web uygulaması ile .NET üzerinde çalışan kurumsal bir ERP modülünün adımları birebir aynı olmayabilir. Yine de tipik akış net biçimde tanımlanabilir.

  1. Geliştirici kodu Git deposuna gönderir.
  2. Pipeline tetiklenir.
  3. Build işlemi başlar.
  4. Otomatik testler çalışır.
  5. Güvenlik ve kalite kontrolleri yapılır.
  6. Paket veya container imajı üretilir.
  7. Staging ortama dağıtım yapılır.
  8. Gerekirse onay alınır.
  9. Üretim ortamına dağıtım gerçekleşir.
  10. Log, metrik ve health check sonuçları izlenir.

Basit bir YAML örneği bile bu mantığı somutlaştırır:

stages:
  - build
  - test
  - deploy

build:
  script:
    - npm install
    - npm run build

test:
  script:
    - npm run test

deploy:
  script:
    - kubectl apply -f k8s/deployment.yaml

Bu örnek yalın tutulmuştur. Gerçek projelerde buna cache, secret yönetimi, paralel test, rollback ve ortam bazlı değişkenler de eklenir. Yine de 3 aşamalı bu yapı hattın özünü gösterir: üret, doğrula, yayınla.

İşletmelere ne kazandırır? Hız, kalite ve operasyonel netlik

CI/CD’nin en görünür çıktısı, daha hızlı yayın döngüsüdür. Eskiden ayda 1 kez çıkan sürüm, doğru altyapıyla haftada birkaç kez hatta günde birkaç kez yayınlanabilir. Buradaki amaç “daha çok dağıtım” yapmak değildir; küçük değişiklikleri daha düşük riskle yönetmektir. 1 büyük paket yerine 6 küçük paket yayınlandığında, sorunlu değişikliği izole etmek kolaylaşır.

Bir diğer önemli fayda kalite tarafındadır. Manuel testler tamamen ortadan kalkmaz, ancak tekrarlayan kontroller otomasyona taşınır. Her commit’te çalışan 150 birim testi, 20 entegrasyon testi ve temel güvenlik taraması, insan gözünden kaçabilecek hataları erken aşamada yakalayabilir. Hatanın geliştirme anında bulunması ile canlıda bulunması arasında maliyet farkı oluşur. Kesin, evrensel bir oran vermek doğru olmaz; ancak yazılım ekiplerinin pratik deneyimi, erken tespitin çok daha ucuz olduğunu açık biçimde gösterir.

İş birimleri açısından da kazanım nettir. Ürün yöneticisi yeni bir kampanya sayfası için 10 gün beklemek yerine 1-2 gün içinde güncelleme alabilir. Operasyon ekipleri hafta sonu gece dağıtımına daha az ihtiyaç duyar. Yönetim tarafı ise hangi sürümün ne zaman çıktığını, hangi testlerden geçtiğini ve gerekirse hangi commit’e dönüleceğini kayıtlı biçimde görebilir.

Hata oranını nasıl azaltır? Somut senaryolarla açıklama

CI/CD tek başına hataları sihirli biçimde ortadan kaldırmaz. Yanlış tasarlanmış testler, eksik gözlemleme ya da düzensiz branching modeli varsa sorunlar sürer. Ancak hata üretme ihtimali yüksek alanları disipline eder.

Senaryo 1: Konfigürasyon farkı

Geliştirici ortamında çalışan bir özelliğin staging’de bozulması sık görülür. Bunun nedeni çoğu zaman farklı çevresel değişkenler, bağımlılık sürümleri ya da eksik migration dosyalarıdır. Pipeline içine otomatik migration kontrolü ve ortam bazlı doğrulama eklendiğinde, bu sınıftaki hatalar yayın öncesinde yakalanır.

Senaryo 2: İnsan kaynaklı atlanan adım

Manuel dağıtımda biri yanlış branch’i seçebilir, bir dosyayı eksik kopyalayabilir ya da servisi yeniden başlatmayı unutabilir. Özellikle 8-10 adımdan oluşan checklist’lerde bu risk artar. CI/CD, dağıtım adımlarını kod olarak tanımladığı için aynı işlemi her seferinde aynı sırayla yürütür.

Senaryo 3: Sorun çıktığında geri dönüş

Yeni sürümde bir problem fark edildi. Eğer sistemde versiyonlanmış artefact, container image etiketi ve otomatik rollback stratejisi varsa önceki sürüme 2-3 dakika içinde dönülebilir. Manuel modelde bu süre çok daha uzun olabilir; üstelik hangi dosyanın ne zaman değiştiğini bulmak da ayrı bir iş yükü yaratır.

CI/CD için hangi araçlar kullanılır?

Araç seçimi, teknoloji stack’ine, güvenlik gereksinimlerine ve ekip yetkinliğine göre yapılmalıdır. Tek bir “en iyi araç” yoktur. Sık kullanılan örnekler arasında GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps, Bitbucket Pipelines ve CircleCI yer alır. Container tarafında Docker, orkestrasyon için Kubernetes, altyapı otomasyonu için Terraform ya da Ansible tercih edilebilir.

Türkiye’deki orta ve büyük ölçekli işletmelerde seçim yapılırken 4 başlık öne çıkar: mevcut ekosistem uyumu, audit kayıtları, rol bazlı yetkilendirme ve self-hosted çalışma ihtiyacı. Örneğin regülasyon baskısı olan bir kurum, pipeline verisini kendi ağı içinde tutmak isteyebilir. SaaS tabanlı araçlar hız kazandırırken bazı sektörlerde şirket içi kurulum daha uygun olabilir.

CI/CD’ye geçerken sık yapılan hatalar

En yaygın hata, süreci yalnızca araç kurulumundan ibaret sanmaktır. Jenkins veya GitLab kurulduğunda problem çözülmüş olmaz. Önce branch stratejisi, test kapsamı, release politikası ve secret yönetimi netleşmelidir. Pipeline, bu kuralların uygulama motorudur.

İkinci hata, her şeyi ilk haftada otomatikleştirmeye çalışmaktır. Daha sağlıklı yaklaşım, kademeli ilerlemektir. İlk 2 hafta build ve temel testler otomatikleşir. Sonraki sprint’te staging deploy eklenir. Ardından güvenlik taraması, smoke test ve rollback mekanizması gelir. Bu şekilde ilerleyen ekipler daha sürdürülebilir sonuç alır.

Bir başka kritik nokta ise ölçümdür. DORA benzeri metrikler burada işe yarar: deployment frequency, lead time for changes, change failure rate, mean time to restore. Her ekip tüm metrikleri aynı olgunlukta kullanmak zorunda değildir. Yine de ayda 1 dağıtımdan haftada 3 dağıtıma çıkmak veya geri dönüş süresini 90 dakikadan 10 dakikaya indirmek gibi somut hedefler, dönüşümü daha yönetilebilir kılar.

Hangi şirketler için öncelikli bir ihtiyaç?

Her yazılım ekibi CI/CD’den fayda görür, ancak bazı yapılarda ihtiyaç daha keskindir. Birden fazla geliştiricinin aynı kod tabanında çalıştığı ekipler ilk sırada gelir. 4 kişilik bir web ürün ekibinde bile merge çakışmaları ve yayın stresi kısa sürede büyüyebilir. Mikroservis mimarisi kullanan yapılarda ihtiyaç daha da artar; 12 servisli bir sistemde manuel koordinasyon ciddi bir darboğaz yaratır.

E-ticaret, SaaS, lojistik, üretim, finansal entegrasyon, saha operasyonu ve çok lokasyonlu B2B platformlar da güçlü adaylardır. Çünkü bu yapılarda kesinti maliyeti yüksektir. Bir sipariş akışının, stok entegrasyonunun veya bayi portalı güncellemesinin hatalı yayınlanması doğrudan operasyonu etkiler. Düzenli sürüm çıkaran kurumlar için CI/CD artık “iyi olur” kategorisinden çıkmıştır; temel teslim altyapısının bir parçası haline gelmiştir.

Sonuç: CI/CD bir araç değil, teslim disiplinidir

CI/CD’yi yalnızca teknik bir otomasyon başlığı olarak görmek eksik kalır. Aslında bu yaklaşım, yazılımı daha öngörülebilir biçimde üretime taşıma disiplinidir. Küçük değişiklikler, sık doğrulama, otomatik kontroller ve izlenebilir dağıtım akışları; hem ekip içi verimliliği hem de iş tarafındaki güveni artırır. Hedef, tek seferde kusursuz yayın yapmak değil; riski küçük parçalara bölerek yönetilebilir hale getirmektir. Doğru kurgulanmış bir CI/CD hattı, yazılım ekiplerinin hız ile kalite arasında sürekli seçim yapmak zorunda kalmasını büyük ölçüde azaltır.