CI/CD İşlem Hattı En İyi Uygulamaları: Güvenilir Dağıtımlara Giden Yolunuzu Otomatikleştirin

Olgun CI/CD ardışık düzenlerine sahip ekipler, olmayanlara göre 208 kat daha sık dağıtım yaparken, değişiklik hatası oranları da 7 kat daha düşük. Kırılgan "çoğunlukla işe yarıyor" işlem hattı ile savaşta test edilmiş dağıtım sistemi arasındaki fark, amatör otomasyonu üretim sınıfı altyapıdan ayıran bir avuç uygulamaya dayanır.

Bu kılavuz, CI/CD işlem hatlarını geniş ölçekte güvenilir kılan somut uygulamaları, yapılandırmaları ve mimari kararları kapsar.

Önemli Çıkarımlar

• Ardışık düzen yürütme süresi, geliştirici üretkenliğini doğrudan etkiler --- tüm paket için 10 dakikanın altındaki hedef
• CI'daki güvenlik taraması, güvenlik açıklarının %85'ini üretime ulaşmadan önce yakalar
• Otomatik geri alma mekanizmaları, ortalama kurtarma süresini saatlerden dakikalara indirir
• Şube koruma kuralları ve gerekli durum kontrolleri, bozuk kodun ana bilgisayara ulaşmasını önler

---

Boru Hattı Mimarisi

Beş Aşamalı Model

Her üretim CI/CD işlem hattı beş aşamayı uygulamalıdır:

1. Aşama: Lint ve Doğrulama (hedef: <2 dakika)

lint:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
        cache: pnpm
    - run: pnpm install --frozen-lockfile
    - run: pnpm lint
    - run: pnpm typecheck

2. Aşama: Test (hedef: <8 dakika)

test:
  runs-on: ubuntu-latest
  services:
    postgres:
      image: postgres:17
      env:
        POSTGRES_PASSWORD: test
        POSTGRES_DB: test
      ports:
        - 5432:5432
      options: >-
        --health-cmd pg_isready
        --health-interval 10s
        --health-timeout 5s
        --health-retries 5
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
        cache: pnpm
    - run: pnpm install --frozen-lockfile
    - run: pnpm test
      env:
        DATABASE_URL: postgresql://postgres:test@localhost:5432/test

3. Aşama: Oluşturma (hedef: <5 dakika)

Docker görüntüleri oluşturun, varlıkları derleyin, üretim paketleri oluşturun. Bağımlılıkları agresif bir şekilde önbelleğe alın.

4. Aşama: Hazırlamaya Dağıtım

Ana ile birleştirmede otomatik dağıtım. Hazırlama ortamına karşı duman testleri yapın.

5. Aşama: Üretime Dağıtım

Manuel onay kapısı veya aşamalandırma doğrulama geçişlerinden sonra otomatikleştirilmiş.

---

Hız Optimizasyonu

Yavaş işlem hatları geliştirici üretkenliğini azaltır. Ekip genelinde CI bekleme süresinin her dakikasıyla çarpılması, bağlam değiştirme süresinde saatlerce kayıp oluşmasına neden olur.

Paralelleştirme

Bağımsız işleri aynı anda çalıştırın:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [...]

  test-unit:
    runs-on: ubuntu-latest
    steps: [...]

  test-integration:
    runs-on: ubuntu-latest
    steps: [...]

  test-e2e:
    runs-on: ubuntu-latest
    steps: [...]

  build:
    needs: [lint, test-unit, test-integration, test-e2e]
    runs-on: ubuntu-latest
    steps: [...]

Bağımlılığı Önbelleğe Alma

- uses: actions/cache@v4
  with:
    path: |
      ~/.pnpm-store
      node_modules
      apps/*/node_modules
      packages/*/node_modules
    key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}
    restore-keys: |
      ${{ runner.os }}-pnpm-

Docker Katmanını Önbelleğe Alma

- uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: registry.example.com/app:${{ github.sha }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

Boru Hattı Hız Karşılaştırmaları

---

Güvenlik Taraması

Bağımlılık Güvenlik Açığı Taraması

security:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - name: Run Snyk to check for vulnerabilities
      uses: snyk/actions/node@master
      env:
        SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      with:
        args: --severity-threshold=high

    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: fs
        scan-ref: .
        severity: CRITICAL,HIGH
        exit-code: 1

Gizli Tarama

    - name: Detect secrets
      uses: trufflesecurity/trufflehog@main
      with:
        extra_args: --only-verified

SAST (Statik Uygulama Güvenliği Testi)

    - name: CodeQL Analysis
      uses: github/codeql-action/analyze@v3
      with:
        languages: javascript-typescript

Güvenlik Kapısı Politikası

---

Şube Koruma ve Birleştirme Stratejisi

Gerekli Durum Kontrolleri

Bunları ana dalda gerekli durum kontrolleri olarak yapılandırın:

1. Tüysüz ve daktilo kontrolünden geçmelidir
2. Tüm birim testlerinin başarılı olması gerekir
3. Tüm entegrasyon testlerinin başarılı olması gerekir
4. Güvenlik taramasında kritik/yüksek bulgu bulunmamalıdır
5. Derleme başarılı olmalı

Birleştirme Stratejisi

Temiz bir geçmişi korumak için özellik dalları için kabak birleştirmelerini kullanın:

main: A --- B --- C --- D (each is a squashed feature)

PR'ler için en az bir onay gerektir. Kritik yollar için (kimlik doğrulama, faturalandırma, veritabanı geçişleri) iki onay gerekir.

---

Dağıtım Stratejileri

Mavi-Yeşil Dağıtım

İki özdeş üretim ortamını koruyun. Trafiği birine dağıtırken diğerine yönlendirin.

#!/bin/bash
# blue-green-deploy.sh

CURRENT=$(kubectl get service production -o jsonpath='{.spec.selector.version}')

if [ "$CURRENT" == "blue" ]; then
  TARGET="green"
else
  TARGET="blue"
fi

echo "Current: $CURRENT, deploying to: $TARGET"

# Deploy to inactive environment
kubectl set image deployment/$TARGET-app app=registry.example.com/app:$TAG

# Wait for rollout
kubectl rollout status deployment/$TARGET-app --timeout=300s

# Run smoke tests against target
curl -sf "http://$TARGET.internal/health" || exit 1

# Switch traffic
kubectl patch service production -p "{\"spec\":{\"selector\":{\"version\":\"$TARGET\"}}}"

echo "Traffic switched to $TARGET"

Devamlı Dağıtım

Bölmeleri aşamalı olarak güncelleyin:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 0

maxUnavailable: 0 dağıtım sırasında kapasite kaybı yaşanmamasını sağlar.

Kanarya Dağıtımı

Trafiğin küçük bir yüzdesini yeni sürüme yönlendirin:

# Using Istio for traffic splitting
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app-canary
spec:
  hosts:
    - app.example.com
  http:
    - route:
        - destination:
            host: app-stable
          weight: 95
        - destination:
            host: app-canary
          weight: 5

Daha fazla dağıtım stratejisi için sıfır kesinti süreli dağıtımlar hakkındaki özel kılavuzumuza bakın.

---

Geri Alma Otomasyonu

Durum Denetimi Başarısızlığında Otomatik Geri Alma

deploy-production:
  runs-on: ubuntu-latest
  steps:
    - name: Deploy
      run: |
        kubectl set image deployment/app app=${{ env.IMAGE }}
        kubectl rollout status deployment/app --timeout=300s

    - name: Smoke tests
      run: |
        sleep 30
        STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://app.example.com/health)
        if [ "$STATUS" != "200" ]; then
          echo "Health check failed with status $STATUS"
          kubectl rollout undo deployment/app
          exit 1
        fi

    - name: Monitor error rate
      run: |
        # Check error rate over 5 minutes
        ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total{status=~'5..'}[5m])/rate(http_requests_total[5m])" | jq '.data.result[0].value[1]' -r)
        if (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
          echo "Error rate $ERROR_RATE exceeds threshold"
          kubectl rollout undo deployment/app
          exit 1
        fi

---

Monorepo Boru Hattı Optimizasyonu

Monorepo projeleri için (Turborepo kullananlar gibi), yalnızca değişenleri çalıştırın:

- name: Determine affected packages
  id: affected
  run: |
    AFFECTED=$(npx turbo run build --filter='...[HEAD~1]' --dry-run=json | jq -r '.packages[]')
    echo "packages=$AFFECTED" >> $GITHUB_OUTPUT

- name: Test affected packages
  if: steps.affected.outputs.packages != ''
  run: npx turbo run test --filter='...[HEAD~1]'

Bu, büyük bir monorepoda yalnızca tek bir paketi etkileyen değişiklikler için CI süresini %60-80 oranında azaltır.

---

Sıkça Sorulan Sorular

Üretime ne sıklıkta dağıtım yapmalıyız?

İşlem hattınızın izin verdiği sıklıkta dağıtım yapın. Yüksek performanslı ekipler günde birden çok kez konuşlanır. Amaç, gözden geçirilmesi, test edilmesi ve geri alınması kolay olan küçük, artımlı değişikliklerdir. Dağıtım riskli görünüyorsa bu, işlem hattınızın daha az dağıtıma değil, daha fazla otomatik teste ve daha iyi geri alma mekanizmalarına ihtiyaç duyduğunun bir işaretidir.

Grank tabanlı geliştirmeyi mi yoksa özellik dallarını mı kullanmalıyız?

Kısa ömürlü (1-3 gün) özellik dalları çoğu ekip için en iyi sonucu verir. Trunk tabanlı geliştirme, daha olgun test altyapısı ve özellik bayrakları gerektirir. Önemli olan dalların kısa ömürlü olmasıdır; uzun ömürlü özellik dalları birleştirme çatışmaları yaratır ve geri bildirimi geciktirir.

CI/CD'deki veritabanı geçişlerini nasıl ele alıyoruz?

Geçişleri, uygulama dağıtımından önce ayrı bir işlem hattı adımı olarak çalıştırın. Geçişlerin geriye dönük olarak uyumlu olduğundan emin olun (eski uygulama sürümünün yeni şemayla çalışması gerekir). Genişlet ve daralt modelini kullanın: önce yeni sütunlar ekleyin, hem eski hem de yeniye yazan kodu dağıtın, verileri taşıyın, ardından sonraki sürümde eski sütunları kaldırın.

CI için doğru test piramidi nedir?

Tipik bir web uygulaması için: %70 birim testleri (hızlı, yalıtılmış), %20 entegrasyon testleri (API uç noktaları, veritabanı sorguları), %10 E2E testleri (kritik kullanıcı akışları). Birim testleri her işlemde çalıştırılır. Entegrasyon testleri PR üzerinde yürütülür. E2E testleri ana ile birleştirme sırasında veya üretim dağıtımından önce gerçekleştirilir.

---

Sırada Ne Var?

İyi tasarlanmış bir CI/CD işlem hattı, diğer tüm DevOps uygulamalarının temelidir. Güvenilir otomasyon uygulandığında, kod olarak altyapı, üretim izleme ve yük testi işlemlerini güvenle gerçekleştirebilirsiniz.

CI/CD işlem hattı tasarımı ve uygulaması için ECOSIRE ile iletişime geçin veya altyapı yol haritasının tamamı için Küçük işletmeler için DevOps kılavuzumuzu inceleyin.

---

ECOSIRE tarafından yayınlandı - işletmelerin yazılımı güvenle dağıtmasına yardımcı oluyor.