CI/CD Pipeline — nedir, otomasyon aşamaları ve araçlar

CI/CD Pipeline Nedir

CI/CD Pipeline, kodun depoya değişiklik commit'inden üretime dağıtıma kadar geçtiği resmileştirilmiş ve otomatikleştirilmiş bir süreçler kümesidir. Terim iki uygulamayı birleştirir: Continuous Integration (sürekli entegrasyon) ve Continuous Delivery (sürekli teslimat), birlikte bir yazılım teslim hattı oluştururlar.

CI/CD Tarihi

Continuous Integration kavramı 1991'de Grady Booch tarafından tanımlanmış ve 2000'lerde Martin Fowler tarafından popülerleştirilmiştir. Continuous Delivery terimi, Jez Humble ve David Farley'in “Continuous Delivery” kitabından (2010) sonra yerleşmiştir. Modern CI/CD Pipeline, 2015'ten sonra bulut CI sunucularının ve uygulama mağazası otomasyonunun ortaya çıkmasıyla mobil geliştirmede fiili standart haline gelmiştir.

Mobil Geliştirmede CI/CD Pipeline Neden Gereklidir

Mobil uygulamaların derleme ve yayınlama konusunda belirli gereksinimleri vardır: sertifika imzalama, birden çok yapılandırma (debug, release, staging), ProGuard/R8 karartma, birden çok derleme türü (APK, AAB, IPA) ve uygulama mağazalarıyla entegrasyon. Bu adımların manuel olarak yürütülmesi saatler alır ve hataya açıktır — CI/CD Pipeline rutini otomatikleştirir.

Mobil Uygulamalar İçin CI/CD Pipeline Aşamaları

Android veya iOS uygulamaları için standart bir CI/CD Pipeline yedi ana aşamadan oluşur. Bazı aşamalar paralel, bazıları sıralı olarak çalışır. Aşamaların tam seti teknoloji yığınına ve ekip olgunluğuna bağlıdır, ancak çekirdek aynı kalır.

1. Checkout ve Bağımlılık Kurulumu

Pipeline, deponun kopyalanması ve bağımlılıkların kurulmasıyla başlar: Android için Gradle/Maven, iOS için CocoaPods veya SPM. Çalıştırmalar arasında bağımlılık önbellekleme, kurulum süresini 3–5 dakikadan birkaç saniyeye düşürür — tüm modern CI hizmetleri bu optimizasyonu destekler.

2. Statik Analiz ve Linting

Derlemeden önce kod, linter'lar (Android için ktlint, detekt, iOS için SwiftLint) ve statik analizörler (Android Lint, SonarQube) tarafından kontrol edilir. Linting, testler çalıştırılmadan önce potansiyel hataları, kod stili ihlallerini ve kullanımdan kaldırılmış API'leri tespit eder — fail-fast ilkesi ekip zamanı kazandırır.

3. Proje Derlemesi

Derleme aşamasında, tüm proje derlenir ve yapıtlar oluşturulur: Android için APK ve AAB, iOS için IPA. Android için Gradle görevleri (assembleDebug, bundleRelease) kullanılır, iOS için — xcodebuild veya xcrun. Derleme, CI sunucusunun izole edilmiş ortamında gerçekleştirilir ve tekrarlanabilirlik sağlanır.

# GitHub Actions'ta Android için CI/CD Pipeline örneği
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. Otomatik Test

Derlemeden sonra birim testleri, entegrasyon testleri ve UI testleri çalıştırılır. Birim testleri için JUnit ve MockK, Android UI için Espresso ve Compose Test, iOS için XCTest ve XCUITest. Sonuçlar bir raporda yayınlanır ve kritik testler başarısız olursa pipeline'ı bloke eder.

5. İmzalama ve Karartma

Sürüm derlemeleri için dijital sertifika imzalama (Android için APK Signer, iOS için codesign) ve kod karartma gerçekleştirilir. Android için ProGuard veya R8, APK boyutunu %15–30 oranında azaltır. İmzalama anahtarları CI sunucusunun sırlarında saklanır — depoya asla commit edilmez.

6. Teslimat ve Dağıtım

Pipeline'ın son aşaması yapıtların yayınlanmasıdır: Google Play Console dahili testine APK yükleme, TestFlight'a IPA gönderme veya Firebase Distribution'da yayınlama. Continuous Delivery bu adımın manuel onay gerektirdiği anlamına gelirken, Continuous Deployment otomatik olarak çalışır.

7. Bildirimler ve Raporlar

Pipeline tamamlandıktan sonra ekip sonuçları içeren bir bildirim alır: başarı/başarısızlık, çalıştırma süresi, yapıt bağlantısı. Slack, Telegram veya e-posta — bildirim kanalları ekip ihtiyaçlarına göre seçilir. Bir aşama başarısız olduğunda, bildirim ilgili hata günlüğüne bağlantı içerir.

CI ve CD Arasındaki Fark

CI ve CD terimleri genellikle tek bir kavram CI/CD olarak kullanılır, ancak aralarında temel bir fark vardır. CI (Continuous Integration) her kod entegrasyonunda kalite kontrolünden sorumluyken, CD (Continuous Delivery) kodun sürüme hazır olmasını sağlar. Bir pipeline tasarlarken farkı anlamak kritik öneme sahiptir.

Continuous Integration — Kalite Kontrolü

CI her push veya pull request'te çalışır ve derleme, statik analiz ve test içerir. CI'ın amacı, düzeltme maliyetinin en düşük olduğu anda sorunları mümkün olduğunca erken tespit etmektir. CI başarısız olursa — kod ana dala girmez. Bir mobil proje için ortalama CI çalıştırma süresi 5–15 dakikadır.

Continuous Delivery — Sürüme Hazırlık

CD, CI'ya sürüm hazırlık aşamalarını ekler: imzalama, karartma, sürüm notları oluşturma, lisans kontrolü, test uzmanları için depolamaya yayınlama. CD garanti eder ki ana daldaki herhangi bir commit tek bir tıklamayla üretime gönderilebilir, ancak sürümün kendisi manuel onay gerektirir.

CI/CD Pipeline Oluşturma Araçları

Mobil geliştirme için CI/CD araçları ekosistemi, bulut hizmetlerini, kendi kendine barındırılan çözümleri ve özel platformları içerir. Araç seçimi ekip büyüklüğüne, bütçeye ve güvenlik gereksinimlerine bağlıdır. Aşağıda en popüler seçenekler bulunmaktadır.

GitHub Actions

GitHub'da yerleşik CI/CD, genel depolar için ayda 2000 dakika ücretsiz limit ile. GitHub Actions, hazır eylemlerin devasa ekosistemi (marketplace), YAML ile kolay yapılandırma ve GitHub depolarıyla sorunsuz entegrasyon sayesinde popülerdir. Sınırlama — ücretsiz planda iOS derlemeleri için Windows çalıştırıcı desteği yoktur.

GitLab CI/CD

Güçlü bir YAML yapılandırıcısı ile kendi kendine barındırılan ve bulut çözümü. GitLab CI paralel işleri, önbellekleme, yapıtları ve ortamları destekler. Kendi altyapısında dağıtım imkanı ve veriler üzerinde tam kontrol sayesinde kurumsal segmentte popülerdir.

Jenkins

Klasik açık kaynak CI sunucusu. Jenkins eklentiler (1800'den fazla) aracılığıyla yapılandırılır, Groovy formatında Declarative Pipeline'ı destekler ve her ortamda çalışır: Windows, macOS, Linux. Özel yönetim gerektirir ancak maksimum yapılandırma esnekliği sunar.

CircleCI

Hız ve basitliğe odaklanmış bulut CI hizmeti. CircleCI bağımlılıkları otomatik olarak önbelleğe alır, izole derlemeler için Docker görüntülerini destekler ve iOS derlemeleri için macOS ile entegre olur. Fiyatlandırma kredi tabanlıdır — performansa değer veren ekipler için uygundur.

CI/CD Pipeline Kurulum Örneği

GitHub Actions ve Fastlane kullanarak bir iOS uygulaması için tam bir CI/CD Pipeline inceleyelim. Fastlane, mobil projeler için karmaşık derleme, imzalama ve yayınlama işlemlerini basit komutlara soyutlayan bir otomasyon aracıdır.

# Fastfile — iOS CI/CD için Fastlane yapılandırması
default_platform(:ios)

platform :ios do
  desc "Testleri ve lint'i çalıştır"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Sürüm derlemesi ve TestFlight'a yükleme"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match sertifikaları ve provisioning profillerini yönetir, build_app IPA'yı derler, pilot derlemeyi TestFlight'a yükler. fastlane release komutu tüm aşamaları sıralı olarak yürütür: sertifikaları alır, derler, imzalar, beta test uzmanları için App Store Connect'e yükler.

GitHub Actions ile iOS İçin CI/CD Pipeline

Fastlane'i GitHub Actions ile entegre etmek, ana dala pull request'lerde tüm pipeline'ın otomatik olarak çalışmasını sağlar. iOS kodu derlemesi için macOS üzerinde kendi kendine barındırılan çalıştırıcı gereklidir — GitHub ücretsiz planda macOS çalıştırıcı sağlamaz.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

CI/CD Pipeline En İyi Uygulamaları

Etkili bir CI/CD Pipeline oluşturmak yalnızca araç seçmeyi değil, aynı zamanda kanıtlanmış uygulamaları takip etmeyi gerektirir. Doğru organizasyon olmadan pipeline, geliştirmeyi hızlandırmak yerine yavaşlatan bir darboğaz haline gelebilir. Aşağıda, olgun mobil ekiplerin deneyimine dayanan temel öneriler bulunmaktadır.

Fail Fast (Hızlı Başarısızlık)

En hızlı kontroller (linting, birim testleri) ilk önce çalıştırılır. Başarısız olurlarsa — pipeline uzun UI testleri veya sürüm derlemeleri çalıştırmadan sona erer. Fail fast CI zamanından dakikalar kazandırır ve geliştiriciye geri bildirimi hızlandırır. İlk başarısızlığa kadar geçen ortalama süre 2–3 dakikayı geçmemelidir.

Bağımlılık Önbellekleme

Gradle önbelleği, CocoaPods önbelleği ve SPM önbelleği çalıştırmalar arasında geri yüklenmelidir. GitHub Actions actions/cache aracılığıyla önbelleklemeyi destekler, GitLab CI cache anahtar sözcüğü aracılığıyla. Önbellekleme olmadan, her derleme tüm bağımlılıkları sıfırdan indirir — pipeline süresine 3–10 dakika ekler.

Paralel Yürütme

Bağımsız aşamalar (Android ve iOS için linter, farklı modüllerin birim testleri) paralel işler olarak çalıştırılır. Paralelleştirme toplam pipeline süresini 20–30 dakikadan 5–10 dakikaya düşürür. Çoğu CI hizmeti paralel işler için ayrı ücret alır — plan seçerken bunu göz önünde bulundurun.

Ortam İzolasyonu

Her pipeline çalıştırması temiz bir ortamda gerçekleştirilir: Docker konteyneri, sanal makine veya geçici çalıştırıcı. İzolasyon önceki derlemelerin mevcut olanı etkilemesini önler. Projeler arasında paylaşılan çalıştırıcı kullanmaktan kaçının — çapraz proje ortam kirliliği belirleyici olmayan hatalara yol açar.

Sır Güvenliği

API anahtarları, imzalama sertifikaları ve uygulama mağazası erişim token'ları CI sunucusunun şifrelenmiş kasasında saklanır. SECRET_ öneki olmadan günlüklerde, yapıtlarda veya ortam değişkenlerinde sırlara asla yer vermeyin. iOS sertifika yönetimi için Fastlane match gibi araçlar kullanın.