GitHub Actions ile CI/CD Pipeline Kurulumu: Adım Adım Rehber

Sürekli entegrasyon ve sürekli teslimat (CI/CD), modern yazılım geliştirmenin kalbinde yer alıyor. Kodunuzu ana dal ile birleştirdiğinizde ya da bir pull request açtığınızda, testlerin otomatik koşması, build işleminin tamamlanması ve hatta doğrudan production ortamına deploy yapılması… İşte tüm bu zincirleme süreci, GitHub Actions ile sıfırdan kurabilirsiniz. Bu rehberde, GitHub Actions CI/CD pipeline kurulumu konusunu en temel kavramlardan başlayarak, çalışan bir örnek üzerinden adım adım ele alacağız.

GitHub Actions Nedir ve Neden Kullanmalısınız?

GitHub Actions, GitHub tarafından sunulan ve doğrudan repository'nizle entegre çalışan ücretsiz bir CI/CD hizmetidir. Public repository'ler için tamamen ücretsiz olan bu servis, private repository'lerde ise aylık 2.000 dakikaya kadar ücretsiz kullanım imkânı tanır. Harici bir CI/CD aracına ihtiyaç duymadan, kodunuzla aynı yerde pipeline oluşturabilmeniz, geliştirici deneyimini önemli ölçüde iyileştirir.

2026 itibarıyla GitHub Marketplace'te 15.000'den fazla hazır action bulunuyor ve Linux, macOS, Windows runner'ları üzerinde çalıştırılabiliyor. Bu ekosistem, hemen her senaryoya uygun bir çözüm bulmanızı sağlar. Ayrıca self-hosted runner desteği sayesinde, kurumsal altyapınızda özel güvenlik ve performans gereksinimlerini de karşılayabilirsiniz.

GitHub Actions Temel Kavramlar

Pipeline yazmaya başlamadan önce, GitHub Actions'ın yapı taşlarını anlamak önemlidir. Bu kavramlar hiyerarşik bir ilişki içindedir:

  • Workflow: Tüm CI/CD sürecini tanımlayan en üst seviye yapılandırmadır. Bir veya daha fazla job içerir ve bir tetikleyici olayla başlar.
  • Job: Aynı runner üzerinde çalışan adımlar bütünüdür. Varsayılan olarak job'lar paralel çalışır, ancak needs anahtar kelimesiyle sıralı bağımlılık kurabilirsiniz.
  • Step: Bir job içinde çalıştırılan tekil komut veya action çağrısıdır. Shell komutu ya da hazır bir marketplace action'ı olabilir.
  • Action: Tekrar kullanılabilir kod parçalarıdır. Kendi action'larınızı yazabilir ya da topluluk tarafından geliştirilmiş olanları kullanabilirsiniz.
  • Runner: Workflow'unuzun çalıştığı sunucudur. GitHub tarafından sağlanan (ubuntu-latest, windows-latest gibi) runner'ları veya kendi self-hosted runner'larınızı kullanabilirsiniz.

Workflow dosyaları YAML formatında yazılır ve repository'nizin .github/workflows/ dizini altında saklanır.

İlk Workflow Dosyasını Oluşturma

Hemen bir örnekle başlayalım. Repository'nizde .github/workflows/ci.yml dosyası oluşturarak en basit haliyle bir workflow tanımlayabilirsiniz:

name: CI Pipeline

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:

      - uses: actions/checkout@v4
      - name: Bağımlılıkları Yükle
        run: npm ci
      - name: Testleri Çalıştır
        run: npm test

Bu workflow, main dalına push yapıldığında veya main dalına yönelik bir pull request açıldığında tetiklenir. Ubuntu runner üzerinde kodu checkout eder, bağımlılıkları yükler ve testleri çalıştırır. İşte ilk CI pipeline'ınız çalışıyor!

Tetikleyiciler: Workflow Ne Zaman Çalışsın?

Workflow'unuzu hangi olayların tetikleyeceğini on anahtarıyla belirlersiniz. En sık kullanılan tetikleyiciler:

  • push: Belirtilen dallara kod gönderildiğinde
  • pull_request: Yeni bir PR açıldığında veya mevcut PR güncellendiğinde
  • schedule: Cron tabanlı zamanlanmış çalıştırma için
  • workflow_dispatch: Manuel olarak tetiklemek için (GitHub UI üzerinden)
  • workflow_call: Başka bir workflow'dan çağrılabilir hale getirmek için

Tetikleyicilere filtre ekleyerek çalışma koşullarını daraltabilirsiniz. Örneğin, sadece belirli dosya yollarındaki değişikliklerde tetiklemek gibi.

Test Otomasyonu: Matrix Stratejisi ile Çoklu Ortam Testleri

Uygulamanızın farklı Node.js veya Python sürümlerinde sorunsuz çalıştığından emin olmak ister misiniz? Matrix stratejisi tam olarak bunu sağlar. Tek bir job tanımıyla 256'ya kadar farklı işletim sistemi ve dil sürümü kombinasyonunda paralel test koşabilirsiniz.

test:
  runs-on: ubuntu-latest
  strategy:
    matrix:
      node-version: [16.x, 18.x, 20.x]
      os: [ubuntu-latest, windows-latest]
  steps:

    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test

Bu yapılandırma, üç farklı Node.js sürümü ve iki işletim sistemi için toplam altı paralel test işi başlatır. Herhangi bir kombinasyonda hata alırsanız, hangi spesifik ortamda sorun olduğunu anında görürsünüz. Bu, GitHub Actions CI/CD pipeline kurulumu sürecinde test güvenilirliğini katlayan en değerli özelliklerden biridir.

Build ve Containerization: Docker Entegrasyonu

Testler başarıyla geçtikten sonra sıra uygulamanızı paketlemeye gelir. GitHub Actions, Docker ile kusursuz bir entegrasyona sahiptir ve doğrudan runner üzerinde imaj oluşturup registry'e push edebilirsiniz.

build:
  needs: test
  runs-on: ubuntu-latest
  if: github.ref == 'refs/heads/main'
  steps:

    - uses: actions/checkout@v4
    - name: Docker imajı oluştur
      run: docker build -t signalique/app:${{ github.sha }} .
    - name: Docker Hub'a push et
      run: |
        echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin
        docker push signalique/app:${{ github.sha }}

Burada needs: test ifadesi, build job'unun ancak test job'u başarılı olduğunda çalışmasını sağlar. if koşulu ise sadece main dalında çalıştığından emin olur. İmaj etiketi olarak github.sha (commit hash'i) kullanmak, her build'in benzersiz ve izlenebilir olmasını garantiler.

Secret Yönetimi: Hassas Bilgileri Güvende Tutun

API anahtarları, veritabanı bağlantı dizeleri, SSH anahtarları gibi hassas bilgileri asla workflow dosyalarınıza düz metin olarak yazmamalısınız. GitHub Secrets, bu bilgileri güvenli bir şekilde saklar ve çalışma zamanında ortam değişkeni olarak kullanmanıza imkân tanır.

Secret eklemek için repository'nizin Settings → Secrets and variables → Actions menüsüne gidin ve değişkenlerinizi tanımlayın. Daha sonra workflow içinde şu şekilde kullanabilirsiniz:

env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}
  API_KEY: ${{ secrets.API_KEY }}

steps:

  - run: echo "Veritabanına bağlanılıyor..."
    env:
      DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

GitHub, secret değerlerini loglarda otomatik olarak gizler ve aynı değer fork edilmiş repository'lerden gelen PR'larda kullanılamaz. Bu, CI/CD pipeline'ınızın güvenliğini en baştan sağlamanın kritik bir adımıdır.

Otomatik Deploy: Production'a Geçiş

Pipeline'ın son adımı, başarılı build'i hedef ortama deploy etmektir. En yaygın iki yaklaşım SSH tabanlı sunucu deploy'u ve cloud platform entegrasyonlarıdır.

SSH ile Sunucuya Deploy:

deploy:
  needs: build
  runs-on: ubuntu-latest
  steps:

    - uses: appleboy/[email protected]
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USER }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          docker pull signalique/app:${{ github.sha }}
          cd /opt/app && docker-compose up -d

Cloud Platform Entegrasyonu (AWS örneği):

deploy:
  needs: build
  runs-on: ubuntu-latest
  steps:

    - uses: aws-actions/configure-aws-credentials@v4
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: eu-west-1
    - run: aws eks update-kubeconfig --name production-cluster
    - run: kubectl set image deployment/app app=signalique/app:${{ github.sha }}

Her iki yöntem de tamamen otomatik çalışır ve manuel müdahale ihtiyacını ortadan kaldırır. DevOps kültürü hakkındaki yazımızda da belirttiğimiz gibi, bu tür otomasyonlar ekiplerin hızını ve güvenilirliğini katlanarak artırır.

En İyi Uygulamalar

Temel kurulumu tamamladığınıza göre, pipeline'ınızı daha verimli ve güvenilir hale getirecek birkaç pratik öneriye göz atalım:

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

Her çalıştırmada bağımlılıkları yeniden indirmek zaman kaybıdır. Cache action'ı ile node_modules veya pip cache'ini saklayabilirsiniz:


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

2. Job'ları İzole Tutun

Her job'ı tek bir sorumluluğa odaklayın: test ayrı, build ayrı, deploy ayrı olsun. Bu, hata durumunda sorunun kaynağını hızlıca bulmanızı sağlar.

3. Hata Yönetimi ve Bildirimler

Başarısız pipeline'lar için Slack veya email bildirimleri ekleyin. if: failure() koşuluyla sadece hata durumunda çalışacak bir job tanımlayabilirsiniz.

4. Environment Koruması

Production ortamı için environment anahtarını kullanarak onay mekanizmaları ve koruma kuralları tanımlayın. Bu, yanlışlıkla deploy'ların önüne geçer.

Daha ileri seviye otomasyonlar için kendi kendini onaran altyapı rehberimize de göz atabilirsiniz.

Sonuç

GitHub Actions, modern yazılım geliştirme sürecinin vazgeçilmez bir parçası haline geldi. Bu rehberde ele aldığımız GitHub Actions CI/CD pipeline kurulumu adımlarıyla, kod gönderdiğiniz andan itibaren test edilen, build alınan ve production'a deploy edilen tam otomatik bir akışa sahip olabilirsiniz. Başlangıçta basit bir test workflow'u ile başlayıp, ihtiyaçlarınız büyüdükçe matrix testler, Docker entegrasyonu ve otomatik deploy adımlarını ekleyebilirsiniz.

Resmi dokümantasyonu (GitHub Actions Workflow Yapısı, CI/CD En İyi Uygulamaları) inceleyerek bilginizi derinleştirebilir, Marketplace'teki binlerce hazır action ile pipeline'ınızı daha da zenginleştirebilirsiniz.