CI/CD Nedir? Otomatik Test ve Yayın Hattı

Kısa cevap: CI/CD, yazılımdaki her değişikliğin otomatik olarak derlendiği, test edildiği ve kurallara uyuyorsa yayına alındığı hattır. CI (sürekli entegrasyon) "bu değişiklik bir şeyi bozdu mu?" sorusunu her kayıtta makineye sordurur; CD (sürekli teslim/yayın) ise testten geçen sürümü aynı adımlarla, elle dosya kopyalamadan sunucuya taşır. Sonuç: daha az "canlıda patladı" günü ve bozulduğunda dakikalar içinde geri dönebilen bir sistem.

CI/CD nedir, CI ile CD arasındaki fark ne?

İki kavram genelde birlikte anılır ama farklı sorulara cevap verir. Sürekli entegrasyon (Continuous Integration), geliştiricilerin kodu sık sık ortak depoya birleştirmesi ve her birleştirmede otomatik kontrollerin çalışmasıdır. Sürekli teslim (Continuous Delivery), testten geçen her sürümün yayına hazır paket hâline getirilmesidir; yayın düğmesine hâlâ bir insan basar. Sürekli yayın (Continuous Deployment) ise o düğmeyi de kaldırır: kontrollerden geçen her değişiklik kendiliğinden canlıya çıkar.

• CI: her kayıtta derleme, tip kontrolü, lint ve otomatik testler çalışır; kırmızı sonuç birleştirmeyi durdurur.
• Continuous Delivery: yeşil sürüm paketlenir ve test ortamına çıkar; canlıya geçiş tek tıkla ama onaylı yapılır.
• Continuous Deployment: onay adımı yoktur; güçlü test kapsamı ve izleme şarttır.

Çoğu kurumsal proje için doğru başlangıç, CI + Continuous Delivery ikilisidir. Tamamen otomatik yayın, test kapsamı ve izleme olgunlaştıktan sonra düşünülmesi gereken bir adımdır.

CI/CD olmayan projede ne olur?

CI/CD olmayan projelerde yayın genelde bir kişinin bilgisayarında yapılır: kod derlenir, dosyalar FTP ya da SSH ile sunucuya atılır, bir şey unutulursa site yarım kalır. Bu süreç çalışıyor gibi görünür, ta ki o kişi izne çıkana ya da bir adımı atlayana kadar. Sorunlar hep aynı kalıptadır:

• Yayın kişiye bağlıdır; bilgi bir kafada durur, yazılı ve tekrar edilebilir değildir.
• "Benim bilgisayarımda çalışıyordu" sorunu: geliştiricinin ortamı ile sunucu farklıdır.
• Testler çalıştırılsa bile elle çalıştırılır; acele edilen gün atlanır.
• Geri almak için önceki sürümün tam olarak ne olduğu bilinmez.
• Yayınlar korkutucu olduğu için seyrekleşir; biriken büyük değişiklikler daha fazla hata çıkarır.

CI/CD'nin asıl kazancı hız değil öngörülebilirliktir: her yayın aynı adımlarla, aynı kontrollerden geçerek yapılır ve kimin ne zaman neyi yayına aldığı kayıt altındadır.

Tipik bir CI/CD hattının adımları

Araç ne olursa olsun (GitHub Actions, GitLab CI, Azure DevOps, Jenkins) iyi bir hat aşağı yukarı aynı sırayı izler. Her adım bir öncekinden geçemezse hat durur ve kimse "sonra düzeltiriz" diyerek canlıya bozuk kod gönderemez.

• Bağımlılıkların kilit dosyasından birebir kurulması (npm ci gibi) — her seferinde aynı sürümler.
• Statik kontroller: tip kontrolü, lint, biçim kontrolü.
• Otomatik testler: birim testleri, gerekirse entegrasyon ve uçtan uca testler.
• Derleme ve paketleme: çoğu zaman bir Docker imajı; imaj sürüm numarası ya da commit ile etiketlenir.
• Test (staging) ortamına yayın ve kısa bir duman testi.
• Onaylı canlı yayın, ardından sağlık kontrolü; başarısızsa otomatik geri dönüş.

Testlerin neyi kapsaması gerektiği ayrı bir konudur; hangi test türünün ne zaman işe yaradığını yazılım test süreci ve QA yazımızda anlattık. CI/CD, o testleri her değişiklikte kimseye sormadan çalıştıran mekanizmadır.

Örnek: GitHub Actions ile basit bir CI hattı

Aşağıdaki dosya bir Node.js / Next.js projesinde her pull request ve ana dala her birleştirmede tip kontrolü, lint, test ve derlemeyi çalıştırır. Bir adım kırmızı yanarsa birleştirme engellenir (depo ayarlarında "status check zorunlu" açıldığında).

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run typecheck
      - run: npm run lint
      - run: npm test --if-present
      - run: npm run build

Yayın (CD) adımı bunun üzerine ayrı bir iş olarak eklenir: yalnızca ana dalda, CI yeşilse çalışır, imajı üretir ve sunucuya gönderir. Sunucu erişim anahtarları kodun içine değil, CI aracının gizli değişken alanına konur ve yalnızca yayın işine açılır.

Geri alma planı: hattın en çok unutulan parçası

Her yayın hattı bir gün bozuk bir sürüm çıkarır; önemli olan ne kadar hızlı geri dönüldüğüdür. Geri alma planı yayından önce yazılmalıdır, olay anında değil.

• Her sürüm değişmez bir etiketle saklanır; geri almak önceki etiketi yeniden çalıştırmaktır.
• Veritabanı değişiklikleri (migration) geriye uyumlu yazılır: önce yeni sütun eklenir, eski sütun ancak bir sonraki sürümde kaldırılır.
• Yayın sonrası sağlık kontrolü (ör. /health adresi) başarısızsa trafik eski sürüme döner.
• Büyük özellikler özellik bayrağı (feature flag) arkasında yayınlanır; sorun çıkarsa kod geri alınmadan kapatılır.

Kod geri alınabilir ama silinen veri geri alınamaz. Bu yüzden CI/CD, yedekleme stratejisinin yerini tutmaz; ikisi birlikte çalışır. Yedek tarafını veri yedekleme ve felaket kurtarma yazısında ele aldık.

Yazılım firmasına sormanız gereken 5 soru

CI/CD teknik bir konu gibi görünse de müşteri açısından doğrudan risk yönetimidir. Bir özel yazılım ya da web geliştirme projesi başlatırken şu soruların net cevabı olmalı:

• Yayın nasıl yapılıyor, elle mi otomatik mi? Adımlar yazılı mı?
• Her değişiklikte hangi kontroller çalışıyor, test kırmızıysa yayın durur mu?
• Canlıdan ayrı bir test (staging) ortamı var mı?
• Bozuk bir sürüm çıkarsa geri dönmek ne kadar sürer, bunu kim yapar?
• Proje teslim edildiğinde CI/CD tanımları ve depo erişimi bize devrediliyor mu?

Son soru özellikle önemlidir: hat tanımları depoda dosya olarak durduğunda, firma değişse bile yayın süreci sizinle kalır. Bakım döneminde bu altyapının nasıl işletildiğini web sitesi bakım maliyetleri yazısında ayrıca anlattık.

Sonuç

CI/CD, küçük bir ekip için bile kurulmaya değer: ilk kurulum çoğu projede birkaç dosyadan ibarettir, kazancı ise her yayında geri döner. Önce CI ile başlayın, test ortamı ve onaylı yayın ekleyin, geri alma planını yazılı hâle getirin. Projenizde otomatik test ve yayın hattı kurmak ya da mevcut süreci gözden geçirmek isterseniz teklif alın; ihtiyacınıza uygun yapıyı birlikte çıkaralım.