CI/CD Nedir?

Üç kavram, üç ayrı taahhüt

"CD" kısaltması iki farklı pratiği anlatabildiği için CI/CD sık sık bulanık kullanılır. Aradaki fark, otomasyonun nerede durduğudur:

CI'ın özü bir araç değil, bir alışkanlıktır: geliştiriciler değişikliklerini ana dala sık ve küçük parçalar hâlinde birleştirir; her birleştirme otomatik olarak doğrulanır. Haftalarca ayrı dalda bekleyen kod, ne kadar araç kullanılırsa kullanılsın, birleşme anında sorun çıkarır.

Testler bir kapıdır

Tipik bir pipeline; kod stili ve tip kontrolü, birim testleri, derleme (ör. bir Docker imajı üretmek), entegrasyon testleri, test ortamına dağıtım ve son olarak canlıya dağıtım aşamalarından oluşur. Temel kural basittir: bir aşama başarısız olursa sonraki aşama çalışmaz. Aşağıdaki GitHub Actions örneğinde deploy işi, test işi geçmeden başlamaz:

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 24
      - run: npm ci
      - run: npm run lint
      - run: npm test

  deploy:
    needs: test                       # testler geçmeden çalışmaz
    if: github.event_name == 'push'   # pull request'lerde dağıtım yok
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v5
      - run: ./scripts/deploy.sh

production ortamına GitHub'da onay kuralı tanımlanırsa bu hat sürekli teslimat olur; kural yoksa her başarılı push doğrudan canlıya çıkar ve sürekli dağıtım hâline gelir. Sözdiziminin ayrıntıları GitHub Actions belgelerinde yer alır; GitLab CI, Jenkins gibi araçlarda da mantık aynıdır.

Önemli bir ilke de "bir kez derle, her yere dağıt"tır: test ortamında doğrulanan paket ya da imaj, canlıya da aynen gönderilmelidir. Her ortam için yeniden derlemek, test edilmemiş bir şeyin yayına çıkması demektir.

Geri alma (rollback) planı

Ne kadar test yazılırsa yazılsın, bazı hatalar ancak canlıda görünür. Bu yüzden hızlı geri dönüş, pipeline'ın kendisi kadar önemlidir:

• Sürümlü ve değişmez paketler: Her yayın commit kimliği ya da sürüm numarasıyla etiketlenirse, geri almak önceki etiketi yeniden dağıtmaktan ibarettir.
• Kademeli yayın: Blue-green dağıtımda yeni sürüm eskisinin yanında hazırlanır ve trafik tek hamlede çevrilir; canary yayında trafiğin küçük bir kısmı önce yeni sürüme yönlendirilir.
• Feature flag: Riskli bir özellik kod geri alınmadan kapatılabilir.
• Veritabanı değişikliklerine dikkat: Kodu geri almak şemayı geri almaz. Göçler (migration) önce ekleyen, sonra temizleyen adımlarla, eski kodla da uyumlu kalacak biçimde tasarlanmalıdır.

Sık yapılan hatalar

• Ara sıra rastgele başarısız olan (flaky) testleri görmezden gelmek; ekip kırmızı sonuca güvenmemeye başladığında kapı işlevini yitirir.
• Acil durumlarda testleri atlayıp elle dağıtım yapmak; en riskli değişiklikler genellikle bunlardır.
• Sırları depoya ya da pipeline dosyasına açık metin olarak yazmak; CI aracının gizli değişken özelliği kullanılmalıdır.
• Dakikalarca süren hatlara katlanmak; geri bildirim yavaşladıkça geliştiriciler daha büyük ve seyrek değişiklik yapmaya başlar.

Kendi yayın hattına sahip çok sayıda servisten oluşan mikroservis mimarilerinde bu disiplin bir tercih değil, zorunluluktur. CI/CD, yazılım ekiplerinde en yaygın otomasyon örneklerinden biridir.