GitLab CI: podstata, pipeline a kontinuální integrace

Co je GitLab CI?

GitLab CI je součástí jednotné DevSecOps aplikace GitLab, zahrnující kontinuální integraci, doručování a nasazení. Systém se objevil v roce 2012 jako samostatný projekt, ale poté byl přímo integrován do GitLabu. Základní princip — konfigurace jako kód (Configuration as Code) prostřednictvím souboru .gitlab-ci.yml v kořeni repozitáře. GitLab CI je dostupný jak v cloudové SaaS verzi, tak v self-managed instalaci.

Pro mobilní vývoj nabízí GitLab CI automatizaci sestavení APK a IPA, spouštění instrumentálních testů, statickou analýzu kódu, podepisování aplikací a publikování v obchodech. Platforma podporuje Docker obrazy pro vlastní prostředí, což umožňuje předinstalaci Android SDK, NDK, Xcode a dalších nástrojů. Vestavěný Container Registry zjednodušuje ukládání a distribuci obrazů v rámci týmu.

Architektura GitLab CI: Runners, Pipelines a Stages

Architektura GitLab CI se skládá ze tří klíčových komponent. GitLab Runner je agent, který provádí joby. Runners mohou být shared (poskytované GitLabem), group (pro skupinu projektů) a specific (pro jeden projekt). Každý runner se registruje s uvedením executoru: Shell, Docker, Kubernetes nebo VirtualBox. GitLab Runner podporuje auto-škálování pro zpracování špičkových zatížení.

Pipeline je soubor stages prováděných sekvenčně. Uvnitř jedné stage jsou joby prováděny paralelně. Typická struktura pro mobilní projekt: build → test → deploy. Pokud job na stage test skončí chybou, deploy se nespustí. Lze nakonfigurovat ruční spuštění (when: manual) pro nasazení. Jsou také podporovány triggery multi-project pipelines pro komplexní CI/CD scénáře mezi repozitáři.

Executory GitLab Runner

Docker executor je nejoblíbenější pro CI/CD mobilních aplikací. Každý job je spuštěn v čistém Docker kontejneru, což zaručuje izolaci a reprodukovatelnost. Pro Android sestavení se používá obraz android-sdk s předinstalovaným SDK, pro iOS — macOS runner s Shell executorem.

Konfigurace .gitlab-ci.yml pro mobilní projekty

Soubor .gitlab-ci.yml definuje pipeline ve formátu YAML. Hlavní sekce: image (Docker obraz), stages (seznam fází), variables (proměnné prostředí), before_script (příkazy před každým jobem) a samotné joby s sekcemi script, artifacts, cache. GitLab CI podporuje include — připojení externích YAML souborů pro opětovné použití sdílených konfigurací mezi projekty.

Variables v GitLab CI mohou být nastaveny na několika úrovních: globálně v UI, v konfiguračním souboru, v nastavení skupiny a projektu. Priorita proměnných je určena hierarchií: trigger variables mají nejvyšší prioritu, poté CI/CD variables z UI, poté z .gitlab-ci.yml. Proměnné lze chránit (protected), což je zpřístupní pouze pro chráněné branche a tagy.

Základní proměnné a obraz

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 sestavení s artefakty

Job generate-apk sestaví Gradle projekt a uloží APK jako artefakt. Artefakty jsou předávány mezi stages — deploy job může použít APK z build. Doba uchování artefaktů je konfigurována pomocí 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: klíčové rozdíly

Při výběru mezi GitLab CI a GitHub Actions pro mobilní projekt je důležité zvážit infrastrukturu týmu. GitLab CI poskytuje vestavěný Container Registry, který lze použít pro ukládání Docker obrazů s Android SDK. GitHub Actions se spoléhá na GitHub Packages nebo externí registry. GitLab má také vestavěný SAST (Static Application Security Testing) pro analýzu kódu na zranitelnosti.

GitLab CI nabízí flexibilnější model runners — podporuje Kubernetes executor, auto-škálování a vlastní obrazy. GitHub Actions vítězí v integraci s ekosystémem GitHub a marketplace akcí. GitLab CI vyžaduje ruční konfiguraci pro mnoho úkolů, které jsou v GitHub Actions řešeny hotovou akcí.

Z hlediska CI/CD pro mobilní projekty: GitLab CI je vhodnější pro společnosti, které již používají GitLab Self-Managed a vyžadují self-hosted runners s Docker/Kubernetes. GitHub Actions je pohodlnější pro malé týmy na cloudovém GitHubu, které oceňují hotové akce a jednoduchost nastavení.

Srovnání možností

Příklad pipeline pro Android projekt

Plný pipeline pro Android zahrnuje: lint, jednotkové testy, sestavení a nasazení do Firebase App Distribution. Pipeline používá Docker obraz s Android SDK, cachování Gradle a paralelní provádění lint a testů v jedné stage. Tento přístup zkracuje celkový čas pipeline, protože úkoly lint a test na sobě nezávisí.

Pro iOS projekty se struktura pipeline liší kvůli potřebě macOS runneru a podepisování kódu. Typický iOS pipeline zahrnuje: instalaci CocoaPods nebo SPM, spuštění testů na simulátoru, archivaci Xcode projektu, export IPA a nahrání do TestFlight. GitLab CI pro iOS používá macOS runners — buď GitLab SaaS macOS runners s časovými omezeními, nebo self-hosted runner na Mac mini nebo 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

Optimalizace doby sestavení v GitLab CI

Optimalizace pipeline mobilního sestavení v GitLab CI vyžaduje pozornost k detailům. Správná konfigurace cache a artifacts umožňuje několikanásobně zkrátit dobu sestavení. Pro analýzu výkonu poskytuje GitLab CI/CD Analytics — dashboard s metrikami délky pipeline, zatížení runners a úzkých míst. Analyzujte tyto metriky pravidelně, abyste našli příležitosti pro optimalizaci. Nastavení resource_group blokuje paralelní spuštění jedné pipeline — užitečné pro prevenci konfliktů při nasazení.

Důležitá je také strategie větví pro CI. Doporučuje se spouštět plný pipeline pouze pro main a release větve a pro feature větve — pouze lint a jednotkové testy. To šetří minuty runners a zrychluje zpětnou vazbu vývojářům. GitLab CI podporuje workflow:rules — podmínečná pravidla pro zahrnutí nebo vyloučení jobů v závislosti na větvi, změněných souborech nebo proměnných prostředí.

Cachování závislostí je hlavním způsobem zrychlení. GitLab CI cachuje .gradle, Pods a node_modules mezi spuštěními. Klíč cache obsahuje $CI_COMMIT_REF_SLUG nebo hash lock souboru. Doba sestavení Android projektu se při správném cachování sníží z 10–15 na 2–4 minuty. Cache může být distribuovaná — GitLab podporuje cache:key s fallbackem na předchozí klíče.

Docker obraz s předinstalovanými nástroji šetří čas instalace. Doporučuje se vytvořit vlastní obraz s Android SDK, NDK a požadovanou úrovní API. Paralelní provádění jobů (lint, test, assemble) v různých stages zkracuje celkový čas pipeline. Pull policies pro obrazy (if-not-present) zrychlují spouštění jobů. Lze také použít dependency proxy pro cachování obrazů na úrovni GitLab instance.

Dalším důležitým aspektem optimalizace je použití artefaktů mezi fázemi. Těžké soubory APK a IPA je lepší předávat pomocí dependency, než znovu sestavovat v každém jobu. Pro velké projekty s desítkami modulů se doporučuje povolit Gradle Build Cache na úrovni pipeline a nakonfigurovat remote cache na sdíleném úložišti. Časový limit (timeout) pro každý job by měl být nastaven na základě očekávané doby sestavení — to zabraňuje zaseknutým procesům.

Příklad s cachováním a 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