GitLab CI: mahiyyəti, pipeline’lar və davamlı inteqrasiya

GitLab CI nədir?

GitLab CI — bu GitLab vahid DevSecOps tətbiqinin davamlı inteqrasiya, çatdırma və yerləşdirməni əhatə edən hissəsidir. Sistem 2012-ci ildə ayrı bir layihə olaraq ortaya çıxdı, lakin sonra birbaşa GitLab-a inteqrasiya edildi. Əsas prinsip — depozitoriyanın kök qovluğundakı .gitlab-ci.yml faylı vasitəsilə konfiqurasiyanın kod şəklində olmasıdır (Configuration as Code). GitLab CI həm bulud SaaS versiyasında, həm də self-managed quraşdırmada mövcuddur.

Mobil tətbiq inkişafı üçün GitLab CI APK və IPA qurulmasının avtomatlaşdırılmasını, instrumental testlərin işə salınmasını, statik kod analizini, tətbiq imzalanmasını və mağazalarda dərc edilməsini təklif edir. Platforma fərdi mühitlər üçün Docker görüntülərini dəstəkləyir ki, bu da Android SDK, NDK, Xcode və digər alətlərin əvvəlcədən qurulmasına imkan verir. Daxili Container Registry komanda daxilində görüntülərin saxlanmasını və paylanmasını asanlaşdırır.

GitLab CI Arxitekturası: Runnels, Pipelines və Stages

GitLab CI arxitekturası üç əsas komponentdən ibarətdir. GitLab Runner — işləri yerinə yetirən agentdir. Runners shared (GitLab tərəfindən təmin edilir), group (layihə qrupu üçün) və specific (bir layihə üçün) ola bilər. Hər runner executor göstərərək qeydiyyatdan keçir: Shell, Docker, Kubernetes və ya VirtualBox. GitLab Runner pik yüklərin öhdəsindən gəlmək üçün auto-skaling dəstəkləyir.

Pipeline — ardıcıl yerinə yetirilən stages məcmusudur. Bir stage daxilində işlər paralel yerinə yetirilir. Mobil layihə üçün tipik struktur: build → test → deploy. Əgər test stage’ındakı iş xəta ilə bitsə, deploy işə düşürülmür. Yerləşdirmə üçün əl ilə işə salma (when: manual) konfiqurasiya edilə bilər. Həmçinin depozitoriyalar arasında mürəkkəb CI/CD ssenariləri üçün multi-project pipelines tetikləyiciləri dəstəklənir.

GitLab Runner Executorları

Docker executor — mobil tətbiqlərin CI/CD-si üçün ən populyardır. Hər bir iş təmiz Docker konteynerində işə salınır ki, bu da izolyasiya və təkrarlanabilirliyi təmin edir. Android qurulması üçün əvvəlcədən quraşdırılmış SDK ilə android-sdk görüntüsü istifadə edilir, iOS üçün isə Shell executor ilə macOS runner istifadə edilir.

Mobil Layihələr Üçün .gitlab-ci.yml Konfiqurasiyası

.gitlab-ci.yml faylı pipeline’ı YAML formatında təyin edir. Əsas bölmələr: image (Docker görüntüsü), stages (mərhələlər siyahısı), variables (mühit dəyişənləri), before_script (hər işdən əvvəl əmrlər) və script, artifacts, cache bölmələri ilə işlərin özləri. GitLab CI include dəstəkləyir — layihələr arasında ümumi konfiqurasiyaların təkrar istifadəsi üçün xarici YAML fayllarını birləşdirmə.

GitLab CI-da dəyişənlər bir neçe səviyyədə təyin edilə bilər: UI-da qlobal, konfiqurasiya faylında, qrup və layihə tənzimləmələrində. Dəyişən prioriteti iyerarxiya ilə müəyyən edilir: trigger variables ən yüksək prioritetə malikdir, sonra UI-dan CI/CD variables, sonra isə .gitlab-ci.yml-dən gələnlər. Dəyişənlər qoruna bilər (protected), bu da onları yalnız qorunan branch və tag-lar üçün əlçatan edir.

Əsas dəyişənlər və 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/

Artefaktlarla quruluş işi

generate-apk işi Gradle layihəsini qurur və APK-nı artefakt kimi saxlayır. Artefaktlar stages arasında ötürülür — deploy işi build-dən APK-dan istifadə edə bilər. Artefaktların saxlanma müddəti expire_in vasitəsilə konfiqurasiya edilir.

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

GitLab CI vs GitHub Actions: Əsas Fərqlər

Mobil layihə üçün GitLab CI ilə GitHub Actions arasında seçim edərkən komandanın infrastrukturunu nəzərə almaq vacibdir. GitLab CI Android SDK ilə Docker görüntülərinin saxlanması üçün istifadə edilə bilən daxili Container Registry təmin edir. GitHub Actions GitHub Packages və ya xarici reyestrlərə etibar edir. GitLab həmçinin zəifliklər üçün kod analizi üçün daxili SAST (Static Application Security Testing) malikdir.

GitLab CI daha çevik runner modeli təklif edir — Kubernetes executor, auto-skaling və fərdi görüntülər dəstəkləyir. GitHub Actions GitHub ekosistemi və actions bazarı ilə inteqrasiyada qalib gəlir. GitLab CI GitHub Actions-da hazır action ilə həll edilən bir çox tapşırıq üçün əl ilə konfiqurasiya tələb edir.

Mobil layihələr üçün CI/CD baxımından: GitLab CI artıq GitLab Self-Managed istifadə edən və Docker/Kubernetes ilə self-hosted runners tələb edən şirkətlər üçün daha uyğundur. GitHub Actions bulud GitHub-dan istifadə edən, hazır actions və sadə konfiqurasiyanı qiymətləndirən kiçik komandalar üçün daha əlverişlidir.

Imkanların müqayisəsi

Android Layihəsi Üçün Pipeline Nümunəsi

Android üçün tam pipeline daxildir: lint, vahid testlər, quruluş və Firebase App Distribution-da yerləşdirmə. Pipeline Android SDK ilə Docker görüntüsü, Gradle keşləməsi və bir stage daxilində lint və testlərin paralel yerinə yetirilməsindən istifadə edir. Bu yanaşma pipeline’ın ümumi vaxtını azaldır, çünki lint və test tapşırıqları bir-birindən asılı deyil.

iOS layihələri üçün pipeline strukturu macOS runner və kod imzalanması ehtiyacı səbəbindən fərqlidir. Tipik iOS pipeline’ı daxildir: CocoaPods və ya SPM quraşdırılması, simulyatorda testlərin işə salınması, Xcode layihəsinin arxivləşməsi, IPA ixracı və TestFlight-a yüklənmə. iOS üçün GitLab CI macOS runners istifadə edir — ya vaxt məhdudiyyəti ilə GitLab SaaS macOS runners, ya da Mac mini və ya MacStadium-da self-hosted 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-da Quruluş Vaxtının Optimallaşdırılması

GitLab CI-da mobil quruluş pipeline’larının optimallaşdırılması detallara diqqət tələb edir. Cache və artifacts-ın düzgün konfiqurasiyası quruluş vaxtını bir neçə dəfə azaltmağa imkan verir. Performans təhlili üçün GitLab CI/CD Analytics təqdim edir — pipeline müddəti, runner yükü və dar boğazlar haqqında göstəricilərə malik panel. Optimallaşdırma imkanlarını tapmaq üçün bu göstəriciləri müzəmmədən təhlil edin. resource_group tənzimləməsi bir pipeline’ın paralel işə salınmasını bloklayır — bu yerləşdirmə zamanı münaqişələrin qarşısını almaq üçün faydalıdır.

CI üçün branch strategiyası da vacibdir. Tam pipeline’ı yalnız main və release branch-ları üçün işə salmaq, feature branch-lar üçün isə yalnız lint və vahid testlər tövsiyə olunur. Bu runner dəqiqələrinə qənaət edir və tərtibatçılara geribildirimi sürətləndirir. GitLab CI workflow:rules dəstəkləyir — branch, dəyişdirilmiş fayllar və ya mühit dəyişənlərindən asılı olaraq işləri daxil etmək və ya çıxarmaq üçün şərti qaydalar.

Asılılıqların keşlənməsi — sürətləndirmənin əsas yoludur. GitLab CI işə salmalar arasında .gradle, Pods və node_modules keşləyir. Keş açarı $CI_COMMIT_REF_SLUG və ya lock faylının heşini əhatə edir. Düzgün keşləmə ilə Android layihəsinin quruluş müddəti 10–15 dəqiqədən 2–4 dəqiqəyə qədər azalır. Keş paylanmış ola bilər — GitLab əvvəlki açarlara fallback ilə cache:key dəstəkləyir.

Əvvəlcədən quraşdırılmış alətlərlə Docker görüntüsü quraşdırma vaxtına qənaət edir. Android SDK, NDK və tələb olunan API səviyyəsi ilə fərdi görüntü yaratmaq tövsiyə olunur. Müxtəlif stage’larda işlərin (lint, test, assemble) paralel yerinə yetirilməsi pipeline’ın ümumi vaxtını azaldır. Görüntülər üçün pull policies (if-not-present) işlərin başlamasını sürətləndirir. Həmçinin GitLab instance səviyyəsində görüntüləri keşləmək üçün dependency proxy istifadə edilə bilər.

Optimallaşdırmanın digər vacib aspekti — mərhələlər arasında artefaktlardan istifadədir. Ağır fayllar APK və IPA-nı hər işdə yenidən qurmaq əvəzinə dependency vasitəsilə ötürmək daha yaxşıdır. Onlarla modulu olan böyük layihələr üçün pipeline səviyyəsində Gradle Build Cache-i aktivləşdirmək və ümumi anbarda remote cache konfiqurasiya etmək tövsiyə olunur. Hər iş üçün timeout gözlənilən quruluş müddətinə əsasən təyin edilməlidir — bu asılı proseslərin qarşısını alır.

Keşləmə və pull policy ilə nümunə

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

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