Manuel deployment sürecinden GitHub Actions ile otomatikleştirilmiş bir CI/CD sürecine geçtiğimden beri, hem hata oranım düştü hem de yayına alma süreci çok daha az stresli hale geldi.

Basit Bir .NET Pipeline'ı

name: build-and-test
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      - run: dotnet restore
      - run: dotnet build --no-restore
      - run: dotnet test --no-build

Her push'ta otomatik olarak build ve testlerin çalışması, bir hatayı ana dala (main) ulaşmadan önce yakalıyor.

Branch Koruma Kurallarıyla Birleştirmek

Pipeline'ın sadece çalışması yetmiyor; GitHub'da branch protection kuralları ile "testler geçmeden merge edilemez" kuralını zorunlu kılıyorum. Aksi halde pipeline sadece bilgilendirici kalıyor, gerçek bir güvenlik ağı olmuyor.

Ortama Göre Ayrı Deployment Adımları

Staging ve production için ayrı workflow'lar tanımlıyorum; production'a deployment'ı genelde manuel bir onay adımıyla (GitHub Environments özelliği) tetikliyorum, böylece her push otomatik olarak canlıya çıkmıyor.

Secrets Yönetimi

Bağlantı dizeleri ve API anahtarlarını asla workflow dosyasına gömmüyorum; GitHub Secrets üzerinden ortam değişkeni olarak enjekte ediyorum. Bu, hassas bilgilerin repo geçmişinde asla görünmemesini garanti ediyor.

Sonuç

GitHub Actions ile kurulan bir CI/CD pipeline'ı, küçük bir başlangıç yatırımıyla, insan hatasından kaynaklanan deployment sorunlarını büyük ölçüde ortadan kaldırıyor. Basit bir build/test pipeline'ı bile, hiç otomasyon olmamasına göre büyük bir adım.