GitHub Actions ile CI/CD Pipeline Kurma Rehberi

GitHub Actions, kodunu her push'ladığında testlerini çalıştıran ve her şey yeşilse projeni otomatik olarak sunucuya deploy eden bir otomasyon aracıdır. Repository'nin içinde yaşar, ayrı bir servise abone olmana gerek yoktur ve açık kaynak projelerde cömert bir ücretsiz kotayla gelir. Bu rehberde sıfırdan bir CI/CD pipeline'ı kuracağız: önce kavramları netleştirecek, sonra gerçek bir test ve deploy workflow'u yazacağız.

CI/CD ve GitHub Actions neden işine yarar?

CI (Continuous Integration), her kod değişikliğini otomatik olarak derleyip test etmektir; böylece bozuk bir commit'i daha merge etmeden yakalarsın. CD (Continuous Delivery/Deployment) ise testlerden geçen kodu otomatik olarak hazırlama ya da canlı ortama göndermektir. İkisini birleştiren akışa CI/CD pipeline denir.

Elle "lokalde testleri çalıştır, FTP'yle dosya at, parmaklarını çapraz yap" döngüsü hem yavaş hem hataya açıktır. GitHub Actions bu döngüyü tekrarlanabilir hale getirir:

• Tutarlılık: Pipeline temiz bir sanal makinede çalışır, "bende çalışıyordu" sorununu büyük ölçüde ortadan kaldırır.
• Hız: Job'lar paralel koşabilir; lint, test ve build aynı anda ilerler.
• Güvenlik: SSH anahtarları ve token'lar repository secret'larında şifreli saklanır, koda gömülmez.

Temel kavramlar: workflow, job, step, action

GitHub Actions'ın sözlüğü küçük ama önemlidir:

• Workflow: .github/workflows/ klasöründeki bir YAML dosyası. Ne zaman ve neyin çalışacağını tanımlar.
• Event (trigger): Workflow'u başlatan olay — push, pull_request, zamanlanmış schedule ya da elle workflow_dispatch.
• Job: Aynı runner üzerinde çalışan adımlar grubu. Job'lar varsayılan olarak paralel, needs ile sıralı koşar.
• Step: Bir job'ın içindeki tek bir komut (run) ya da hazır bir uses action.
• Runner: Job'ın koştuğu sanal makine, örneğin ubuntu-latest.

İlk workflow: testleri çalıştırmak

Bir Node.js projesi düşünelim. Repository kökünde .github/workflows/ci.yml dosyasını oluştur:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    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 test

actions/checkout@v4 repon'u runner'a klonlar, setup-node doğru Node sürümünü kurar ve cache: npm ile bağımlılıkları cache'ler. npm ci, package-lock.json'a birebir sadık kalan temiz bir kurulum yapar; CI ortamında npm install'dan daha güvenilirdir. Bu dosyayı push'ladığın anda her commit ve pull request'te testler otomatik koşar.

Matrix ile birden çok sürümü test etmek

Bir kütüphaneyi birden fazla dil sürümünde test etmek istersen strategy.matrix tek bir job'ı çoğaltır:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Bu workflow aynı testi Node 18, 20 ve 22 üzerinde paralel çalıştırır. PHP/Laravel tarafında aynı mantıkla shivammathur/setup-php action'ı ile birden çok PHP sürümünü deneyebilir, ardından php artisan test çalıştırabilirsin.

Secret'lar ve deploy job'u

Deploy adımı sunucuya erişim ister, bu da sır demektir. SSH özel anahtarını veya API token'ını asla YAML'e yazma. Bunun yerine GitHub'da Settings → Secrets and variables → Actions altında bir secret oluştur (örneğin SSH_PRIVATE_KEY, SSH_HOST) ve workflow'da ${{ secrets.SSH_HOST }} ile çağır.

Aşağıdaki örnek, testler geçtikten sonra deploy yapan ikinci bir job ekler. needs: test sayesinde deploy yalnızca test job'ı başarılıysa çalışır ve if koşuluyla sadece main branch'ine push'ta tetiklenir:

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SSH ile sunucuda deploy
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT }}
          script: |
            cd ~/app
            git pull origin main
            composer install --no-dev -o
            php artisan migrate --force
            php artisan optimize

Burada deploy stratejisi basit bir "sunucuya bağlan, çek, güncelle" akışı. Docker kullanıyorsan bunun yerine imajı build edip bir registry'ye push edebilir (docker/build-push-action) ve sunucuda yeni imajı çekebilirsin. Önemli olan ilke aynı: yapılandırma kodda, sırlar secret'larda.

Pipeline'ı sağlamlaştırmak için ipuçları

• Hızlı başarısızlık: Lint ve testi deploy'dan önce ayrı job'lar yap; kırmızı bir test deploy'u tamamen engellesin.
• Cache kullan: Bağımlılık ve build cache'i pipeline süresini dakikalardan saniyelere indirir.
• Action'ları sürümle: @v4 gibi sabit major sürümlere bağlan; en hassas projelerde commit SHA'sına sabitle.
• Concurrency: concurrency bloğuyla aynı branch'in eski çalışmalarını iptal et, gereksiz deploy'ları engelle.
• Görünürlük: README'ye bir status badge ekle; pipeline'ın yeşil mi kırmızı mı olduğu bir bakışta görünsün.

Sık Sorulan Sorular

GitHub Actions ücretsiz mi?

Public repository'lerde standart runner'lar ücretsizdir. Private repository'lerde ücretsiz bir aylık dakika kotası vardır; bu kota aşıldığında dakika başına ücretlendirme başlar. Çoğu küçük ve orta ölçekli proje ücretsiz kotanın içinde rahatça kalır.

Jenkins veya GitLab CI yerine neden GitHub Actions?

Kodun zaten GitHub'daysa Actions, repon'la aynı yerde yaşadığı için sıfır altyapı kurulumuyla başlar. Jenkins daha fazla kontrol ve eklenti sunar ama bir sunucu işletmeni gerektirir. Karar, ekibin nerede çalıştığına ve ne kadar özelleştirme istediğine bağlıdır.

Deploy başarısız olursa ne olur?

Job kırmızıya döner, sonraki adımlar çalışmaz ve GitHub sana bildirim gönderir. Loglardan tam komutu ve hata çıktısını görürsün. Güvenli deploy için migration'ları geri alınabilir tasarla ve mümkünse mavi-yeşil ya da rolling deploy stratejisi kullan.

Pipeline'ını kurmak ya da mevcut deploy akışını otomatikleştirmek mi istiyorsun? Projeni hızlı, güvenli ve tekrarlanabilir bir CI/CD hattına taşımana yardımcı olabilirim — benimle iletişime geç.