Mobil geliştirmede Build Pipeline — özü, aşamaları ve yapılandırma

Build Pipeline Nedir

Build Pipeline, her kod değişikliğinde otomatik olarak yürütülen resmileştirilmiş bir adım dizisidir. Her adım, kalitenin belirli bir yönünü kontrol eder: derlenebilirlik, testlerin doğruluğu, güvenlik açıklarının bulunmaması, kod stiline uygunluk. Herhangi bir adım başarısız olursa, pipeline durur.

Pipeline kavramı üretim hattından gelir — tıpkı her istasyonun ürüne değer kattığı bir fabrikadaki gibi. Geliştirmede, her aşama kodun sürüm için hazır olduğuna dair güven ekler. Modern pipeline'lar kod olarak tanımlanır (Pipeline as Code) ve projeyle birlikte Git deposunda saklanır.

Continuous Delivery Foundation, 2025'e göre, olgun bir build pipeline, commit'ten sürüme kadar geçen süreyi haftalardan dakikalara indirir. Bu, tam otomasyon ve bağımsız aşamaların paralel yürütülmesiyle sağlanır.

Pipeline as Code

Bir web arayüzü üzerinden yapılandırmak yerine, modern bir pipeline YAML veya Groovy dosyalarında tanımlanır. Jenkinsfile, `.gitlab-ci.yml`, `.github/workflows/build.yml` Pipeline as Code örnekleridir. Avantajlar: sürümleme, kod incelemesi, tekrarlanabilirlik.

Bildirimsel (Declarative) ve Scripted Pipeline

Jenkins'in iki sözdizimi vardır. Bildirimsel — daha basit, net bir stages/steps yapısıyla. Scripted — daha esnek, Groovy tabanlı. Çoğu proje için, daha okunabilir ve öngörülebilir olduğundan bildirimsel yaklaşım önerilir.

Tipik Pipeline Aşamaları

Bir mobil uygulama için tipik bir build pipeline, birkaç temel aşama içerir. Her aşama işlevini yerine getirir ve potansiyel sorunları erken bir aşamada filtreler.

Checkout ve Bağımlılık Kurulumu

Pipeline, depoyu klonlayarak başlar. Ardından bağımlılıklar kurulur: Gradle/Maven paketleri, CocoaPods, SPM (Swift Package Manager), npm paketleri. Bu aşamada önbellek kullanımı, sonraki derlemeleri %50-70 oranında hızlandırır.

Linting ve Statik Analiz

Derlemeden önce, kod kalitesi araçları çalıştırılır: Kotlin için Detekt veya ktlint, Swift için SwiftLint, JavaScript için ESLint. Bunlar kod stiline uygunluğu kontrol eder ve kod analizi düzeyinde potansiyel hataları bulur.

Derleme ve Birim Testleri

Kod ikili forma derlenir, birim testler paralel olarak çalışır. Android için `./gradlew testDebugUnitTest`, iOS için — `xcodebuild test -scheme App -destination 'platform=iOS Simulator'`. Test başarısızlığı pipeline'ı hemen durdurur.

name: Mobile Build Pipeline
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew detekt

  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew jacocoTestReport

  build-release:
    needs: [lint, unit-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk

Entegrasyon ve UI Testleri

Başarılı derlemeden sonra, uygulamanın çalıştırılmasını gerektiren testler yürütülür: Android için Espresso, iOS için XCTest/XCUITest, React Native için Detox. Bu aşamada, artefakt çiftlik hizmetleri (Firebase Test Lab, BrowserStack, Sauce Labs) aracılığıyla bir simülatör veya gerçek cihazda dağıtılır.

Pipeline Yapılandırması

Pipeline'ın doğru yapılandırılması, tüm CI/CD sürecinin verimliliğini belirler. Yapılandırma şunları içerir: tetikleyici seçimi, paralel ve sıralı aşamaların tanımlanması, parametrelendirme ve harici hizmetlerle entegrasyon.

Pipeline Tetikleyicileri

Ana tetikleyiciler: depoya push, pull request (özellikle otomatik kontrollerle kod incelemesi için), Git etiketi oluşturma (sürüm derlemesi için), zamanlama (nightly build). Pull request tetikleyicisi, kod birleştirmeden önce sorunları belirlediği için ekip çalışması için en pratiktir.

Paralel ve Sıralı Aşamalar

Bağımsız aşamalar (linting, farklı işletim sistemi sürümlerinde test) hızlandırmak için paralel olarak çalıştırılmalıdır. Bağımlı olanlar — sıralı olarak. Modern CI sistemleri, paralel görevleri otomatik olarak yönetir ve bunları mevcut ajanlara dağıtır.

• Fail-fast — herhangi bir paralel daldaki hatada anında başarısızlık yapılandırın
• Matrix build — tek bir derlemeyi birden çok yapılandırmada (API Seviyesi, Xcode sürümü) çalıştırma
• Koşullu aşamalar — bazı aşamalar yalnızca belirli dallar için çalışır (örneğin, yalnızca main'den dağıt)

Build Pipeline Optimizasyonu

Uzun bir pipeline, geliştirme döngüsünü yavaşlatır ve ekip motivasyonunu azaltır. Derleme süresi optimizasyonu, build pipeline ile çalışırken bir DevOps mühendisinin ana görevlerinden biridir.

Bağımlılık Önbelleklemesi

Gradle Build Cache, önceki derlemelerin sonuçlarını kaydeder. Bir modülün kaynak kodu değişmediyse, yeniden derlenmez. Swift ve Kotlin'de artımlı derleme benzer şekilde çalışır. Önbellek boyutu gigabaytlara ulaşabilir, ancak zaman tasarrufu %30 ile %70 arasındadır.

Testlerin Paralel Yürütülmesi

Birim testler, test sınıflarını dağıtarak aynı anda birden çok ajanda çalıştırılabilir. Sharding, testleri gruplara (shard) ayırma tekniğidir. GitHub Actions `strategy.matrix`'i, Jenkins — Parallel Test Executor'ı, Gradle — `--parallel --max-workers`'ı destekler.

Pipeline Katmanlarını En Aza İndirme

Her ekstra aşama süre ekler. Pipeline'ı düzenli olarak analiz edin: hangi aşamalar birleştirilebilir? Örneğin, linting derlemeden önce değil, derleme ile paralel olarak çalıştırılabilir. Entegrasyon testleri — her commit için değil, yalnızca pull request'ler için.

pipeline {
    agent any
    options {
        timestamps()
        timeout(time: 30, unit: 'MINUTES')
    }
    stages {
        stage('Parallel Checks') {
            parallel {
                stage('Lint') {
                    steps { sh './gradlew detekt' }
                }
                stage('Unit Tests') {
                    steps { sh './gradlew test' }
                }
            }
        }
        stage('Build') {
            steps { sh './gradlew assembleRelease' }
        }
    }
}

Build Pipeline Güvenliği

Build pipeline, yazılım tedarik zincirinin kritik bir öğesidir ve güvenliği göz ardı edilemez. Pipeline'ın tehlikeye girmesi, sürüm artefaktına kötü amaçlı kod enjekte edilmesine yol açarak uygulamanın tüm kullanıcılarını etkileyebilir.

Pipeline'lara Tedarik Zinciri Saldırıları

Bilinen saldırılar: SolarWinds (2020), Codecov (2021), 3CX (2023) — hepsi CI/CD pipeline'larındaki güvenlik açıklarını kullandı. Ortak vektör — saldırgan, derleme sunucusunun kimlik bilgilerine erişir ve derleme aşamasında kodu değiştirir. Sonuç — meşru bir sertifikayla imzalanmış kötü amaçlı sürüm.

Kimlik Bilgisi Koruması

Asla saklamayın imzalama anahtarlarını, API token'larını ve parolaları depoda veya CI sistemi ortam değişkenlerinde düz metin olarak. CI sistemi sırlarını (GitHub Secrets, GitLab CI Variables), HashiCorp Vault, AWS Secrets Manager kullanın. Sırlara erişimi en aza indirin — her pipeline yalnızca belirli adımları için gereken anahtarları almalıdır.

Pipeline Artefaktlarının Doğrulanması

Pipeline'dan çıkan her artefakt kriptografik olarak imzalanmalı ve bir tasdik (attestation) — menşe kanıtı (provenance) içermelidir. Araçlar: SLSA çerçevesi, in-toto tasdiki, konteyner imzalaması için cosign. İmza doğrulaması, herhangi bir ortama dağıtımdan önce yapılmalıdır.

name: Secure Build Pipeline
on: [push]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan dependencies
        run: ./gradlew dependencyCheckAnalyze
      - name: SAST scan
        run: ./gradlew detekt

  sign-attest:
    needs: security-scan
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew assembleRelease
      - name: Sign APK
        run: jarsigner -keystore ${{ secrets.KEYSTORE }} \
          app-release.apk ${{ secrets.KEY_ALIAS }}
      - name: Generate provenance
        uses: actions/attest-build-provenance@v1

Pipeline İzleme ve Hata Ayıklama

Build pipeline, sürekli izleme gerektiren karmaşık bir sistemdir. Metrikler olmadan, pipeline'ın yavaşlayıp yavaşlamadığını ve hangi aşamanın darboğaz haline geldiğini belirlemek imkansızdır.

Pipeline Metrikleri

Takip edin: toplam pipeline süresi, her aşamanın süresi, derleme başarısızlık oranı, kuyruk bekleme süresi. Büyük bir ekip için (>20 geliştirici), Grafana veya Datadog'da haftalık/aylık toplu istatistiklerle bir pano kurulması önerilir.

Başarısızlık Uyarıları

Her pipeline başarısızlığı bir yanıt gerektirir. Mesajlaşma uygulamalarında (Slack, Telegram, Discord) hata günlüğüne bağlantı ve commit yazarının adıyla bildirimler kurun. Kritik başarısızlıklar için — yükseltmeli PagerDuty veya Opsgenie.

Yerel Pipeline Hata Ayıklama

Act (GitHub Actions için) veya Jenkins Pipeline Unit Test gibi araçlar, commit yapmadan pipeline'ı yerel olarak çalıştırmaya olanak tanır. Bu, özellikle yeni aşamalar eklerken veya yapılandırmayı değiştirirken pipeline geliştirme ve hata ayıklamayı hızlandırır.