GitLab CI: esența, pipeline-urile și integrarea continuă

Ce este GitLab CI?

GitLab CI face parte din aplicația unificată DevSecOps GitLab, incluzând integrare, livrare și implementare continuă. Sistemul a apărut în 2012 ca un proiect separat, dar apoi a fost integrat direct în GitLab. Principiul de bază — configurație ca cod (Configuration as Code) prin fișierul .gitlab-ci.yml în rădăcina depozitului. GitLab CI este disponibil atât în versiunea cloud SaaS, cât și în instalarea self-managed.

Pentru dezvoltarea mobilă, GitLab CI oferă automatizarea construirii APK și IPA, rularea testelor instrumentale, analiza statică a codului, semnarea aplicațiilor și publicarea în magazine. Platforma suportă imagini Docker pentru medii personalizate, ceea ce permite preinstalarea Android SDK, NDK, Xcode și a altor instrumente. Container Registry încorporat simplifică stocarea și distribuirea imaginilor în cadrul echipei.

Arhitectura GitLab CI: Runner-e, Pipeline-uri și Stage-uri

Arhitectura GitLab CI constă din trei componente cheie. GitLab Runner este agentul care execută job-urile. Runner-ele pot fi shared (furnizate de GitLab), group (pentru un grup de proiecte) și specific (pentru un singur proiect). Fiecare runner se înregistrează cu specificarea executorului: Shell, Docker, Kubernetes sau VirtualBox. GitLab Runner suportă auto-scalare pentru gestionarea sarcinilor de vârf.

Pipeline-ul este un set de stage-uri executate secvențial. În cadrul unui stage, job-urile sunt executate paralel. Structura tipică pentru un proiect mobil: build → test → deploy. Dacă un job pe stage-ul test se încheie cu eroare, deploy nu este pornit. Se poate configura pornirea manuală (when: manual) pentru implementare. De asemenea, sunt suportate trigger-e multi-project pipelines pentru scenarii complexe CI/CD între depozite.

Executorii GitLab Runner

Docker executor este cel mai popular pentru CI/CD al aplicațiilor mobile. Fiecare job este rulat într-un container Docker curat, ceea ce garantează izolarea și reproductibilitatea. Pentru compilarea Android se folosește imaginea android-sdk cu SDK preinstalat, pentru iOS — runner macOS cu executor Shell.

Configurația .gitlab-ci.yml pentru proiecte mobile

Fișierul .gitlab-ci.yml definește pipeline-ul în format YAML. Secțiunile principale: image (imagine Docker), stages (lista etapelor), variables (variabile de mediu), before_script (comenzi înainte de fiecare job) și job-urile în sine cu secțiunile script, artifacts, cache. GitLab CI suportă include — conectarea fișierelor YAML externe pentru reutilizarea configurațiilor comune între proiecte.

Variables în GitLab CI pot fi setate la mai multe niveluri: globale în UI, în fișierul de configurare, în setările de grup și proiect. Prioritatea variabilelor este determinată de ierarhie: trigger variables au cea mai mare prioritate, apoi CI/CD variables din UI, apoi din .gitlab-ci.yml. Variabilele pot fi protejate (protected), făcându-le accesibile doar pentru branch-uri și tag-uri protejate.

Variabile de bază și imagine

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/

Job de construire cu artefacte

Job-ul generate-apk construiește proiectul Gradle și salvează APK ca artefact. Artefactele sunt transmise între stage-uri — job-ul deploy poate folosi APK-ul din build. Durata de stocare a artefactelor este configurată prin expire_in.

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

GitLab CI vs GitHub Actions: diferențe cheie

La alegerea între GitLab CI și GitHub Actions pentru un proiect mobil, este important să se țină cont de infrastructura echipei. GitLab CI oferă un Container Registry încorporat care poate fi folosit pentru stocarea imaginilor Docker cu Android SDK. GitHub Actions se bazează pe GitHub Packages sau registre externe. GitLab are, de asemenea, SAST încorporat (Testare Statică de Securitate a Aplicațiilor) pentru analiza codului pentru vulnerabilități.

GitLab CI oferă un model mai flexibil de runner-e — suportă executor Kubernetes, auto-scalare și imagini personalizate. GitHub Actions câștigă în integrarea cu ecosistemul GitHub și piața de actions. GitLab CI necesită configurare manuală pentru multe sarcini care în GitHub Actions sunt rezolvate cu un action gata făcut.

Din punct de vedere CI/CD pentru proiecte mobile: GitLab CI este mai potrivit pentru companiile care folosesc deja GitLab Self-Managed și necesită runner-e self-hosted cu Docker/Kubernetes. GitHub Actions este mai convenabil pentru echipele mici care folosesc GitHub cloud, apreciind acțiunile gata făcute și simplitatea configurării.

Compararea capacităților

Exemplu de pipeline pentru un proiect Android

Pipeline-ul complet pentru Android include: lint, teste unitare, construire și implementare în Firebase App Distribution. Pipeline-ul folosește o imagine Docker cu Android SDK, cache Gradle și executarea paralelă a lint și testelor într-un singur stage. Această abordare reduce timpul total al pipeline-ului, deoarece sarcinile lint și test nu sunt dependente una de alta.

Pentru proiectele iOS, structura pipeline-ului diferă din cauza necesității unui runner macOS și a semnării codului. Pipeline-ul iOS tipic include: instalarea CocoaPods sau SPM, rularea testelor pe simulator, arhivarea proiectului Xcode, exportul IPA și încărcarea în TestFlight. GitLab CI pentru iOS folosește runner-e macOS — fie runner-e GitLab SaaS macOS cu limitări de timp, fie un runner self-hosted pe Mac mini sau MacStadium.

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

Optimizarea timpului de construire în GitLab CI

Optimizarea pipeline-urilor de construire mobilă în GitLab CI necesită atenție la detalii. Configurarea corectă a cache și artifacts permite reducerea timpului de construire de mai multe ori. Pentru analiza performanței, GitLab oferă CI/CD Analytics — un panou cu metrici privind durata pipeline-urilor, încărcarea runner-elor și blocajele. Analizează aceste metrici în mod regulat pentru a găsi oportunități de optimizare. Setarea resource_group blochează rularea paralelă a unui pipeline — util pentru prevenirea conflictelor în timpul implementării.

Strategia de branch-uri pentru CI este de asemenea importantă. Se recomandă rularea pipeline-ului complet doar pentru branch-urile main și release, iar pentru branch-urile feature — doar lint și teste unitare. Aceasta economisește minutele runner-elor și accelerează feedback-ul pentru dezvoltatori. GitLab CI suportă workflow:rules — reguli condiționale pentru includerea sau excluderea job-urilor în funcție de branch, fișiere modificate sau variabile de mediu.

Cache-ul dependențelor este principala metodă de accelerare. GitLab CI face cache pentru .gradle, Pods și node_modules între rulări. Cheia de cache include $CI_COMMIT_REF_SLUG sau hash-ul fișierului lock. Timpul de construire a unui proiect Android se reduce de la 10–15 la 2–4 minute cu un cache corect. Cache-ul poate fi distribuit — GitLab suportă cache:key cu fallback la chei anterioare.

O imagine Docker cu instrumente preinstalate economisește timpul de instalare. Se recomandă crearea unei imagini personalizate cu Android SDK, NDK și nivelul API necesar. Executarea paralelă a job-urilor (lint, test, assemble) în stage-uri diferite reduce timpul total al pipeline-ului. Pull policies pentru imagini (if-not-present) accelerează pornirea job-urilor. De asemenea, se poate folosi dependency proxy pentru cache-ul imaginilor la nivelul instanței GitLab.

Un alt aspect important al optimizării este utilizarea artefactelor între etape. Fișierele grele APK și IPA este mai bine să fie transmise prin dependency, decât să fie reconstruite în fiecare job. Pentru proiecte mari cu zeci de module, se recomandă activarea Gradle Build Cache la nivel de pipeline și configurarea unui cache remote pe un stocaj comun. Timeout-ul pentru fiecare job trebuie setat pe baza timpului de construire așteptat — acest lucru previne procesele blocate.

Exemplu cu cache și pull policy

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

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