Bölüm 10 — Konu 46: CI/CD

Konu 45'te testler yazmayı öğrendik — ama testler, sadece senin bilgisayarında elle çalıştırdığında faydalıdır, kimse her zaman hatırlayıp çalıştırmaz. Bu ders, testleri (ve build sürecini) otomatikleştirmeyi — yani her kod değişikliğinde kendiliğinden çalışmasını sağlamayı öğretiyor.

#CI/CD Nedir? İki Kavramı Ayıralım

CI (Continuous Integration — Sürekli Entegrasyon): Kod her push edildiğinde ya da bir pull request açıldığında, otomatik olarak testlerin çalıştırılması ve kodun derlenebilir olduğunun doğrulanması. Amaç: "bu değişiklik, projeyi bozmuyor" garantisini insan hatırlamadan almak.

CD (Continuous Deployment/Delivery — Sürekli Dağıtım): CI başarılı olduktan sonra, uygulamanın otomatik olarak bir test ortamına, ya da Bölüm 11'de göreceğimiz gibi doğrudan Play Store/App Store'a dağıtılması.

Analoji: CI, Bölüm 10 Konu 45'teki testlerin "her zaman, kendiliğinden çalışan" versiyonu; CD ise Bölüm 9 Konu 44'teki build/imzalama sürecinin "her zaman, kendiliğinden çalışan" versiyonu. CI/CD, yeni bir kavram değil — önceki iki dersin otomatikleştirilmesidir.

#Neden Otomatikleştiresin?

• İnsan unutur, makine unutmaz. "Testleri çalıştırmayı unuttum, push ettim, ana branch bozuldu" — CI, bunu imkansız hale getirir (testler geçmezse, değişiklik birleştirilemez).
• Takım büyüdükçe kritikleşir. Bölüm 7'de öğrendiğimiz Dependency Inversion gibi — tek başına çalışırken "disiplin" yeterliyken, birden fazla kişi aynı kod tabanına dokunduğunda, otomatik bir kapı bekçisi gerekir.
• Hızlı geri bildirim. Bir hata, senin bilgisayarında saatler sonra fark edilmek yerine, push ettikten dakikalar sonra raporlanır.

#GitHub Actions ile Basit Bir CI Pipeline'ı

# .github/workflows/flutter-ci.yml
name: Flutter CI

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4          # kodu indir

      - uses: subosito/flutter-action@v2   # Flutter SDK'yı kur
        with:
          flutter-version: '3.24.0'
          channel: 'stable'

      - run: flutter pub get               # bağımlılıkları indir

      - run: flutter analyze                # statik kod analizi (birazdan detaylandıracağız)

      - run: flutter test                   # Bölüm 10 Konu 45'teki tüm unit/widget testleri

Parça parça inceleyelim:

on: push / pull_request — bu pipeline'ın ne zaman tetikleneceğini belirtir; burada, main branch'ine her push'ta ve her pull request'te çalışacak.

runs-on: ubuntu-latest — GitHub, senin için geçici, temiz bir sanal makine ayağa kaldırır — Bölüm 9'da öğrendiğimiz kendi bilgisayarındaki geliştirme ortamından bağımsız, her seferinde sıfırdan, aynı bir ortam.

steps: — Dart Bölüm 4'te öğrendiğimiz List yapısına benzer, sırayla çalışacak komutların listesi. Her adım başarısız olursa, pipeline durur ve "failed" olarak işaretlenir.

flutter analyze — Bölüm 10'un ileride (Konu 47-48) daha derin işleyeceğimiz statik analiz aracı; kodun çalıştırılmadan, sadece okunarak (potansiyel hatalar, stil sorunları, kullanılmayan değişkenler gibi) taranmasıdır — flutter test'ten önce çalıştırmak, hızlı ve ucuz bir ilk filtre sağlar.

#pull_request Tetikleyicisinin Gücü — "Kapı Bekçisi" Rolü

GitHub'da (ve benzer platformlarda), bir repository'nin ayarlarından, CI geçmeden bir PR'ın birleştirilemeyeceğini ("required status check") zorunlu kılabilirsin. Bu, CI'ın asıl gücünü ortaya koyar — artık "testleri çalıştırmayı unuttum" diye bir kod ana branch'e giremez, çünkü GitHub, CI kırmızı (başarısız) olduğu sürece "Merge" butonunu devre dışı bırakır.

#Matrix Build — Birden Fazla Ortamda Test Etme

jobs:
  test:
    strategy:
      matrix:
        flutter-version: ['3.22.0', '3.24.0']
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: ${{ matrix.flutter-version }}
      - run: flutter test

strategy: matrix, Dart Bölüm 9'da öğrendiğimiz generic kavramına biraz benzer bir fikir taşır — aynı pipeline'ı, farklı parametrelerle (burada farklı Flutter sürümleriyle) paralel olarak birden fazla kez çalıştırır. Bir kütüphane/paket geliştiriyorsan (Bölüm 12 Konu 58'i hatırla), kullanıcılarının farklı Flutter sürümlerinde de çalıştığından emin olmak için değerlidir.

#Önbellekleme (Caching) — Hızı Artırma

- uses: actions/cache@v4
  with:
    path: |
      ~/.pub-cache
      **/.dart_tool
    key: ${{ runner.os }}-pub-${{ hashFiles('**/pubspec.lock') }}

Her pipeline çalıştığında sıfırdan tüm paketleri (Bölüm 1'de öğrendiğimiz pubspec.yaml bağımlılıkları) indirmek zaman kaybıdır. actions/cache, pubspec.lock değişmediği sürece, önceki çalıştırmadan indirilen paketleri yeniden kullanır — bu, büyük projelerde CI süresini dakikalarca kısaltabilir.

#Mobil Build'e Özgü Bir Zorluk — iOS için macOS Gerekir

Bölüm 9 Konu 44'te öğrendiğimiz gibi, iOS build'i Xcode gerektirir, ve Xcode sadece macOS'ta çalışır. Bu, CI ortamı için önemli bir kısıtlama getirir:

jobs:
  build-ios:
    runs-on: macos-latest  # Android'den FARKLI olarak, macOS runner ZORUNLU
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
      - run: flutter build ios --release --no-codesign

runs-on: macos-latest — GitHub Actions'ın macOS sanal makineleri mevcuttur ama Linux/Windows makinelere göre daha yavaş ve daha pahalıdır (kullanım kotası daha hızlı tükenir). Bu yüzden pratikte, çoğu takım unit/widget testleri ucuz Linux runner'larda, sadece gerçek iOS build/dağıtımını macOS runner'da çalıştırır.

#Codemagic / Fastlane — Mobil-Özel CI/CD Araçları

GitHub Actions genel amaçlıdır (herhangi bir dil/proje için) — mobil geliştirmeye özel olarak tasarlanmış araçlar da var:

• Codemagic: Flutter'a özel, imzalama sertifikalarını/provisioning profillerini yöneten arayüzü olan, sıfır-konfigürasyona yakın bir CI/CD servisi. Bölüm 9 Konu 44'te gördüğümüz "imzalama karmaşıklığını" büyük ölçüde basitleştirir.
• Fastlane: Ruby tabanlı, Android/iOS build + imzalama + mağazaya otomatik yükleme (Bölüm 11 Konu 53) adımlarını script'leyen bir araç — GitHub Actions'ın içinde bir adım olarak da çağrılabilir.

Pratik tavsiye: Küçük/orta projelerde GitHub Actions (test + analyze için) + Codemagic (mobil build/dağıtım için) kombinasyonu yaygındır; büyük/kurumsal takımlarda Fastlane, tüm süreci tek bir script altında birleştirmek için tercih edilir.

#Basit Bir Zihinsel Model — CI Pipeline'ının Aşamaları

push/PR → checkout → Flutter kur → pub get → analyze → test → (opsiyonel) build → (opsiyonel) dağıt

Her aşama, bir öncekinin başarılı olmasına bağlıdır — bu, Dart Bölüm 5'te öğrendiğimiz sıralı await zinciri mantığına (bir işlem bitmeden diğeri başlamaz) kavramsal olarak benzer.

#🎯 Bu Dersten Çıkarılması Gerekenler

• CI, her push/PR'da testlerin otomatik çalışmasıdır; CD, CI başarılı olduktan sonra otomatik dağıtımdır — ikisi de, Konu 45'teki test yazımı ve Konu 44'teki build sürecinin otomatikleştirilmiş halidir.
• GitHub Actions'ta bir workflow, on: (ne zaman tetiklenir) ve steps: (sırayla çalışacak komutlar) ile tanımlanır.
• pull_request tetikleyicisi + "required status check" ayarı, CI'ı gerçek bir kapı bekçisine dönüştürür.
• strategy: matrix, aynı pipeline'ı birden fazla ortamda (örn. farklı Flutter sürümleri) paralel test etmeyi sağlar.
• Önbellekleme (actions/cache), her çalıştırmada paketlerin sıfırdan indirilmesini önleyerek CI süresini kısaltır.
• iOS build'i macOS runner gerektirir (daha yavaş/pahalı); Codemagic/Fastlane, mobil-özel imzalama/dağıtım karmaşıklığını basitleştiren araçlardır.

#📝 Ödevler

• [ ] GitHub Actions ile, her push'ta flutter analyze + flutter test çalıştıran basit bir workflow kur (bu dersteki temel örneği kullanabilirsin).
• [ ] Repository ayarlarından, bu CI check'ini main branch için zorunlu hale getir, testi bilerek bozup bir PR'ın birleştirilemediğini gözlemle.
• [ ] actions/cache ekleyerek, pipeline süresinin (cache'li ve cache'siz çalıştırma arasında) ne kadar değiştiğini ölç.
• [ ] Kendi cümlelerinle, "neden iOS build'inin CI'da macOS runner gerektirdiğini", Bölüm 9 Konu 44'teki Xcode bilgisiyle ilişkilendirerek açıkla.

Sıradaki konu: Bölüm 10 — Konu 47: Rebuild Optimizasyonu (const, key Kullanımı)