GitLab CI: pipeline'lar ve sürekli entegrasyon

GitLab CI Nedir?

GitLab CI, sürekli entegrasyon, teslimat ve dağıtımı kapsayan birleşik DevSecOps GitLab uygulamasının bir parçasıdır. Sistem 2012'de ayrı bir proje olarak başladı ancak daha sonra doğrudan GitLab'a entegre edildi. Temel prensip, depo kökündeki .gitlab-ci.yml dosyası aracılığıyla kod olarak yapılandırmadır (Configuration as Code). GitLab CI hem bulut SaaS sürümünde hem de kendi kendine yönetilen kurulumda mevcuttur.

Mobil geliştirme için GitLab CI, APK ve IPA derlemelerinin otomasyonunu, araçlı testlerin çalıştırılmasını, statik kod analizini, uygulama imzalamayı ve mağaza yayınlamayı sunar. Platform özel ortamlar için Docker görüntülerini destekleyerek Android SDK, NDK, Xcode ve diğer araçların önceden yüklenmesine olanak tanır. Yerleşik Container Registry, ekip içinde görüntülerin depolanmasını ve dağıtılmasını basitleştirir.

GitLab CI Mimarisi: Runner'lar, Pipeline'lar ve Stage'ler

GitLab CI mimarisi üç temel bileşenden oluşur. GitLab Runner, işleri yürüten bir ajandır. Runner'lar paylaşımlı (GitLab tarafından sağlanan), grup (bir proje grubu için) veya belirli (tek bir proje için) olabilir. Her runner bir yürütücü (executor) ile kaydedilir: Shell, Docker, Kubernetes veya VirtualBox. GitLab Runner, yoğun yükleri yönetmek için otomatik ölçeklendirmeyi destekler.

Pipeline, sırayla yürütülen stage'lerin bir koleksiyonudur. Bir stage içinde işler paralel olarak çalışır. Mobil proje için tipik bir yapı şöyledir: build → test → deploy. Test stage'inde bir iş başarısız olursa deploy tetiklenmez. Dağıtım için manuel tetikleme (when: manual) yapılandırılabilir. Depolar arasındaki karmaşık CI/CD senaryoları için çoklu proje pipeline tetikleyicileri de desteklenir.

GitLab Runner Yürütücüleri

Docker yürütücüsü, mobil uygulama CI/CD'si için en popüler olanıdır. Her iş temiz bir Docker kapsayıcısında çalışır ve yalıtım ile tekrarlanabilirlik sağlar. Android derlemeleri için önceden yüklenmiş SDK ile android-sdk görüntüsü kullanılır; iOS için Shell yürütücülü macOS runner kullanılır.

Mobil Projeler için .gitlab-ci.yml Yapılandırması

.gitlab-ci.yml dosyası, YAML formatında bir pipeline tanımlar. Ana bölümler şunları içerir: image (Docker görüntüsü), stages (aşama listesi), variables (ortam değişkenleri), before_script (her işten önceki komutlar) ve script, artifacts, cache bölümleri olan işler. GitLab CI, projeler arasında ortak yapılandırmaları yeniden kullanmak için harici YAML dosyalarının dahil edilmesini (include) destekler.

GitLab CI'de değişkenler birden çok düzeyde ayarlanabilir: kullanıcı arayüzünde genel olarak, yapılandırma dosyasında, grup ve proje ayarlarında. Değişken önceliği bir hiyerarşi izler: tetikleyici değişkenleri en yüksek önceliğe sahiptir, ardından arayüzden CI/CD değişkenleri ve sonra .gitlab-ci.yml'den gelen değişkenler gelir. Değişkenler korunabilir ve yalnızca korunan dallar ve etiketler için erişilebilir hale gelir.

Temel Değişkenler ve Görüntü

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Yapıt İçeren Derleme İşi

generate-apk işi bir Gradle projesi oluşturur ve APK'yı bir yapıt (artifact) olarak kaydeder. Yapıtlar stage'ler arasında iletilir — deploy işi, build stage'inden APK'yı kullanabilir. Yapıtların saklama süresi expire_in ile yapılandırılır.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions: Temel Farklar

Mobil bir proje için GitLab CI ile GitHub Actions arasında seçim yaparken ekip altyapısı önemli bir faktördür. GitLab CI, Android SDK ile Docker görüntülerini depolamak için yerleşik bir Container Registry sağlar. GitHub Actions, GitHub Packages veya harici kayıtlara bağımlıdır. GitLab ayrıca kod güvenlik açığı analizi için yerleşik SAST (Statik Uygulama Güvenlik Testi) özelliğine sahiptir.

GitLab CI daha esnek bir runner modeli sunar — Kubernetes yürütücüsünü, otomatik ölçeklendirmeyi ve özel görüntüleri destekler. GitHub Actions, GitHub ekosistemi entegrasyonu ve eylem pazarında öne çıkar. GitLab CI, GitHub Actions'ın hazır eylemlerle çözdüğü birçok görev için manuel yapılandırma gerektirir.

Mobil CI/CD perspektifinden: GitLab CI, halihazırda GitLab Self-Managed kullanan ve Docker/Kubernetes ile kendi kendine barındırılan runner'lara ihtiyaç duyan şirketler için daha uygundur. GitHub Actions, hazır eylemlere ve kurulum kolaylığına değer veren bulut GitHub'daki küçük ekipler için daha uygundur.

Özellik Karşılaştırması

Android Projesi için Pipeline Örneği

Tam bir Android pipeline'ı şunları içerir: lint, birim test, derleme ve Firebase App Distribution'a dağıtım. Pipeline şunları kullanır: Android SDK içeren bir Docker görüntüsü, Gradle önbellekleme ve aynı stage'de lint ve test'in paralel yürütülmesi. Bu yaklaşım, lint ve test görevleri birbirinden bağımsız olduğu için toplam pipeline süresini azaltır.

iOS projeleri için pipeline yapısı, macOS runner ve kod imzalama gereksinimi nedeniyle farklılık gösterir. Tipik bir iOS pipeline'ı şunları içerir: CocoaPods veya SPM kurulumu, simülatörde test çalıştırma, Xcode projesini arşivleme, IPA dışa aktarma ve TestFlight'a yükleme. GitLab CI for iOS, macOS runner'ları kullanır — zaman sınırlamaları olan GitLab SaaS macOS runner'ları veya Mac Mini veya MacStadium üzerinde kendi kendine barındırılan runner.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

GitLab CI'de Derleme Süresini Optimize Etme

GitLab CI'de mobil derleme pipeline'larını optimize etmek ayrıntılara dikkat gerektirir. Önbellek ve yapıtların doğru yapılandırması derleme süresini birkaç kat azaltabilir. Performans analizi için GitLab, CI/CD Analytics sağlar — pipeline süresi metrikleri, runner yükü ve darboğazları gösteren bir gösterge paneli. Optimizasyon fırsatları bulmak için bu metrikleri düzenli olarak analiz edin. resource_group yapılandırması paralel pipeline çalıştırmalarını engeller — dağıtım çakışmalarını önlemek için kullanışlıdır.

CI için dal stratejisi de önemlidir. Önerilen, tam pipeline'ı yalnızca main ve release dalları için çalıştırmak ve özellik dalları için yalnızca lint ve birim testleri çalıştırmaktır. Bu, runner dakikalarından tasarruf sağlar ve geliştirici geri bildirimini hızlandırır. GitLab CI, workflow:rules'ı destekler — dal, değiştirilen dosyalar veya ortam değişkenlerine göre işleri dahil etme veya hariç tutma için koşullu kurallar.

Bağımlılık önbelleğe alma birincil hızlandırma yöntemidir. GitLab CI, çalıştırmalar arasında .gradle, Pods ve node_modules'u önbelleğe alır. Önbellek anahtarı $CI_COMMIT_REF_SLUG veya bir kilit dosyası karması içerir. Doğru önbellekleme ile Android projesi derleme süresi 10–15 dakikadan 2–4 dakikaya düşer. Önbellek dağıtılabilir — GitLab, önceki anahtarlara geri dönüşlü cache:key'i destekler.

Önceden yüklenmiş araçlara sahip bir Docker görüntüsü kurulum süresinden tasarruf sağlar. Önerilen, Android SDK, NDK ve gerekli API düzeyi ile özel bir görüntü oluşturmaktır. Farklı stage'lerde işlerin (lint, test, assemble) paralel yürütülmesi toplam pipeline süresini azaltır. Görüntüler için çekme politikaları (if-not-present) iş başlatmayı hızlandırır. GitLab örneği düzeyinde görüntüleri önbelleğe almak için bağımlılık proxy'si de kullanılabilir.

Optimizasyonun bir diğer önemli yönü, aşamalar arasında yapıtların kullanılmasıdır. APK ve IPA gibi ağır dosyalar, her işte yeniden oluşturulmak yerine bağımlılık (dependency) aracılığıyla iletilmelidir. Düzinelerce modülü olan büyük projeler için, pipeline düzeyinde Gradle Build Cache'in etkinleştirilmesi ve paylaşılan depolamada uzak bir önbellek yapılandırılması önerilir. Her iş için zaman aşımı, beklenen derleme süresine göre ayarlanmalıdır — bu, askıda kalan işlemleri önler.

Önbellekleme ve Çekme Politikası Örneği

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present