GitLab CI: essens, pipelines och kontinuerlig integration

Vad är GitLab CI?

GitLab CI är en del av den enhetliga DevSecOps-applikationen GitLab, som omfattar kontinuerlig integration, leverans och driftsättning. Systemet uppstod 2012 som ett separat projekt men integrerades sedan direkt i GitLab. Grundprincipen är konfiguration som kod (Configuration as Code) via filen .gitlab-ci.yml i rotkatalogen av repositoriet. GitLab CI är tillgängligt både i molnets SaaS-version och i en självhanterad installation.

För mobilutveckling erbjuder GitLab CI automatisering av byggande av APK och IPA, körning av instrumentella tester, statisk kodanalys, signering av appar och publicering i butiker. Plattformen stöder Docker-avbildningar för anpassade miljöer, vilket möjliggör förinstallation av Android SDK, NDK, Xcode och andra verktyg. Den inbyggda Container Registry förenklar lagring och distribution av avbildningar inom teamet.

GitLab CI-arkitektur: Runners, Pipelines och Stages

GitLab CI-arkitekturen består av tre nyckelkomponenter. GitLab Runner är agenten som utför jobben. Runners kan vara shared (tillhandahålls av GitLab), group (för en grupp projekt) och specific (för ett enskilt projekt). Varje runner registreras med angivande av executor: Shell, Docker, Kubernetes eller VirtualBox. GitLab Runner stöder automatisk skalning för att hantera toppbelastningar.

En pipeline är en samling stages som utförs sekventiellt. Inom en enda stage utförs jobb parallellt. Typisk struktur för ett mobilprojekt: build → test → deploy. Om ett jobb på stage test slutar med fel, startas inte deploy. Manuell start (when: manual) kan konfigureras för driftsättning. Även utlösare för multi-project pipelines stöds för komplexa CI/CD-scenarier mellan repositorier.

GitLab Runner-executors

Docker executor är den mest populära för CI/CD av mobila applikationer. Varje jobb startas i en ren Docker-container, vilket garanterar isolering och reproducerbarhet. För Android-byggen används avbildningen android-sdk med förinstallerat SDK, för iOS — macOS-runner med Shell executor.

.gitlab-ci.yml-konfiguration för mobilprojekt

Filen .gitlab-ci.yml definierar pipeline i YAML-format. Huvudsektioner: image (Docker-avbildning), stages (lista över faser), variables (miljövariabler), before_script (kommandon före varje jobb) och själva jobben med sektionerna script, artifacts, cache. GitLab CI stöder include — anslutning av externa YAML-filer för återanvändning av gemensamma konfigurationer mellan projekt.

Variables i GitLab CI kan ställas in på flera nivåer: globalt i UI, i konfigurationsfilen, i grupp- och projektinställningar. Prioriteten för variabler bestäms av hierarkin: trigger-variabler har högst prioritet, sedan CI/CD-variabler från UI, sedan från .gitlab-ci.yml. Variabler kan skyddas (protected), vilket gör dem tillgängliga endast för skyddade brancher och taggar.

Grundläggande variabler och avbildning

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/

Byggjobb med artefakter

Jobbet generate-apk bygger Gradle-projektet och sparar APK som en artefakt. Artefakter överförs mellan stages — deploy-jobbet kan använda APK från build. Lagringstiden för artefakter konfigureras via 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: viktiga skillnader

Vid val mellan GitLab CI och GitHub Actions för ett mobilprojekt är det viktigt att ta hänsyn till teamets infrastruktur. GitLab CI tillhandahåller en inbyggd Container Registry som kan användas för att lagra Docker-avbildningar med Android SDK. GitHub Actions förlitar sig på GitHub Packages eller externa register. GitLab har även inbyggd SAST (Static Application Security Testing) för kodanalys av sårbarheter.

GitLab CI erbjuder en mer flexibel modell för runners — stöder Kubernetes executor, automatisk skalning och anpassade avbildningar. GitHub Actions vinner i integration med GitHub-ekosystemet och actions-marknadsplatsen. GitLab CI kräver manuell konfiguration för många uppgifter som i GitHub Actions löses med en färdig action.

Ur CI/CD-perspektiv för mobilprojekt: GitLab CI är lämpligare för företag som redan använder GitLab Self-Managed och behöver självhostade runners med Docker/Kubernetes. GitHub Actions är bekvämare för små team på molnbaserat GitHub som värdesätter färdiga actions och enkel konfiguration.

Jämförelse av funktioner

Exempel på pipeline för Android-projekt

Den fullständiga pipelinen för Android omfattar: lint, enhetstester, byggande och driftsättning i Firebase App Distribution. Pipelinen använder en Docker-avbildning med Android SDK, Gradle-cachning och parallell exekvering av lint och tester i en stage. Detta tillvägagångssätt minskar den totala pipelinetiden eftersom lint- och testuppgifterna inte är beroende av varandra.

För iOS-projekt skiljer sig pipelinestrukturen på grund av behovet av en macOS-runner och kodsignering. En typisk iOS-pipeline omfattar: installation av CocoaPods eller SPM, körning av tester på simulatorn, arkivering av Xcode-projektet, export av IPA och uppladdning till TestFlight. GitLab CI för iOS använder macOS-runners — antingen GitLab SaaS macOS-runners med tidsbegränsningar eller en självhostad runner på Mac mini eller 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

Optimering av byggtid i GitLab CI

Optimering av mobila byggpipelines i GitLab CI kräver uppmärksamhet på detaljer. Korrekt konfiguration av cache och artifacts kan minska byggtiden flera gånger. För prestandaanalys tillhandahåller GitLab CI/CD Analytics — en instrumentpanel med mått på pipelinelängd, runner-belastning och flaskhalsar. Analysera dessa mått regelbundet för att hitta optimeringsmöjligheter. Inställningen resource_group blockerar parallell körning av en pipeline — användbart för att förebygga konflikter vid driftsättning.

Grenstrategin för CI är också viktig. Det rekommenderas att köra hela pipelinen endast för main- och release-grenar och för feature-grenar — endast lint och enhetstester. Detta sparar minuter av runners och påskyndar återkoppling till utvecklare. GitLab CI stöder workflow:rules — villkorliga regler för att inkludera eller exkludera jobb beroende på gren, ändrade filer eller miljövariabler.

Cachning av beroenden är det främsta sättet att påskynda. GitLab CI cachar .gradle, Pods och node_modules mellan körningar. Cache-nyckeln innehåller $CI_COMMIT_REF_SLUG eller hash av låsfilen. Byggtiden för ett Android-projekt minskar från 10–15 till 2–4 minuter med korrekt cachning. Cache kan vara distribuerad — GitLab stöder cache:key med återfall till tidigare nycklar.

En Docker-avbildning med förinstallerade verktyg sparar installationstid. Det rekommenderas att skapa en anpassad avbildning med Android SDK, NDK och önskad API-nivå. Parallell exekvering av jobb (lint, test, assemble) i olika stages minskar den totala pipelinetiden. Pull policies för avbildningar (if-not-present) påskyndar start av jobb. Även dependency proxy kan användas för cachning av avbildningar på GitLab-instansnivå.

En annan viktig aspekt av optimering är användning av artefakter mellan faser. Tunga filer APK och IPA är bättre att överföra via dependency än att bygga om i varje jobb. För stora projekt med tiotal moduler rekommenderas att aktivera Gradle Build Cache på pipelinenivå och konfigurera fjärrcache på en gemensam lagring. Timeout för varje jobb bör ställas in baserat på förväntad byggtid — detta förhindrar låsta processer.

Exempel med cachning och 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