CI/CD, modern yazılım teslimatının otomasyon omurgasıdır: bir kod değişikliğini geliştiricinin branch'inden production'a hızla, tekrarlanabilir biçimde ve her adımda ilerlemenin güvenli olduğuna dair kanıtla taşıyan pratikler ve araçlar bütünü. Bu rehber terimlerin gerçekte ne anlama geldiğini, bir pipeline'ın pratikte neye benzediğini ve GitHub Actions üzerinde nasıl kurulacağını anlatıyor — hiçbir uzun ömürlü bulut kimlik bilgisi kullanmayan, eksiksiz ve çalışan bir AWS Lambda deployment'ı dahil.

CI/CD Gerçekte Ne Demek?

Continuous Integration (CI), kod değişikliklerini ortak bir ana hatta sık — ideal olarak günlük — birleştirme ve her merge'ü otomatik bir build ve test paketiyle doğrulama pratiğidir. Amaç, entegrasyon problemlerini kendilerine yol açan değişiklikten dakikalar sonra, diff küçükken ve yazarın bağlamı hâlâ tazeyken yüzeye çıkarmaktır.

"CD" iki şekilde açılır ve aradaki fark önemlidir. Continuous Delivery, pipeline'ı geçen her değişikliğin deploy edilebilir bir artifact üretmesi, ama production'a çıkışın bilinçli bir karar olması demektir — tipik olarak manuel bir onay veya planlı bir release. Continuous Deployment bir adım ileri gider: geçen her değişiklik, insan kapısı olmadan otomatik olarak production'a çıkar. Ekiplerin çoğu continuous delivery uygular; continuous deployment, güçlü test kapsamı ve olgun operasyonları olan servisler için doğru varış noktasıdır. Şunu da not edin: her değişikliği deploy etmek release'leri kendi başına daha güvenli yapmaz — patlama yarıçapını sınırlayan şey deploy'un etrafındaki mekanizmadır: aşamalı rollout'lar, canary release'ler, health check'ler ve metrikler geriye gittiğinde otomatik rollback.

Bir Pipeline'ın Anatomisi

Hangi aracı kullanırsanız kullanın, pipeline her biri bir değişikliğin ilerlemesini durdurabilen aşamalar dizisidir:

  • Kaynak — bir pull request'te veya main branch'e merge'de bir tetikleyici ateşlenir.
  • Build — derle, bağımlılıkları çöz ve versiyonlu bir artifact üret: bir container imajı, bir zip paketi, bir package.
  • Test — her commit'te hızlı unit testler; maliyeti haklı çıktığı yerlerde entegrasyon ve uçtan uca testler.
  • Güvenlik kontrolleri — bağımlılık denetimi, statik analiz, secret taraması.
  • Staging'e deploy — artifact, değiştirilmeden, production benzeri bir ortama gider.
  • Production'a terfi — yine aynı artifact, bir onay kapısının arkasında veya otomatik olarak.

En önemli özellik şudur: bir kez build et, aynı artifact'i her yere deploy et. Staging ve production farklı build'ler çalıştırıyorsa, staging hiçbir şeyi doğrulamıyor demektir.

Referans Uygulama Olarak GitHub Actions

GitHub Actions, zaten GitHub'da olan ekipler için varsayılan CI/CD sistemidir ve modeli pipeline anatomisine doğrudan oturur. Bir workflow, .github/workflows/ içinde olaylara tepki olarak çalışan bir YAML dosyasıdır. Bir workflow bir veya daha fazla job içerir; her job bir runner üzerinde çalışır — GitHub'ın barındırdığı bir sanal makine, ya da sizin işlettiğiniz self-hosted bir makine veya container — ve sıralı step'lerden oluşur. Job'lar varsayılan olarak paralel çalışır ve needs ile sıralanabilir.

İşte bir Node.js projesi için minimal ama production kalitesinde bir CI workflow'u:

name: ci

on:
  pull_request:
  push:
    branches: [main]

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

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - run: npm ci
      - run: npm test

Bunu tutorial kodundan ayıran ayrıntılar: güncel major sürümlere sabitlenmiş action'lar (checkout@v4, setup-node@v4 — GitHub, ömrü dolmuş Node runtime'larında çalışan v2 gibi emekli major'ları hâlâ kullanan workflow'ları artık fail ettiriyor), aktif LTS hattı olarak Node 22, bağımlılık cache'i ve tekrarlanabilir kurulumlar için npm install yerine npm ci.

GitHub Actions ve OIDC ile AWS Lambda Deploy Etmek

Yayınlanmış tutorial'ların çoğunun yanlış yaptığı yer deployment'tır; genellikle AWS_ACCESS_KEY_ID ve AWS_SECRET_ACCESS_KEY'i repository secret'ı olarak saklayarak. CI'da uzun ömürlü bulut kimlik bilgileri bir yükümlülüktür: asla süresi dolmaz, loglar ve fork'lar üzerinden sızabilirler ve döndürülmeleri nadiren yapılan manuel bir iştir. Doğru desen — AWS ve GitHub tarafından 2021'den beri destekleniyor ve 2026'da tartışmasız en iyi pratik — OIDC federasyonudur: workflow GitHub'dan kısa ömürlü bir kimlik token'ı ister, bunu AWS STS'e sunar ve tam olarak o repository ve branch'e daraltılmış bir IAM rolünü üstlenir. Hiçbir yerde statik anahtar yoktur.

Tek seferlik AWS kurulumu:

  • token.actions.githubusercontent.com için bir IAM OIDC identity provider oluşturun.
  • Trust policy'si sts:AssumeRoleWithWebIdentity'ye yalnızca token'ın sub claim'i sizin repository ve branch'inizle eşleştiğinde izin veren (örneğin repo:your-org/your-repo:ref:refs/heads/main) ve permissions policy'si hedef fonksiyon üzerinde lambda:UpdateFunctionCode'a izin veren bir deployment rolü oluşturun.

Bu deployment rolünü fonksiyonun execution role'ünden ayrı tutun: execution role, çalışan Lambda kodunuza diğer AWS servislerine erişim veren roldür ve pipeline'ın o izinlere hiçbir zaman ihtiyacı yoktur. Servisin kendisi size yeniyse, AWS Lambda nedir ve ne zaman kullanılır yazımızla başlayın.

Eksiksiz deployment workflow'u:

name: deploy-lambda

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

concurrency:
  group: lambda-deploy
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - name: Install production dependencies
        run: npm ci --omit=dev

      - name: Package function
        run: zip -r bundle.zip . -x ".git/*" -x ".github/*"

      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-lambda-deploy
          aws-region: eu-central-1

      - name: Deploy
        run: |
          aws lambda update-function-code \
            --function-name my-lambda-function \
            --zip-file fileb://bundle.zip
          aws lambda wait function-updated \
            --function-name my-lambda-function

Güvenlik ve doğruluk yükünü dört satır taşıyor. permissions: id-token: write, job'un OIDC token'ı istemesine izin verir. Tetikleyici main üzerindeki push'larla sınırlıdır — çıplak bir on: push her branch'te ateşlenir; bu da bir deploy workflow'u için her feature branch'in production'a çıkması demektir. concurrency grubu, merge'ler art arda geldiğinde iki deploy'un yarışmasını engeller. Ve aws lambda wait function-updated, güncelleme tamamlanmazsa job'un yarım kalmış bir deploy'da yeşil raporlamak yerine yüksek sesle fail etmesini sağlar.

Test Kapıları

Bir pipeline ancak içindeki kapılar kadar güvenilirdir. Unit testleri ve lint'i her pull request'te çalıştırın ve branch protection'da required status check olarak işaretleyin; böylece kırmızı bir build merge edilmesi utanç verici değil, imkânsız olur. Daha yavaş entegrasyon ve uçtan uca paketleri main'e merge'lere veya deploy öncesi bir aşamaya saklayın. Flaky bir testi bir rahatsızlık değil bir olay gibi ele alın: mühendisler kırmızı bir build'i "muhtemelen sorun yoktur" diye ilk kez yeniden çalıştırdığında, kapı anlamını yitirmiştir. Bu paketlerin nasıl katmanlanacağını otomatik test stratejileri rehberimizde ele alıyoruz.

Environment'lar ve Onaylar

GitHub environment'ları release'in kontrol düzlemidir. Repository ayarlarında staging ve production tanımlayın, environment kapsamlı secret'ları ve değişkenleri bağlayın ve koruma kuralları ekleyin: production için zorunlu reviewer'lar, opsiyonel bekleme süreleri ve yalnızca main'in onu hedefleyebilmesi için deployment branch kısıtlamaları. Yukarıdaki workflow'daki environment: production satırı bu kuralları etkinleştiren şeydir — job, yetkili bir reviewer onaylayana kadar bekler ve her onay denetlenir. Bu, açık bir release kapısı olan continuous delivery'dir; zorunlu reviewer kuralını kaldırın, aynı pipeline continuous deployment olur.

Sık Yapılan Hatalar

  • CI'da statik bulut anahtarları. Bunları OIDC rol üstlenmesiyle değiştirin — AWS'de de, Azure ve Google Cloud'da da.
  • Kullanımdan kalkmış action major'ları. checkout@v2 ve benzerleri emekli runtime'larda çalışır ve artık düpedüz fail eder. Güncel major'lara sabitleyin ve güncellemeleri Dependabot önersin.
  • Fazla geniş tetikleyiciler. Filtrelenmemiş bir on: push her branch'ten çalışır — ve deploy eder. Deploy workflow'larını her zaman release branch'ine filtreleyin.
  • Ortam başına yeniden build. Test ettiğiniz artifact'i terfi ettirin; production için yeniden build, test edilmemiş bir build'dir.
  • Rollback yolunun olmaması. Lambda version ve alias'larını (sunucular için blue-green'i) kullanın; böylece rollback, baskı altında yeniden deploy değil bir pointer çevirme işlemi olur.

Bunların hiçbiri egzotik değil — yukarıdaki workflow'lar bir öğleden sonrada uyarlayabileceğiniz şablonlar. Zor olan kısım örgütseldir: test kapsamını yeşilin gerçekten "gönderilebilir" anlamına geldiği noktaya, deploy sıklığını release'lerin sıkıcı olduğu noktaya getirmek. DevOps danışmanlık pratiğimizin mühendislik ekipleriyle yaptığı iş tam olarak budur; ilk pipeline'dan tam otomatik teslimata kadar.

Bunu production'da mı çalıştırıyorsunuz? AWS Yönetilen Hizmetler ekibimiz bu tür ortamları 7/24 işletir — isimleri belli kıdemli mühendislerle izleme, olay müdahalesi, yama ve maliyet kontrolü, 3.000 €/ay'dan başlayan fiyatlarla.

Etiketler: #DevOps #CI/CD #GitHubActions #OIDC #AWS