Continuous Integration (CI) — nedir, ilkeleri ve otomasyon kurulumu

Continuous Integration Nedir

Continuous Integration (CI), birden fazla katılımcının kodunu tek bir kod tabanına entegre etme sürecini otomatikleştiren bir geliştirme metodolojisidir. Terim, 2000'lerin başında Martin Fowler tarafından “entegrasyon cehennemi”ni önlemek için bir dizi pratik olarak tanıtıldı — geliştiricilerin haftalarca izole çalıştığı ve değişiklikleri birleştirirken sayısız çakışmanın ortaya çıktığı ve manuel çözümün günler aldığı bir durum.

CI'ın çözdüğü sorun

CI olmadan, bir geliştirici bir özelliği bitirir, değişikliklerini main dalına birleştirmeye çalışır ve meslektaşlarının aynı dosyaları değiştirdiğini fark eder. Çakışmaları çözmek saatler alır ve genellikle çalışan kodu bozar. CI bu sorunu günde birkaç kez entegrasyonu zorunlu kılarak çözer: entegrasyon ne kadar sık olursa, çakışmalar o kadar az ve çözümleri o kadar kolay olur. Uygulama, günlük entegrasyonda çakışma çözümünün dakikalar sürdüğünü, haftalık entegrasyonda ise saatler sürdüğünü göstermektedir.

CI'ın ekonomik etkisi

IBM Systems Sciences Institute'a göre, kodlama aşamasında bir hatayı düzeltme maliyeti 25 dolar, test aşamasında 100 dolar ve üretim aşamasında 2.500 dolardır. CI, hata tespitini mümkün olduğunca sola kaydırır (shift left) ve düzeltmenin neredeyse ücretsiz olduğu commit aşamasında hataları bulur. CI kullanan ekipler, hata ayıklamaya ortalama %15 zaman harcarken, CI kullanmayan ekipler %35 zaman harcar.

Continuous Integration'ın Temel İlkeleri

Martin Fowler, teknoloji yığınından bağımsız olarak geçerli kalan temel CI pratiklerini tanımladı. Bu ilkelere uymak, CI'ın bürokratik bir yük haline gelmek yerine değer getirmesini sağlar. Mobil geliştirme ek gereksinimler getirir, ancak çekirdek değişmez.

Tek depo

Tüm proje kodu, birleşik bir sürüm kontrol sistemi (Git) ile tek bir depoda saklanır. Tek gerçek kaynağı, bir özelliğin çatalda geliştirildiği ve haftalarca ana kod tabanıyla senkronize edilmediği durumu ortadan kaldırır. Mobil projelerde bu, Android, iOS ve backend parçalarının tek bir depoda (monorepo) veya paylaşılan bir sürümleme şemasına sahip ayrı depolarda bulunabileceği anlamına gelir.

Otomatik derleme

Proje derlemesi tek bir komutla çalıştırılabilir olmalıdır. Android için bu ./gradlew assembleDebug, iOS için — xcodebuild veya fastlane build'dir. Derleme betiği tekrarlanabilirliği doğrular: CI sunucusundaki derleme, geliştiricinin makinesindekiyle aynı sonucu üretmelidir. Ortamdaki farklılıklar, konteynerizasyon veya IaC (Infrastructure as Code) ile giderilir.

Otomatik testler

Derlemeden sonra, tüm test seviyeleri yürütülür: birim, entegrasyon ve UI. Testler başarısız olursa, commit geçersiz sayılır. Yeşil durumu korumak ekibin ortak sorumluluğudur. Mobil projelerde, hızlı testler (commit başına 5 dakika içinde yürütülen) genellikle yavaş testlerden (gerçek cihazlarda UI testleri, daha seyrek çalıştırılan) ayrılır.

// CI dostu raporla birim testi örneği
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast ve şeffaflık

CI sonuçları tüm ekip için açıktır: herkes hangi commit'in derlemeyi bozduğunu görebilir. Şeffaflık, hesap verebilirlik kültürü yaratır: geliştiriciler push'tan önce değişikliklerini kontrol eder ve bozuk derlemeyi sıra beklemeden düzeltir. CI sunucusu, derleme durumu değiştiğinde Slack veya Telegram'a bildirim gönderir.

CI Sisteminin Bileşenleri

Eksiksiz bir CI sistemi, birbiriyle etkileşime giren birkaç bileşenden oluşur. Her bileşen, tetiklemeden rapora kadar boru hattının kendi kısmından sorumludur. CI mimarisini anlamak, sorunları teşhis etmeye ve performansı optimize etmeye yardımcı olur.

CI sunucusu

Derleme kuyruğunu, kaynak tahsisini ve sonuç yayınlamayı yöneten merkezi bileşen. Bir CI sunucusu bulut tabanlı (GitHub Actions, GitLab CI, CircleCI) veya kendi barındırılan (Jenkins, TeamCity) olabilir. Sunucu, webhook veya polling yoluyla depodaki değişiklikleri izler ve her push veya pull request'te boru hattını tetikler.

Runner'lar ve ajanlar

Runner'lar, derleme görevlerini yürüten sanal veya fiziksel makinelerdir. Bulut CI'da runner'lar sağlayıcı tarafından sağlanır ve kullanım süresine göre faturalandırılır. Kendi barındırılan runner'lar kendi altyapınıza kurulur ve bakım gerektirir. iOS derlemeleri macOS runner'ları, Android derlemeleri Linux veya Windows gerektirir.

Yapıtlar ve önbellek

Derlemeden sonra CI sistemi yapıtları (APK, IPA, test raporları) depolamaya kaydeder — bunlar indirme ve dağıtım için kullanılabilir. Çalıştırmalar arasında bağımlılık önbelleğe alma (Gradle önbelleği, CocoaPods önbelleği) sonraki derlemeleri 3–5 kat hızlandırır.

Mobil Uygulamalar için Continuous Integration

Mobil geliştirme, web veya backend projelerinden farklı olarak CI için özel gereksinimlere sahiptir. Uzun derleme süreleri (Android için 3–15 dakika, iOS için 5–20 dakika), birden çok yapıt türü (APK, AAB, IPA), imzalama ve karartma ihtiyacı — tüm bunlar özelleştirilmiş CI boru hattı yapılandırması gerektirir.

Android CI boru hattı

Android için tipik bir CI şunları içerir: linting (ktlint, detekt) ve statik analiz, JUnit ve MockK ile birim testleri, hata ayıklama ve sürüm APK/AAB derlemesi, CI içinde öykünücüde araçsal testler ve yapıt yayınlama. Gradle önbelleği tekrarlanan derlemeleri hızlandırır — onsuz her derleme bağımlılıkları sıfırdan indirir ve 3–5 dakika kaybeder.

iOS CI boru hattı

iOS CI, Swift/Objective-C kodunu derlemek için bir macOS runner gerektirir. Boru hattı şunları içerir: CocoaPods veya SPM bağımlılıklarını kurma, stil kontrolü için SwiftLint, XCTest ile birim testleri, IPA derlemesi, Fastlane match ile kod imzalama ve TestFlight'a yükleme. Veri merkezindeki Mac mini veya Mac'te kendi barındırılan runner, bulut macOS runner'larına bir alternatiftir.

Platformlar arası projeler (Flutter, React Native)

Flutter ve React Native, her iki platform için yerel derlemelere dönüştürülür. CI, iki runner'ı desteklemelidir: Android derlemeleri için Linux ve iOS derlemeleri için macOS. En uygun strateji, bölünmüş bir boru hattıdır: Linux runner'da Android derlemesi, macOS runner'da iOS derlemesi, ardından her iki yapıt tek bir sürümde birleştirilir.

CI Araçlarının Karşılaştırılması

CI aracı seçimi, ekip büyüklüğüne, gerekli performansa, bütçeye ve teknoloji yığınına bağlıdır. Aşağıda, mobil geliştirmeye odaklanan popüler çözümlerin bir karşılaştırması bulunmaktadır. Kendi barındırılan çözümler kontrol sağlar ancak yönetim gerektirir; bulut çözümleri rahatlık sağlar ancak yapılandırmayı sınırlar.

GitHub Actions

Herkese açık depolar için ücretsiz (ayda 2000 dakika). GitHub Actions, Android (gradle/actions) ve iOS (apple-actions) için hazır eylemler ekosistemi sunar. Dezavantajı, macOS runner'ların yalnızca ücretli planlarda kullanılabilmesidir. Açık kaynak ve halihazırda GitHub kullanan küçük ekipler için idealdir.

Jenkins

Kendi barındırılan açık kaynaklı bir CI sunucusu. Jenkins, Groovy Pipeline aracılığıyla yapılandırılır, yüzlerce eklentiyi destekler ve herhangi bir donanımda çalışır. Kurulum ve bakım için bir DevOps mühendisi gerektirir. Altyapı kontrolünün kritik olduğu kurumsal segmentte popülerdir.

GitLab CI

Açık runner mimarisiyle GitLab'da yerleşik CI/CD. GitLab CI, ücretsiz planda kendi runner'larınızı (macOS dahil) kullanmanıza izin verir. YAML yapılandırması GitHub Actions'dan daha güçlüdür ancak öğrenmesi daha zordur. GitLab'ı tek bir DevOps platformu olarak kullanan ekipler için uygundur.

CircleCI

Hıza odaklanan bir bulut CI. CircleCI, Docker, macOS ve Android görüntülerini destekler ve bağımlılıkları otomatik olarak önbelleğe alır. Fiyatlandırma kredi tabanlıdır — küçük ekipler için GitHub Actions'dan daha pahalıdır ancak optimize edilmiş runner'lar sayesinde daha hızlıdır. Hız gereksinimleri olan üretim projeleri için önerilir.

CI Kurulum Örneği

GitHub Actions kullanarak bir Android projesi için CI kurulumunu inceleyelim. Boru hattı, main dalına her push ve pull request'te statik analiz, derleme ve test gerçekleştirir. Minimum yapılandırma 15 dakika sürer ve harici hizmet gerektirmez.

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

Boru hattı iki paralel işten oluşur: lint (statik analiz gerçekleştirir) ve unit-tests (lint'a bağlıdır — linting başarısız olursa testler çalışmaz). unit-tests işi, test raporunu bir yapıt olarak yükler — ekip, dosyaları yerel olarak indirmeden GitHub Actions arayüzünde inceleyebilir.

CI öncesi yerel kontrol

Önemsiz hatalar nedeniyle CI başarısızlıklarını önlemek için Git'te bir pre-push hook veya aynı kontrolleri yerel olarak çalıştıran bir Gradle görevi ayarlayın. Örneğin: ./gradlew ktlintCheck detekt testDebugUnitTest. Yerel kontroller 3 dakikadan fazla sürüyorsa, bunları hızlı (lint aracı) ve yavaş (testler) olarak ayırın, hızlı kontrolleri her commit'ten önce, yavaş kontrolleri yalnızca push'tan önce çalıştırın.