CI/CD Nedir?
Sürekli Entegrasyon ve Dağıtım Rehberi

Eskiden yazılım güncellemeleri büyük olaydı. Haftalarca süren geliştirme döngülerinin ardından, bir gece yarısı herkes nefesini tutarak deploy butonuna basardı. Bir şeyler ters giderse geri alma planları hazırdı, ama çoğu zaman geri alma planının da kendi sorunları olurdu. Bugün, iyi yapılandırılmış bir CI/CD pipeline'ıyla günde onlarca hatta yüzlerce deployment yapan ekipler var ve bu deployment'ların çoğu sıfır kesintiyle gerçekleşiyor.

CI, CD ve... CD: Kavramları Ayıralım

CI/CD terimi aslında üç farklı kavramı barındırır ve bunlar sıklıkla karıştırılır. Netleştirelim.

Continuous Integration (Sürekli Entegrasyon - CI): Geliştiricilerin kodlarını sık sık (günde birkaç kez) ana branch'e entegre etmesi ve her entegrasyonun otomatik build ve testlerle doğrulanması pratiğidir. Amaç, entegrasyon sorunlarını mümkün olduğunca erken yakalamaktır. Bir geliştirici kodunu push ettiğinde, CI sistemi otomatik olarak kodu derler, unit testleri çalıştırır ve sonucu raporlar. Sorun varsa geliştirici dakikalar içinde bilgilendirilir.

Continuous Delivery (Sürekli Teslimat - CD): CI'ın bir adım ötesi. Kod her zaman deploy edilebilir durumda tutulur. Testlerden geçen her değişiklik, bir onay adımının ardından production'a deploy edilebilir. Burada önemli nokta şu: deploy etme kararı hala bir insanın onayına bağlıdır, ama teknik olarak her an deploy yapılabilecek hazırlık seviyesindedir.

Continuous Deployment (Sürekli Dağıtım - CD): Continuous Delivery'nin son noktası. Testlerden başarıyla geçen her değişiklik, insan müdahalesi olmadan otomatik olarak production'a deploy edilir. Bu modeli uygulamak güçlü bir test altyapısı ve monitoring gerektirir çünkü güvenlik ağınız artık tamamen otomasyondadır.

Birçok ekip Continuous Delivery noktasında kalır ve bu gayet makul bir tercihtir. Production deployment'ı için bir insan onayı istemek, özellikle regülasyona tabi sektörlerde, hem güvenlik hem de uyumluluk açısından değerlidir.

CI/CD Neden Bu Kadar Önemli?

CI/CD'nin sağladığı faydalar sadece teknik değil, aynı zamanda organizasyonel ve ticari boyutta da etkili.

Hataları erken yakalarsınız. Bir hata, kodun yazıldığı gün mü yoksa iki hafta sonra mu bulunursa daha kolay düzeltilir? Cevap belli. CI ile her push'ta testler çalışır ve sorunlar dakikalar içinde ortaya çıkar. Hatanın context'i hala geliştiricinin zihninde taze olduğu için düzeltme süresi dramatik şekilde kısalır.

Deployment korkusu ortadan kalkar. Küçük, sık ve otomatik deployment'lar yapıldığında, her deployment düşük risklidir. Bir şey ters giderse değişiklik küçük olduğu için nerede sorun olduğunu bulmak ve geri almak kolaydır. Büyük, nadir deployment'lar ise her zaman yüksek risklidir.

Geliştirme hızı artar. Manuel test, build ve deployment süreçleri otomatize edildiğinde, geliştiriciler bu işlerle uğraşmak yerine değer üreten kod yazmaya odaklanır. Ayrıca hızlı geri bildirim döngüsü sayesinde iterasyon hızı artar.

Tutarlılık sağlanır. Pipeline her seferinde aynı adımları, aynı sırayla, aynı ortamda çalıştırır. İnsan hatası faktörü ortadan kalkar. "Ali deploy ederken sorun olmuyor ama Ayşe deploy edince patlıyor" gibi durumlar yaşanmaz.

Pipeline Aşamaları

Tipik bir CI/CD pipeline'ı şu aşamalardan oluşur:

1. Source (Kaynak)

Pipeline, bir kod değişikliğiyle tetiklenir. Bu genellikle bir git push veya pull request oluşturma işlemidir. Pipeline kaynağı olarak GitHub, GitLab, Bitbucket veya Azure Repos gibi platformlar kullanılır.

2. Build (Derleme)

Kaynak kodu derlenir, bağımlılıklar yüklenir ve çalıştırılabilir bir yapı (artifact) oluşturulur. Bu aşamada syntax hataları ve derleme hataları yakalanır. Docker kullanılıyorsa bu aşamada container image oluşturulur.

3. Test

Oluşturulan artifact üzerinde çeşitli testler çalıştırılır. Unit testler, integration testler, linting, statik kod analizi ve güvenlik taramaları bu aşamada gerçekleşir. Test aşaması başarısız olursa pipeline durur ve geliştirici bilgilendirilir.

4. Deploy (Dağıtım)

Testlerden geçen artifact, hedef ortama deploy edilir. Genellikle önce staging ortamına, ardından production'a deploy yapılır. Deployment stratejisi (rolling, blue-green, canary) bu aşamada devreye girer.

GitHub Actions ile basit bir pipeline örneği:

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Node.js kur
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Bağımlılik yukle
        run: npm ci

      - name: Lint kontrol
        run: npm run lint

      - name: Unit testler
        run: npm test

      - name: Build
        run: npm run build

  deploy:
    needs: build-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Production deploy
        run: echo "Deploy adımları burada"

Popüler CI/CD Araçları

Piyasada onlarca CI/CD araçı var, ama pratikte birkaç tanesi öne çıkıyor.

GitHub Actions: GitHub ile doğal entegrasyon en büyük avantajı. YAML tabanlı workflow tanımları, zengin marketplace (hazır action'lar) ve ücretsiz katmanı ile özellikle açık kaynak projeler ve GitHub kullanan ekipler için ilk tercih. Marketplace'teki binlerce hazır action sayesinde karmaşık pipeline'ları bile birkaç satır YAML ile kurabilirsiniz.

GitLab CI/CD: GitLab'ın yerleşik CI/CD çözümü. Kod yönetimi ve CI/CD'nin tek platformda olması büyük kolaylık sağlar. Auto DevOps özelliğiyle sıfır konfigürasyonla temel bir pipeline oluşturabilir. Self-hosted runner desteği ile kendi altyapınızda çalıştırabilirsiniz.

Jenkins: Açık kaynak dünyanın en eski ve en esnek CI/CD araçı. Binlerce plugin ile neredeyse her ihtiyaça uyarlanabilir. Ancak kurulum ve bakımı diğer araçlara göre daha zahmetlidir. Declarative pipeline'lar (Jenkinsfile) ile modern bir kullanım deneyimi sunsa da, yeni projeler için genellikle GitHub Actions veya GitLab CI tercih ediliyor.

CircleCI: Hız ve basitlik odaklı bulut tabanlı CI/CD platformu. Docker desteği güçlü, paralel test çalıştırma yetenekleri gelişmiş. Orbing adı verilen yeniden kullanılabilir konfigürasyon parçaları ile pipeline tanımlarını modüler hale getirebilirsiniz.

Test Stratejileri

CI/CD pipeline'ının güvenilirliği, testlerin kalitesine doğrudan bağlıdır. Test piramidi kavramı burada devreye girer.

Unit testler (taban): En hızlı ve en ucuz testlerdir. Tek bir fonksiyonu veya sınıfı izole şekilde test eder. Binlerce unit test saniyeler içinde çalışır. Pipeline'ın ilk test adımı olmalıdır. Bir değişikliğin mevcut mantığı bozup bozmadığını anında gösterir.

Integration testler (orta): Bileşenlerin birbirleriyle doğru çalıştığını doğrular. Veritabanı bağlantıları, API çağrıları, servisler arası iletişim bu katmanda test edilir. Unit testlerden daha yavaş ama daha gerçekçi senaryoları kapsar.

End-to-end testler (tepe): Tüm sistemi bir kullanıcı gibi test eder. Tarayıcı otomasyonu (Cypress, Playwright) ile gerçek kullanım senaryoları simüle edilir. En yavaş ve en kırılgan test türüdür, bu yüzden sayıları sınırlı tutulmalıdır. Sadece kritik kullanıcı yolculuklarını (kayıt, giriş, ödeme gibi) kapsamalıdır.

Sağlıklı bir test piramidinde unit testler çoğunluğu oluştururken, end-to-end testler azınlıkta kalır. Tersine dönmüş bir piramit (çok sayıda E2E testi, az sayıda unit test) yavaş pipeline'lara ve kırılgan test süitelerine yol açar.

Deployment Stratejileri

Kodunuz testlerden geçti, artık production'a deploy etme zamanı. Ama nasıl? Farklı stratejiler farklı risk profillerine ve gereksinimlere hitap eder.

Rolling Update: Eski pod'lar kademeli olarak yenileriyle değiştirilir. Herhangi bir anda hem eski hem yeni versiyon çalışıyor olabilir. Kubernetes'in varsayılan stratejisidir. Ek altyapı gerektirmez ama geri alma işlemi yeni bir deployment gerektirir.

Blue-Green Deployment: İki özdeş ortam (blue ve green) bulunur. Aktif ortam (diyelim blue) trafiği karşılarken, yeni versiyon green ortama deploy edilir. Green ortam test edildikten sonra trafik bir anda green'e yönlendirilir. Sorun çıkarsa trafik tekrar blue'ya döndürülür. Hızlı geri alma sağlar ama çift altyapı maliyeti vardır.

Canary Deployment: Yeni versiyon önce trafiğin küçük bir yüzdesine (mesela %5) sunulur. Metrikler izlenir: hata oranı, yanıt süresi, CPU kullanımı. Her şey normalse trafik kademeli olarak artırılır (%10, %25, %50, %100). Sorun tespit edilirse canary pod'lar kaldırılır ve tüm trafik eski versiyona döner. En güvenli stratejidir ama kurulumu daha karmaşıktır.

CI/CD Best Practice'leri

Yılların deneyiminden süzülmüş birkaç kritik pratik:

Pipeline'ı hızlı tutun. 30 dakika süren bir pipeline, geliştiricilerin geri bildirim döngüsünü yavaşlatır. Testleri paralel çalıştırın, cache kullanın, gereksiz adımları kaldırın. Hedef: push'tan sonuç almaya kadar 10 dakikanın altı.

Trunk-based development uygulayın. Uzun ömürlü feature branch'ler, birleştirme cehennemine yol açar. Küçük, sık merge'ler yapın. Feature flag'lerle tamamlanmamış özellikleri production'da gizleyin.

Pipeline konfigürasyonunu kod olarak yönetin. Pipeline tanımları (YAML dosyaları) repo'da kaynak kodla birlikte versiyonlanmalıdır. Pipeline'daki bir değişiklik de code review'dan geçmelidir.

Seçret'ları pipeline'a hardcode etmeyin. API anahtarları, veritabanı şifreleri gibi hassas bilgileri CI/CD platformunun secret yönetim özelliğiyle veya HashiCorp Vault gibi araçlarla yönetin.

Başarısız pipeline'ı hemen düzeltin. Kırık bir pipeline tüm ekibi bloke eder. "Main branch her zaman yeşildir" kuralını benimseyin. Pipeline kırıldığında diğer işler dursun, önce pipeline düzeltilsin.

CI/CD, modern yazılım geliştirmenin bel kemiğidir. DevOps hizmetlerimiz kapsamında ekibinize özel CI/CD pipeline tasarımı ve kurulumu sunuyoruz. Doğru kurgulanmış bir pipeline, ekibinizin daha hızlı, daha güvenli ve daha tutarlı şekilde yazılım teslim etmesini sağlar. Küçük başlayın; basit bir build-test-deploy akışıyla başlayıp zamanla olgunlaştırın. Mükemmel pipeline'ı ilk günde kurmak zorunda değilsiniz, ama ilk günden pipeline'ınızın olması gerekiyor.