GitHub Actions ile CI/CD Test Borularını Nasıl Kurarsınız? Adım Adım Rehber

CI/CD (Continuous Integration/Continuous Deployment) araçları, yazılım projelerinde kod değişikliklerinin otomatik olarak test edilmesini ve onaylanmasını sağlayarak geliştirme sürecini hızlandırır. Ancak bu araçlar arasında seçim yaparken dikkate alınması gereken birçok farklı faktör bulunur: testlerin nerede ve nasıl çalıştırılacağı, kurulum karmaşıklığı ve ek operasyonel maliyetler bunların başında gelir. Bu makalede, GitHub Actions'ı kullanarak basit bir test borusu oluşturmayı ve diğer popüler CI/CD araçlarıyla karşılaştırmayı öğreneceksiniz.

CI/CD Araçları Neden Önemli?

Her CI/CD platformunun temel amacı aynıdır: her kod değişikliğinden sonra otomatik olarak testleri çalıştırmak, böylece hataların erken tespit edilmesini sağlamak. Ancak platformlar arasındaki farklar, testlerin nerede ve nasıl yürütüldüğünde, konfigürasyon esnekliğinde ve operasyonel yükünde ortaya çıkar. Bu makalede, GitHub Actions'ı adım adım kurmayı ve alternatif araçlarla karşılaştırmayı ele alacağız.

GitHub Actions Nedir?

GitHub Actions, GitHub'ın yerleşik CI/CD platformudur. Geliştiriciler, test borularını doğrudan .github/workflows/ klasöründe YAML dosyaları olarak tanımlayabilir ve bu boruları GitHub olaylarına (push, pull request, zamanlanmış çalıştırma) bağlı olarak otomatik olarak tetikleyebilir. GitHub, bu boruları kendi barındırılan runner'larında çalıştırır ve böylece ek bir sunucu kurulumuna ihtiyaç kalmaz. Bu yaklaşım, özellikle GitHub'da barındırılan projeler için büyük bir avantaj sağlar.

Bu makale için oluşturulan örnek depo: github.com/mary010-sky/github-actions-ci-demo

Gerçek Bir Test Borusunun Kurulumu

Aşağıda, bir Node.js kütüphanesi için Jest test takımını çalıştıran bir GitHub Actions borusunun nasıl oluşturulduğunu göreceksiniz. Bu boru, her push ve pull request işleminden sonra tetiklenir ve farklı Node.js sürümlerinde testlerin çalıştırılmasını sağlar.

# .github/workflows/test.yml
name: Run Tests

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

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run test suite
        run: npm test -- --coverage

      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

Bu borunun bazı önemli özellikleri şunlardır:

• strategy.matrix bloğu, aynı testi farklı Node.js sürümlerinde çalıştırır. Böylece eski Node.js sürümlerinde ortaya çıkabilecek hataları erkenden yakalayabilirsiniz.

• cache: 'npm' ayarı, node_modules klasörünü önbelleğe alarak kurulum sürelerini önemli ölçüde azaltır. Gerçek bir projede, bu özellik sayesinde çok dakikalar süren kurulumlar saniyelere indirilebilir.

• Test kapsam raporu, GitHub Actions arayüzünden doğrudan indirilebilen bir yapı parçası olarak kaydedilir. Bu sayede ek bir depolama hizmetine ihtiyaç duyulmaz.

Birleştirmeyi Engelleyen Durum Kontrolleri Nasıl Eklenir?

Testlerin başarısız olması durumunda kod birleştirmesini otomatik olarak engellemek, projelerinizin kalitesini korumak için kritik öneme sahiptir. Aşağıda, test kapsamının belirli bir eşik değerin altında kalması durumunda boruyu başarısız hale getiren bir durumu nasıl ekleyeceğinizi görüyorsunuz:

# .github/workflows/test.yml (ek) (jobs bölümünde yer alır)
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      # ...yukarıdaki adımlar aynı...
      
      - name: Fail if coverage drops below threshold
        run: |
          COVERAGE=$(node -e "console.log(require('./coverage/coverage-summary.json').total.lines.pct)")
          echo "Line coverage: $COVERAGE%"
          if (( $(echo "$COVERAGE < 80" | bc -l) )); then
            echo "Coverage below 80% threshold"
            exit 1
          fi

Bu boru, dal koruma kurallarında gerekli durumu olarak ayarlandığında, pull request'lerin testler başarısız olsa veya kapsam eşiğinin altına düşse bile birleştirilemesini engeller. Bu denetim, ayrı bir politika aracılığıyla değil, doğrudan GitHub tarafından uygulanır.

Diğer CI/CD Araçlarıyla Karşılaştırma

GitHub Actions vs. GitLab Pipelines

Her iki platform da depo içindeki YAML dosyalarıyla tanımlanan CI/CD borularına sahiptir ve barındırılan runner'lar sunar. Ana fark, ekosistemlerinde yatar: GitHub Actions, geniş bir üçüncü parti eylem pazarına sahipken, GitLab Pipelines, GitLab'ın sorun takibi, konteyner kayıt defteri ve Auto DevOps şablonlarıyla derin bir entegrasyona sahiptir. GitLab'a bağlı olan ekipler genellikle daha az ek yapılandırmayla çalışabilirken, GitHub kullanıcıları daha fazla üçüncü parti eylemi kullanabilir.

GitHub Actions vs. Jenkins

Jenkins, 2.000'den fazla eklentiyle neredeyse sonsuz esneklik sunar, ancak bu esneklik aynı zamanda ek yük anlamına gelir: Jenkins sunucusunu kurmak, güncellemek ve güvenliğini sağlamak geliştiricilerin sorumluluğundadır. GitHub Actions ise barındırılan runner'lar ve daha küçük, özenle seçilmiş bir eylem ekosistemiyle bu esnekliği değiştirir. Böylece altyapı yönetimi yükünden kurtulursunuz.

GitHub Actions vs. CircleCI

CircleCI, hızlı ve önbelleklenmiş paralel testler konusunda öncü olmuştur ve boru adımlarını görselleştirme yeteneğiyle hala tercih edilen bir arayüze sahiptir. GitHub Actions, performans farkını büyük ölçüde kapatmıştır ve GitHub'da barındırılan projeler için avantaj sağlar: ayrı bir hesap, faturalandırma ilişkisi veya web kancası kurulumuna gerek yoktur.

GitHub Actions vs. Travis CI

Travis CI, YAML tabanlı ve barındırılan runner'lar sunan ilk CI/CD araçlarından biriydi ve birçok projeyi bu modele geçirdi. Ancak GitHub Actions'ın ortaya çıkmasıyla birlikte Travis CI'nin popülaritesi hızla azaldı. GitHub'ın yerleşik entegrasyonu ve daha geniş runner havuzu, Travis CI'nin avantajlarını geride bıraktı ve birçok proje Travis CI'den GitHub Actions'a geçti.

GitHub Actions'ın Sınırları

Büyük ölçekli kurumsal projelerde, Harness veya TeamCity gibi araçlar, GitHub Actions'ın yerleşik olarak sunmadığı daha fazla denetim ve dağıtım stratejisi araçlarına sahiptir. Örneğin, canary dağıtımları veya özellik bayraklarına dayalı yayınlar, bu araçlarla daha kolay yönetilebilir. Ayrıca, ücretsiz katmanda barındırılan runner dakikaları sınırlıdır ve büyük matris boruları sık sık çalıştıran projeler için bu kısıt önemli hale gelebilir.

Sonuç: GitHub Actions Sizin İçin Uygun mu?

GitHub Actions, özellikle GitHub'da barındırılan projeler için en mantıklı seçimdir. Ayrı bir CI sunucusuna, ek hesaplara veya karmaşık web kancası kurulumlarına ihtiyaç duymadan, borularınızı kodla birlikte depolayabilirsiniz. Kurulum maliyeti neredeyse sıfırdır: YAML dosyasını yazın, gönderin ve boru hazır olsun.

Ancak Jenkins'in sunduğu kadar geniş eylem ekosisteminden yoksun olması veya Harness'in sunduğu kadar gelişmiş dağıtım denetimlerine sahip olmaması, büyümekte olan çoğu ekip için henüz bir sorun teşkil etmemektedir. GitHub Actions, şu anda ve yakın gelecekte birçok proje için varsayılan CI/CD çözümü olarak konumunu koruyacaktır.