GitLab CI: lényeg, pipeline-ok és folyamatos integráció

Mi az a GitLab CI?

A GitLab CI a GitLab egységes DevSecOps alkalmazásának része, amely magában foglalja a folyamatos integrációt, szállítást és telepítést. A rendszer 2012-ben jelent meg különálló projektként, de aztán közvetlenül integrálták a GitLabba. Az alapelv — konfiguráció kódként (Configuration as Code) a tár gyökérében található .gitlab-ci.yml fájlon keresztül. A GitLab CI elérhető mind a felhő SaaS verzióban, mind a self-managed telepítésben.

Mobilfejlesztéshez a GitLab CI automatizálja az APK és IPA építését, az instrumentális tesztek futtatását, a statikus kódelemzést, az alkalmazások aláírását és a boltokban történő közzétételt. A platform támogatja a Docker képeket egyedi környezetekhez, ami lehetővé teszi az Android SDK, NDK, Xcode és más eszközök előtelepítését. A beépített Container Registry egyszerűsíti a képek tárolását és terjesztését a csapaton belül.

A GitLab CI architektúrája: Runner-ek, Pipeline-ok és Stage-ek

A GitLab CI architektúrája három kulcsfontosságú összetevőből áll. A GitLab Runner az az ügynök, amely a job-okat végrehajtja. A runner-ek lehetnek shared (a GitLab által biztosítottak), group (projektcsoportok számára) és specific (egy projekt számára). Minden runner az executor megadásával regisztrál: Shell, Docker, Kubernetes vagy VirtualBox. A GitLab Runner támogatja az automatikus méretezést (auto-scaling) a csúcs terhelések kezeléséhez.

A pipeline a stage-ek gyűjteménye, amelyeket egymás után hajtanak végre. Egy stage-en belül a job-okat párhuzamosan hajtják végre. Tipikus struktúra mobil projekthez: build → test → deploy. Ha egy job a test stage-en hibával ér véget, a deploy nem indul el. Kézi indítás (when: manual) konfigurálható a telepítéshez. Támogatottak a multi-project pipelines triggerek is összetett CI/CD forgatókönyvekhez tárak között.

GitLab Runner executorok

A Docker executor a legnépszerűbb a mobilalkalmazások CI/CD-jéhez. Minden job tiszta Docker konténerben indul, ami garantálja az elkülönítést és a reprodukálhatóságot. Android építéshez az android-sdk kép előre telepített SDK-val, iOS-hez — macOS runner Shell executorral használatos.

.gitlab-ci.yml konfiguráció mobil projektekhez

A .gitlab-ci.yml fájl határozza meg a pipeline-t YAML formátumban. Fő szekciók: image (Docker kép), stages (fázisok listája), variables (környezeti változók), before_script (parancsok minden job előtt) és maguk a job-ok script, artifacts, cache szekciókkal. A GitLab CI támogatja az include-ot — külső YAML fájlok csatlakoztatását a közös konfigurációk újrafelhasználásához projektek között.

A variables a GitLab CI-ban több szinten állítható be: globálisan a UI-ban, a konfigurációs fájlban, a csoport és projekt beállításokban. A változók prioritását a hierarchia határozza meg: a trigger variables rendelkezik a legmagasabb prioritással, aztán a CI/CD variables a UI-ból, majd a .gitlab-ci.yml-ből. A változók védhetők (protected), ami csak védett branch-ek és tag-ek számára teszi elérhetővé őket.

Alapváltozók és kép

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/

Építési job artefaktumokkal

A generate-apk job felépíti a Gradle projektet, és APK-t ment artefaktumként. Az artefaktumok átadódnak a stage-ek között — a deploy job használhatja a build-ből származó APK-t. Az artefaktumok tárolási ideje az expire_in segítségével konfigurálható.

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

GitLab CI vs GitHub Actions: fő különbségek

A GitLab CI és a GitHub Actions közötti választáskor mobil projekthez fontos figyelembe venni a csapat infrastruktúráját. A GitLab CI beépített Container Registry-t biztosít, amely használható Docker képek tárolására Android SDK-val. A GitHub Actions a GitHub Packages-re vagy külső regiszterekre támaszkodik. A GitLab rendelkezik beépített SAST-tal (Static Application Security Testing) is a kód sebezhetőségek elemzéséhez.

A GitLab CI rugalmasabb runner modellt kínál — támogatja a Kubernetes executor-t, az automatikus méretezést és az egyedi képeket. A GitHub Actions a GitHub ökoszisztémával és az actions piactérrel való integrációban nyer. A GitLab CI kézi konfigurációt igényel sok olyan feladathoz, amelyek a GitHub Actions-ban egy kész action segítségével oldhatók meg.

CI/CD szempontból mobil projektekhez: a GitLab CI alkalmasabb azoknak a vállalatoknak, amelyek már GitLab Self-Managed-et használnak és self-hosted runner-eket igényelnek Docker/Kubernetes-szel. A GitHub Actions kényelmesebb a felhő GitHub-ot használó kis csapatoknak, akik értékelik a kész action-öket és az egyszerű konfigurációt.

Képességek összehasonlítása

Pipeline példa Android projekthez

A teljes pipeline Androidhoz tartalmazza: lint, egységteszteket, építést és telepítést a Firebase App Distribution-be. A pipeline használ egy Docker képet Android SDK-val, Gradle gyorsítótárat, és a lint és tesztek párhuzamos végrehajtását egy stage-ben. Ez a megközelítés csökkenti a teljes pipeline időt, mert a lint és teszt feladatok nem függenek egymástól.

iOS projektek esetén a pipeline struktúra eltér a macOS runner és a kódaláírás szükségessége miatt. A tipikus iOS pipeline tartalmazza: CocoaPods vagy SPM telepítését, tesztek futtatását szimulátoron, az Xcode projekt archiválását, IPA exportálást és feltöltést a TestFlightba. A GitLab CI iOS-hez macOS runner-eket használ — vagy GitLab SaaS macOS runner-eket időkorlátozásokkal, vagy self-hosted runner-t Mac mini-n vagy MacStadium-on.

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

Építési idő optimalizálása a GitLab CI-ban

A mobil építési pipeline-ok optimalizálása a GitLab CI-ban részletekre való odafigyelést igényel. A cache és artifacts helyes konfigurációja többszörösére csökkentheti az építési időt. A teljesítményelemzéshez a GitLab CI/CD Analytics-t biztosít — egy irányítópultot a pipeline-ok időtartamának, a runner-ek terhelésének és a szűk keresztmetszetek metrikáival. Elemezze ezeket a metrikákat rendszeresen az optimalizálási lehetőségek megtalálásához. A resource_group beállítás blokkolja egy pipeline párhuzamos futtatását — ez hasznos az ütközések megelőzésére telepítéskor.

A CI branch stratégia is fontos. Ajánlott a teljes pipeline-t csak a main és release branch-ekre futtatni, a feature branch-ekre pedig csak lint és egységteszteket. Ez runner perceket takarít meg és felgyorsítja a fejlesztők visszajelzését. A GitLab CI támogatja a workflow:rules-t — feltételüfüggő szabályokat a job-ok be- vagy kizárására branch, módosított fájlok vagy környezeti változók alapján.

A függőségek gyorsítótárazása a gyorsítás fő módja. A GitLab CI cache-eli a .gradle, Pods és node_modules könyvtárakat a futtatások között. A cache kulcs tartalmazza a $CI_COMMIT_REF_SLUG-ot vagy a lock fájl hash-ját. Az Android projekt építési ideje 10–15 percről 2–4 percre csökken megfelelő gyorsítótárazással. A cache elosztott lehet — a GitLab támogatja a cache:key-t korábbi kulcsokra történő visszaállással.

A Docker kép előre telepített eszközökkel időt takarít meg a telepítésen. Ajánlott egyedi képet létrehozni Android SDK-val, NDK-val és a szükséges API szinttel. A job-ok (lint, test, assemble) párhuzamos végrehajtása különböző stage-ekben csökkenti a teljes pipeline időt. A pull policy a képekhez (if-not-present) gyorsítja a job-ok indítását. A dependency proxy használható a képek cache-elésére GitLab példány szinten.

Az optimalizálás másik fontos aspektusa az artefaktumok használata a fázisok között. A nehéz fájlokat APK és IPA jobb dependency-n keresztül átadni, mint minden job-ban újraépíteni. Nagy projektekhez tíz modullal ajánlott a Gradle Build Cache bekapcsolása pipeline szinten és a remote cache konfigurálása közös tárolón. A timeout minden job-hoz a várható építési idő alapján állítandó be — ez megakadályozza a lefagyott folyamatokat.

Példa gyorsítótárazással és pull policy-val

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

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