Mert Özen Her Satırda Daha İleri
Backend .NET Core Web API — #29

CI/CD ile deploy: GitHub Actions ile test, derleme ve dağıtımı otomatikleştirmek

Mert Özen 23 Ağu 2026 13 dk 22 görüntülenme
CI/CD ile deploy: GitHub Actions ile test, derleme ve dağıtımı otomatikleştirmek

CI/CD'yi işliyoruz: sürekli entegrasyon ve sürekli dağıtım ne demek, neden otomatik pipeline gerekli, GitHub Actions ile bir workflow kurmak ve her kod değişikliğinde test-derleme-dağıtımı otomatik çalıştırmak.

Önceki yazıda uygulamayı Docker'a alıp taşınabilir bir pakete koyduk. Ama bu adımları hâlâ elle yapıyoruz: kodu değiştir, testleri çalıştır, imajı oluştur, sunucuya taşı. Her seferinde bu döngüyü elle yürütmek hem yorucu hem de hataya açık. Bir adımı unutursun, yanlış bir sürüm gönderirsin. Bugün bu döngüyü otomatikleştiriyoruz: CI/CD ile, kodu her güncellediğinde her şey kendiliğinden çalışsın.

CI/CD Nedir?

İki kısaltmayı açalım. CI, "Continuous Integration" yani sürekli entegrasyon demek. Fikri şu: her kod değişikliğini otomatik olarak derleyip test etmek. Böylece bir şeyi bozduğunda anında haber alırsın, günler sonra değil. CD ise "Continuous Deployment" (ya da Delivery), yani sürekli dağıtım. Bu da testlerden geçen kodun otomatik olarak dağıtıma hazırlanması, hatta doğrudan canlıya çıkarılmasıdır.

İkisi birlikte bir üretim bandı gibi çalışır. Bir fabrikada ham madde bir uçtan girer, banttan geçerken her istasyonda bir işlem görür (montaj, kontrol, paketleme) ve diğer uçtan bitmiş ürün çıkar. CI/CD de senin kodun için bu bandı kurar: kod bir uçtan girer, otomatik olarak test edilir, derlenir, paketlenir ve diğer uçtan dağıtıma hazır çıkar. İnsan eli her istasyona ayrı ayrı dokunmaz; bant kendi kendine akar.

Neden Otomatikleştirelim?

Elle yapılan her işlem, unutulmaya ve hataya açıktır. Bir gün testleri çalıştırmayı unutursun, bozuk kod canlıya çıkar. Başka bir gün yanlış bir dosyayı kopyalarsın. Üstelik bu adımlar sıkıcıdır ve sıkıcı işleri insanlar isteksizce, dolayısıyla dikkatsizce yapar. Otomasyon bu sorunların hepsini bir çırpıda çözer: makine yorulmaz, unutmaz, her seferinde aynı adımları aynı özenle uygular.

Bir başka önemli fayda da güven. CI/CD pipeline'ın varsa, her değişiklik otomatik olarak testlerden geçtiği için, koda dokunmaktan korkmazsın. Bir şeyi bozduğunda pipeline anında kırmızıya döner ve seni uyarır. Yirmi dördüncü yazıda testin bir güvenlik ağı olduğunu söylemiştik; CI/CD, o güvenlik ağını her değişiklikte otomatik olarak geren mekanizmadır.

GitHub Actions: Otomasyonun Aracı

Bu otomasyonu kurmak için bir araç gerekiyor ve en yaygınlarından biri GitHub Actions. Eğer kodun zaten GitHub'da duruyorsa, ekstra bir servise ihtiyacın yok; GitHub Actions doğrudan projenin içinde çalışır. Fikri basit: belirli olaylar (mesela kodu her gönderdiğinde) gerçekleştiğinde, senin tanımladığın adımları otomatik olarak çalıştırır.

GitHub Actions'a ne yapacağını bir workflow dosyasıyla anlatırsın. Bu dosya, projenin içinde özel bir klasörde (.github/workflows) durur ve YAML formatındadır. İçinde iki temel şey tanımlarsın: bu otomasyon ne zaman çalışacak ve çalışınca hangi adımları izleyecek.

İlk Workflow'u Yazmak

Basit bir workflow ile başlayalım. Amacımız: kod her gönderildiğinde, projeyi otomatik olarak derlemek ve testleri çalıştırmak. Yani CI kısmını kurmak. Dosya aşağı yukarı şöyle görünür:

name: CI

on:
  push:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: .NET kurulumu
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '9.0.x'

      - name: Bağımlılıkları yükle
        run: dotnet restore

      - name: Derle
        run: dotnet build --no-restore

      - name: Testleri çalıştır
        run: dotnet test --no-build

Dosyayı adım adım okuyalım. En üstteki on bölümü, bu workflow'un ne zaman çalışacağını söyler: main dalına her kod gönderildiğinde (push). Altındaki jobs bölümü ise yapılacak işi tanımlar. runs-on: ubuntu-latest, bu işin temiz bir Linux makinesinde çalışacağını belirtir; her seferinde sıfırdan, tertemiz bir ortam kurulur. steps ise sırayla izlenecek adımlar: önce kodu çek, sonra .NET'i kur, bağımlılıkları yükle, derle ve testleri çalıştır.

Pipeline Çalışınca Ne Oluyor?

Bu dosyayı projene ekleyip GitHub'a gönderdiğin an, sihir başlar. Bundan sonra main dalına her kod gönderdiğinde, GitHub Actions otomatik olarak devreye girer: temiz bir makine kurar, kodunu çeker, derler ve tüm testlerini çalıştırır. Sonucu da sana gösterir; her şey yolundaysa yeşil bir onay, bir şey bozulduysa kırmızı bir uyarı görürsün.

Bunun günlük hayattaki karşılığı şu: bir arkadaşınla aynı projede çalışıyorsunuz, o bir değişiklik gönderiyor ama farkında olmadan bir testi bozuyor. Eskiden bunu ancak sen kendi makinende fark ederdin, belki günler sonra. Şimdiyse pipeline anında kırmızıya dönüyor ve herkes bozulmayı o an görüyor. Bu, ekip çalışmasında paha biçilmez bir güvence.

CD: Dağıtımı da Eklemek

Buraya kadar CI kısmını, yani otomatik test ve derlemeyi kurduk. CD kısmı ise bir adım ötesi: testlerden geçen kodu otomatik olarak dağıtıma hazırlamak. Önceki yazıda öğrendiğimiz Docker tam burada devreye giriyor. Testler geçtikten sonra pipeline, uygulamanın Docker imajını otomatik olarak oluşturabilir ve bir imaj deposuna gönderebilir; oradan da hedef sunucuya ya da bulut ortamına dağıtabilir.

Yani tam bir CI/CD pipeline'ı şöyle akar: kodu gönderirsin, otomatik derlenir, testler çalışır, hepsi geçerse Docker imajı oluşturulur ve dağıtılır. Sen sadece kodu göndermişsindir; gerisi kendiliğinden olur. Dağıtım adımlarının detayı, hangi sunucuya ya da hangi bulut sağlayıcısına gittiğine göre değişir; ama temel fikir hep aynı: insan sadece kod yazar, tekrarlayan her şeyi makine yapar.

Küçük Bir Deneme

Projeni GitHub'a taşı (henüz orada değilse). Sonra projenin içinde .github/workflows klasörünü oluştur ve içine yukarıdaki gibi bir workflow dosyası ekle. Bu dosyayı GitHub'a gönder ve projenin "Actions" sekmesine git; pipeline'ının otomatik çalışmaya başladığını gör. Her adımın (kurulum, derleme, test) sırayla nasıl işlediğini izle. İstersen bir de bilerek bir testi boz, kodu gönder ve pipeline'ın nasıl kırmızıya döndüğünü, seni nasıl uyardığını gözlemle. Bu deney, otomasyonun soyut bir kavram olmaktan çıkıp her commit'inde çalışan somut bir güvenceye dönüşmesini sağlar.

Bir sonraki yazı serinin sonuncusu. Performans ve optimizasyon konusuna değinecek, öğrendiğimiz her şeyi bir araya getirecek ve bu uzun yolculuğu bir bütün olarak toparlayacağız. API'n artık yazılıyor, test ediliyor, paketleniyor ve otomatik dağıtılıyor; son yazıda onu daha da iyi hale getirmenin yollarına ve bundan sonra nereye gidebileceğine bakacağız.