CI/CD Pipeline ve DevOps Nedir?

Geleneksel yazılım geliştirme dönemlerinde yeni bir ürün özelliğinin kodlanıp canlı sunuculara (production) aktarılması haftalar, hatta aylar süren stresli bir operasyondu. "Dağıtım gecesi" (Deployment Night) olarak bilinen bu süreçte geliştiriciler kodlarını birleştirir, saatlerce süren manuel derleme ve birleştirme çakışmalarıyla (merge hell) uğraşır, sistem yöneticileri ise gece yarısı sunucuları kapatıp yeni paketleri yüklemeye çalışırdı. Günümüzün yüksek rekabetli uygulama ve yazılım dünyasında ise Amazon, Netflix ve Google gibi teknoloji liderleri günde binlerce kez sıfır kesintiyle (Zero-Downtime) canlı ortama kod göndermektedir. Bu hızı, güvenliği ve kaliteyi mümkün kılan mühendislik disiplini DevOps kültürü ve onun teknik omurgası olan CI/CD Pipeline (Sürekli Entegrasyon ve Sürekli Dağıtım) mimarisidir. Bu kapsamlı rehberde; DevOps felsefesinden CI/CD boru hattının tüm otomatik test ve güvenlik (DevSecOps) aşamalarına, GitHub Actions ve GitLab CI yapılandırmalarından Blue/Green ve Canary dağıtım stratejilerine kadar tüm detayları inceliyoruz.

DevOps Nedir? Kültür, Otomasyon ve Siloların Yıkılışı

DevOps, İngilizce Development (Yazılım Geliştirme) ve Operations (BT Sistem Operasyonları) kelimelerinin birleşiminden oluşan; yazılım geliştirme ekipleri ile sistem/altyapı ekipleri arasındaki geleneksel duvarları (silos) yıkarak, yazılımın fikir aşamasından son kullanıcıya ulaşmasına kadar geçen süreci kısaltmayı ve güvenilirliğini artırmayı hedefleyen bir mühendislik kültürü, pratikler bütünü ve otomasyon felsefesidir.

Geleneksel organizasyonlarda iki ekip arasında doğal bir çıkar çatışması vardı: Yazılım geliştiriciler (Dev) iş birimlerinin istediği yeni özellikleri mümkün olduğunca hızlı canlıya almak (Değişim / Change) isterken; Sistem Yöneticileri (Ops) sunucuların çökmemesi ve sistemin stabil kalması için hiçbir şeyin değişmemesini (İstikrar / Stability) isterdi. Geliştirici kodu yazar, "duvarın üzerinden" operasyon ekibine atar ve canlıda bir sorun çıktığında iki ekip birbirini suçlardı. DevOps kültürü ise Werner Vogels'in ünlü "You build it, you run it" (Kodunu sen yazdıysan, canlıda da sen çalıştırırsın) prensibiyle ortak sorumluluk getirir. DevOps bir iş unvanından önce CALMS (Culture - Kültür, Automation - Otomasyon, Lean - Yalınlık, Measurement - Ölçümleme, Sharing - Paylaşım) ilkelerine dayanan bir çalışma biçimidir.

CI/CD Pipeline (Boru Hattı) Nedir ve Nasıl Çalışır?

CI/CD Pipeline, bir yazılımcının bilgisayarında yazdığı kaynak kodun versiyon kontrol sistemine (Git) gönderildiği (commit/push) andan itibaren; otomatik olarak derlenmesi, kod kalitesi ve güvenlik taramalarından geçirilmesi, otomatik testlerinin koşulması, paketlenmesi ve nihayetinde test/üretim sunucularına insan eli değmeden dağıtılması adımlarından oluşan otomatize edilmiş iş akışı zinciridir. CI/CD kısaltması üç temel kavramı barındırır:

1. CI - Continuous Integration (Sürekli Entegrasyon)
2. CD - Continuous Delivery (Sürekli Teslimat)
3. CD - Continuous Deployment (Sürekli Dağıtım)

1. Sürekli Entegrasyon (Continuous Integration - CI) Aşamaları

Sürekli Entegrasyon (CI), geliştirici ekibindeki tüm mühendislerin yaptıkları kod değişikliklerini haftalarca kendi yerel dallarında (local branches) bekletmek yerine, günde en az bir veya birkaç kez ana kod dalıyla (main / trunk) birleştirmesi ve her birleştirme isteğinde (Pull Request / Merge Request) otomatik bir doğrulama boru hattının tetiklenmesi pratiğidir. CI aşamasının temel amacı "Fail Fast" (Hızlı Hata Yakalama) prensibidir: Bir hata üretim ortamında müşterinin karşısına çıktığında düzeltme maliyeti, kod yazıldıktan 3 dakika sonra CI pipeline'ında yakalanmasına göre 100 kat daha yüksektir.

Modern bir kurumsal CI boru hattı sırasıyla şu teknik adımlardan (Stages) oluşur:

• Kaynak Kodun Çekilmesi ve Linting (Biçim Kontrolü): Git deposundan son commit çekilir. ESLint, Checkstyle, Ruff veya GolangCI-Lint gibi araçlarla kodun kurumsal yazım standartlarına uygunluğu ve sözdizimi hataları saniyeler içinde denetlenir.
• Derleme (Build & Dependency Resolution): Uygulama bağımlılıkları (npm, Maven, NuGet, Go Modules, Pip) önbellekten (cache) yüklenir ve kaynak kod derlenerek sözdizimsel bütünlüğü doğrulanır.
• Birim Testleri (Unit Tests) ve Kod Kapsama Oranı (Code Coverage): Dış bağımlılıklardan (veritabanı, ağ) yalıtılmış yüzlerce birim testi (JUnit, PyTest, Jest, xUnit) paralel olarak çalıştırılır. Eğer testlerden tek biri bile başarısız olursa veya kod kapsama oranı belirlenen eşiğin (örneğin %80) altına düşerse boru hattı anında kırmızıya döner ve kodun ana dala birleştirilmesi (Merge) engellenir.
• Statik Kod Analizi ve Güvenlik Taraması (SAST & SCA - DevSecOps): Güvenliği sürecin en sonuna bırakmak yerine CI aşamasına dahil eden "Shift-Left Security" yaklaşımı uygulanır. SonarQube, Semgrep veya Snyk gibi araçlarla kaynak kod içindeki SQL Injection, XSS açıkları, "code smell" bulguları, unutulmuş API anahtarları (Secret Scanning) ve açık kaynak kütüphanelerdeki bilinen güvenlik zafiyetleri (CVE) otomatik taranır.
• Entegrasyon Testleri ve Artifact (İmaj) Oluşturma: Testcontainers gibi teknolojilerle geçici Docker veritabanları kaldırılarak API ve veritabanı entegrasyon testleri koşulur. Tüm testler başarıyla geçerse uygulama versiyonlanarak (Semantic Versioning / Git SHA) bir Docker imajı haline getirilir, Trivy ile imaj güvenliği taranır ve kurumsal imaj kayıt defterine (Docker Hub, AWS ECR, GitHub Container Registry, Harbor) yüklenir.

2. Sürekli Teslimat (Continuous Delivery) vs Sürekli Dağıtım (Continuous Deployment)

Yazılım dünyasında "CD" kısaltması iki farklı olgunluk seviyesini ifade eder ve aralarındaki fark kritik bir operasyonel tercihtir:

• Continuous Delivery (Sürekli Teslimat): CI aşamasından başarıyla çıkan paket otomatik olarak Test (QA) ve Ön-Üretim (Staging / Pre-Prod) ortamlarına dağıtılır; burada uçtan uca (E2E - Playwright/Cypress) ve yük testlerinden geçer. Paket canlıya alınmaya %100 hazırdır, ancak canlı ortama (Production) geçiş için bir ürün yöneticisi veya baş mühendisin tek tıkla manuel onay (Manual Approval Gate) vermesi beklenir. Bankacılık, sağlık ve regülasyonlara tabi kurumsal yazılımlarda en çok tercih edilen modeldir.
• Continuous Deployment (Sürekli Dağıtım): Otomasyonun zirvesidir. CI, entegrasyon, güvenlik ve Staging üzerindeki uçtan uca testlerin tamamından başarıyla geçen her kod değişikliği, hiçbir insan onayına veya manuel müdahaleye gerek kalmadan doğrudan canlı üretim sunucularına (Production) otomatik olarak dağıtılır ve dakikalar içinde son kullanıcıya ulaşır.

Örnek Üretim Seviyesi GitHub Actions CI/CD YAML İş Akışı

Aşağıda bir mikroservisin her kod gönderiminde testlerini koşan, güvenlik taramasını yapan ve başarılı olduğunda Docker imajını derleyip yayınlayan gerçek bir GitHub Actions (.github/workflows/ci-cd.yml) yapılandırması yer almaktadır:

name: Production CI/CD Pipeline

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

jobs:
  test-and-analyze:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Source Code
        uses: actions/checkout@v4

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

      - name: Install Dependencies & Lint
        run: |
          npm ci
          npm run lint

      - name: Run Unit & Integration Tests
        run: npm run test:coverage

  build-and-deploy:
    needs: test-and-analyze
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Source Code
        uses: actions/checkout@v4

      - name: Build & Push Docker Image to Registry
        run: |
          docker build -t registry.sirket.com/order-service:${{ github.sha }} .
          docker push registry.sirket.com/order-service:${{ github.sha }}

      - name: Trigger Zero-Downtime Kubernetes Rollout
        run: |
          kubectl set image deployment/order-service order-service=registry.sirket.com/order-service:${{ github.sha }} --record
          kubectl rollout status deployment/order-service --timeout=120s

Kesintisiz Canlıya Alma (Zero-Downtime Deployment) Stratejileri

Modern bulut teknolojisi ve SaaS platformlarında "Bakım çalışması nedeniyle sitemiz 2 saat kapalıdır" ekranı kabul edilemez. CI/CD boru hatları, yeni sürümü canlıya alırken kesintisiz hizmet ve anında geri alma (Instant Rollback) için şu dört dağıtım stratejisini kullanır:

1. Rolling Update (Kademeli Güncelleme): Mevcut 10 sunucu/pod kopyasının tamamını aynı anda kapatmak yerine, önce 2 adet yeni sürüm (v2) ayağa kaldırılır; sağlık kontrolünden (Readiness Probe) geçtiklerinde eski sürümden (v1) 2 kopya kapatılır. Tüm kopyalar yenilenene kadar bu döngü sürer. Ek sunucu maliyeti yaratmaz.
2. Blue/Green Deployment (Mavi/Yeşil Dağıtım): Üretim ortamında birbirinin tıpatıp aynısı iki ortam tutulur. Mevcut kullanıcı trafiğinin %100'ü Mavi (v1) ortamındadır. Yeni sürüm Yeşil (v2) ortamına kurulur ve duman testleri (Smoke Tests) yapılır. Her şey kusursuzsa Load Balancer / Router seviyesinde trafik tek saniyede Mavi'den Yeşil'e çevrilir. Bir sorun çıkarsa trafik 1 saniyede tekrar Mavi'ye döndürülerek sıfır veri kaybıyla Rollback yapılır.
3. Canary Deployment (Kanarya Dağıtımı): Yeni sürüm (v2) canlıya alındığında tüm kullanıcılara açılmaz. Önce gerçek kullanıcı trafiğinin yalnızca %2'si veya sadece belirli bir coğrafi bölge yeni sürüme yönlendirilir. Prometheus ve hata izleme araçları (Sentry/Datadog) üzerinden 15 dakika boyunca hata oranları ve gecikme metrikleri izlenir; sorun yoksa trafik kademeli olarak %10, %50 ve %100'e çıkarılır.
4. Feature Flags (Özellik Bayrakları - Dark Launching): Kodun canlı sunucuya dağıtılması (Deployment) ile özelliğin son kullanıcıya açılması (Release) birbirinden ayrılır. Yeni kod if (featureFlags.isEnabled("new-checkout")) bloğu içinde kapalı olarak canlıya gönderilir; çalışma anında kod dağıtmadan sadece yönetim panelinden belirli müşteri grupları için aktif edilir.

Ayrıca günümüzde CI/CD süreçleri; altyapının da kod olarak yönetildiği Infrastructure as Code (IaC - Terraform, Pulumi, Ansible) ve Kubernetes durumunun doğrudan Git depoları üzerinden senkronize edildiği GitOps (ArgoCD, Flux) yaklaşımlarıyla birleşmiştir. Eski kurumsal sistemlerin CI/CD standartlarına kavuşturulmasında yapay zeka destekli tersine mühendislik (REA) ile otomatik birim testlerin üretilmesi, Headless Commerce ve mikroservis API ekosistemlerinde yüzlerce bağımsız boru hattının şablonlaştırılması, No-Code uygulama geliştirme platformlarında görsel sürüm kontrolü ve Web3 ve merkezsiz web projelerinde akıllı sözleşme güvenlik denetimlerinin (Smart Contract Audits) CI aşamasına gömülmesi modern yazılım mühendisliğinin yeni standartlarını oluşturmaktadır.

Popüler CI/CD Araçları ve Dağıtım Aşamaları Karşılaştırma Tablosu

Yazılım yaşam döngüsündeki CI/CD kavramlarının ve sektörde en çok kullanılan otomasyon platformlarının temel farklarını aşağıdaki tabloda karşılaştırdık:

Karşılaştırma Kriteri	Continuous Integration (CI)	Continuous Delivery (CD)	Continuous Deployment (CD)
Temel Hedef	Kod birleştirme hatalarını anında yakalamak	Her an canlıya çıkmaya hazır doğrulamış paket üretmek	Her başarılı kodu anında son kullanıcıya ulaştırmak
Kapsadığı Aşamalar	Lint, Build, Unit Test, SAST Güvenlik Taraması	CI + Staging Dağıtımı, E2E Test, Yük Testi	CI + Delivery + Otomatik Production Dağıtımı
Canlıya Alma Tetikleyicisi	Uygulanamaz (Sadece paket/imaj üretir)	Yetkili kişinin manuel onayı (Manual Gate)	%100 Otomatik (İnsan müdahalesi yok)
Test Otomasyon Gereksinimi	Yüksek (Birim ve entegrasyon testleri şart)	Çok Yüksek (API ve arayüz testleri dahil)	Kusursuz (Tüm testler + Otomatik Rollback metrikleri)
En Popüler Araçlar	GitHub Actions, GitLab CI, Jenkins, CircleCI	GitLab CI, Azure DevOps, Spinnaker, Harness	ArgoCD (GitOps), Flux, GitHub Actions + Flagger
DORA Metriklerine Etkisi	Değişiklik Hata Oranını (Change Failure Rate) düşürür	Dağıtım hazırlık süresini (Lead Time) kısaltır	Dağıtım Sıklığını (Deployment Frequency) zirveye taşır

DevOps Başarısını Ölçmek: 4 DORA Metriği

Google'ın DevOps Research and Assessment (DORA) ekibi tarafından yürütülen araştırmalar, yüksek performanslı yazılım ekiplerini diğerlerinden ayıran dört somut mühendislik metriği belirlemiştir: 1) Dağıtım Sıklığı (Deployment Frequency): Canlı ortama ne kadar sık başarılı kod gönderildiği; 2) Değişiklik Teslim Süresi (Lead Time for Changes): Bir commit'in yazılıp canlıda çalışmaya başlamasına kadar geçen süre; 3) Değişiklik Hata Oranı (Change Failure Rate): Canlıya alınan dağıtımların yüzde kaçının acil müdahale veya geri alma gerektirdiği; 4) Ortalama Kurtarma Süresi (MTTR - Mean Time to Recovery): Canlı ortamda bir kesinti olduğunda sistemin tekrar sağlıklı duruma dönme süresi. İyi kurgulanmış bir CI/CD boru hattı ilk iki metriği hızlandırırken, son iki metriği sıfıra yaklaştırır.

Sıkça Sorulan Sorular (SSS)

1. GitHub Actions, GitLab CI ve Jenkins arasında hangisi tercih edilmeli?

Jenkins, açık kaynaklı, eklenti ekosistemi çok geniş ancak kendi sunucularınızda bakım, güncelleme ve ölçekleme yükü gerektiren geleneksel bir araçtır. Eğer kodlarınız GitHub üzerinde barınıyorsa, sıfır sunucu bakımı ve zengin hazır aksiyon pazaryeri (Marketplace) nedeniyle GitHub Actions en pratik seçimdir. Kurumsal düzeyde uçtan uca entegre bir DevSecOps platformu, dahili Container Registry ve kendi sunucunuzda barındırma (Self-Managed) esnekliği arıyorsanız GitLab CI/CD endüstri standardıdır.

2. Birim testlerimiz (Unit Tests) yoksa yine de CI/CD kurabilir miyiz?

Teknik olarak sadece kodu derleyip sunucuya kopyalayan bir boru hattı kurabilirsiniz; ancak içinde otomatik test olmayan bir CI/CD hattı sadece "hatalı kodu canlı ortama çok daha hızlı taşıyan bir otomasyon" olur. Sürekli Entegrasyonun (CI) varlık sebebi kodu doğrulamaktır. Bu nedenle en azından temel derleme kontrolü, statik kod analizi (Lint/SAST) ve kritik iş akışlarını denetleyen duman testleri (Smoke Tests) ile başlanıp test kapsamı kademeli olarak artırılmalıdır.

3. GitOps (ArgoCD) ile klasik CI/CD arasındaki fark nedir?

Klasik "Push tabanlı" CI/CD'de, GitHub Actions veya Jenkins derleme bittikten sonra üretim Kubernetes kümesinin yönetici şifresine sahip olarak dışarıdan içeriye kubectl apply komutu gönderir (bu durum güvenlik riski oluşturabilir). GitOps yaklaşımında ise Kubernetes kümesinin içinde çalışan ArgoCD veya Flux ajanı, dışarıdaki bir Git deposunu (Altyapı/Manifest deposu) sürekli izler (Pull tabanlı). Git deposundaki YAML dosyası güncellendiğinde ArgoCD değişikliği çekerek kümeye uygular; kümede biri manuel değişiklik yaparsa da otomatik olarak Git'teki orijinal haline geri döndürür (Drift Detection).

4. DevSecOps nedir ve CI/CD boru hattına nasıl entegre edilir?

DevSecOps, siber güvenlik kontrollerinin yazılım geliştirildikten aylar sonra yapılan manuel sızma testlerine (Penetration Testing) bırakılmayıp, doğrudan CI/CD boru hattının içine otomatik adımlar olarak yerleştirilmesidir. Her commit'te Gitleaks ile şifre sızıntısı kontrolü, SonarQube/Semgrep ile SAST (Statik Kod Analizi), Snyk/Dependabot ile bağımlılık taraması (SCA), Trivy ile Docker imaj taraması ve OWASP ZAP ile DAST (Dinamik Uygulama Güvenlik Testi) otomatik çalıştırılarak kritik bir açık bulunduğunda dağıtım anında durdurulur.

5. Canlıya alınan yeni sürümde kritik bir hata çıkarsa CI/CD nasıl geri alır (Rollback)?

Modern CI/CD mimarisinde her dağıtım değiştirilemez (Immutable) ve benzersiz etiketli bir Docker imajı (örneğin v1.4.2) üzerinden yapılır. Yeni sürüm (v1.4.3) canlıya alındığında hata oranı yükselirse, kodun eski halini tekrar derlemek için 15 dakika beklenmez; Kubernetes veya Load Balancer seviyesinde çalışan imaj referansı saniyeler içinde bir önceki sağlam imaja (v1.4.2) geri çekilir. Hatta Argo Rollouts veya Flagger gibi araçlar Prometheus metriklerinde hata artışı gördüğünde insan müdahalesi olmadan otomatik Rollback gerçekleştirir.