GitHub Actions ile Ücretsiz CI/CD Kurulumu: 2026 Pratik Rehberi

Kodu yazmak işin yarısı. Diğer yarısı: o kodun her commit'te otomatik test edilmesi, derlenmesi ve canlıya çıkması. 2026'da bunu kurmanın en kolay ve en ucuz yolu hâlâ GitHub Actions. Public repo'larda sınırsız, private repo'larda ise aylık cömert bir ücretsiz dakika kotasıyla geliyor. Bu rehberde sıfırdan çalışan bir CI/CD hattı kuracağız.

CI/CD Nedir, Neden Önemli?

CI (Continuous Integration / Sürekli Entegrasyon), her kod değişikliğinin otomatik olarak test ve build sürecinden geçmesidir. Amaç: bozuk kodun main branch'ine sızmasını engellemek.

CD (Continuous Delivery/Deployment / Sürekli Teslimat) ise testten geçen kodun otomatik olarak staging veya production ortamına gönderilmesidir.

Bunu elle yapmanın bedeli ağırdır:

• "Bende çalışıyordu" tartışmaları
• Unutulan test adımları yüzünden gelen production hataları
• Saatlerce süren manuel deploy ritüelleri

Otomasyon bu üç sorunu da ortadan kaldırır. Her push, sizin yerinize çalışan tutarlı bir robottur.

Workflow YAML Anatomisi

GitHub Actions, repo'nuzdaki .github/workflows/ klasöründe duran YAML dosyalarıyla çalışır. Bir workflow'un üç temel bileşeni vardır:

• Triggers (on) — Workflow'u ne tetikler? Push, pull request, zamanlanmış cron veya manuel buton.
• Jobs — Paralel veya sıralı çalışan iş birimleri. Her job ayrı bir sanal makinede koşar.
• Steps — Bir job içindeki adımlar. Ya bir kabuk komutu (run) ya da hazır bir eylem (uses).

İskeleti şöyle görünür:

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Merhaba CI"

YAML'ın girinti duyarlılığı en çok hata yapılan noktadır. Bir dosyanın geçerli olup olmadığından emin değilseniz, YAML → JSON Dönüştürücü ile yapısını anında doğrulayabilirsiniz; JSON'a sorunsuz çevriliyorsa söz dizimi sağlamdır.

Gerçek Bir Örnek: Test + Build + Deploy

Aşağıda bir Node.js projesi için tam bir hat var. Test geçerse build alıyor, build başarılıysa deploy ediyor.

name: CI/CD Pipeline
on:
  push:
    branches: [main]

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

  build:
    needs: 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 run build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Dikkat edin: needs anahtarı job'ları zincirler. build sadece test geçtikten sonra, deploy da sadece build bittikten sonra çalışır. Bir adım kırmızı olursa zincir orada durur ve production'a hiçbir şey gitmez.

YAML'ı elle yazmaktan çekiniyorsanız, GitHub Actions Workflow Oluşturucu ile birkaç tıkla başlangıç dosyanızı üretebilirsiniz.

Cache ile Hız, Secrets ile Güvenlik

Bağımlılıkları Cache'leyin

Her çalıştırmada npm install'un sıfırdan paket indirmesi dakikalarınızı yer. setup-node action'ındaki cache: 'npm' satırı, bağımlılıkları runner'lar arasında saklar ve sonraki koşuları belirgin biçimde hızlandırır. Daha ince kontrol için actions/cache@v4'ü doğrudan kullanabilirsiniz:

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}

key içindeki hash sayesinde lock dosyası değişmedikçe cache yeniden kullanılır.

Secrets'ı Asla Koda Gömmeyin

API anahtarları, deploy token'ları ve şifreler asla repo'da düz metin olarak durmamalı. Bunları repo ayarlarındaki Settings → Secrets and variables → Actions bölümüne ekleyin ve workflow'da ${{ secrets.ISIM }} ile çağırın. GitHub bu değerleri loglarda otomatik olarak maskeler.

Matrix Build: Tek Workflow, Çok Ortam

Kodunuzu birden çok dil sürümünde veya işletim sisteminde test etmek istiyorsanız, her biri için ayrı job yazmanıza gerek yok. Matrix stratejisi kombinasyonları sizin yerinize üretir:

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

Bu örnek 2 işletim sistemi × 3 Node sürümü = 6 paralel job üretir. Kütüphane geliştiriyorsanız uyumluluk güvencesi için paha biçilmezdir.

Docker ile Deploy

Container tabanlı dağıtım yapıyorsanız, workflow içinde imaj build edip registry'ye push edebilirsiniz. Önce sağlam bir Dockerfile'a ihtiyacınız var — Dockerfile Oluşturucu ile dile özel, optimize edilmiş bir taslak çıkarabilirsiniz. Çok servisli yerel ortamlar için ise Docker Compose Oluşturucu işinizi görür.

Sık Yapılan Hatalar

• Eski action sürümleri. @v3 veya daha eskisini kullanmak deprecation uyarıları ve Node sürüm hatalarına yol açar. 2026'da @v4 (ve üzeri) tercih edin.
• Cache'siz koşular. Bağımlılık cache'i olmadan dakikalarınız ve kotanız boşa gider.
• Çok geniş tetikleyiciler. Her branch'i deploy etmek istemezsiniz; branches: [main] ile sınırlayın.
• Gizli bilgiyi loglamak. echo $TOKEN yazmayın; maskeleme her zaman kurtarmaz.
• .gitignore eksikliği. node_modules veya build çıktıları yanlışlıkla commit'lenirse cache ve build mantığı bozulur. Temiz bir başlangıç için .gitignore Oluşturucu kullanın.

Daha fazla container ve otomasyon aracı için DevOps araçları kategorisine göz atabilirsiniz.

Özet

GitHub Actions ile yarım saatte çalışan, ücretsiz bir CI/CD hattı kurabilirsiniz: tetikleyiciyi tanımlayın, test–build–deploy job'larını needs ile zincirleyin, cache ekleyin, secrets'ı güvene alın. Sonrası otomatik. Bir kez kurun, her commit'te kazanın.

MagmaNex'teki tüm araçlar tamamen tarayıcınızda çalışır — hiçbir dosya veya veri sunucuya yüklenmez.