GitLab — grunder, funktioner och CI/CD

Vad är GitLab?

GitLab — är en fullständig DevOps-plattform med öppen källkod under MIT-licens. Till skillnad från GitHub, som kombinerar olika tjänster genom integrationer, erbjuder GitLab ett enda verktyg för hela utvecklingslivscykeln: från kodhantering och kodgranskning till CI/CD, övervakning, säkerhet och driftsättning. Plattformen kräver inga tredjepartstjänster för de flesta DevOps-uppgifter.

Historien om GitLab började 2011 som ett internt projekt av ukrainska utvecklare. Den första offentliga versionen släpptes i september 2011, och 2015 blev GitLab det första projektet på GitLab.com och lanserade molnhosting. 2017 genomförde GitLab en smärtsam men lärorik migreringsprocess — flytten av hela infrastrukturen från Azure till Google Cloud, som sändes live och dokumenterades i en serie inlägg.

Arkitekturen i GitLab består av tre huvudkomponenter: GitLab Rails (webbapplikation i Ruby on Rails), GitLab Shell (hantering av Git-operationer via SSH) och Gitaly (gRPC-server för åtkomst till Git-data). CI/CD tillhandahålls genom GitLab Runner — en separat applikation som installeras på byggservrar och utför job i isolerade miljöer (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipelines och runners

GitLab CI/CD — är ett inbyggt system för kontinuerlig integration och leverans, som är en viktig fördel med plattformen. Till skillnad från GitHub Actions var GitLab CI/CD inbyggt i arkitekturen från början och kräver ingen separat konfiguration: varje projekt får automatiskt CI/CD efter att filen .gitlab-ci.yml har lagts till i reporoten.

En pipeline (pipeline) består av steg (stages) som utförs sekventiellt eller parallellt: build → test → deploy. Varje steg innehåller ett eller flera job som utförs på runners. Om ett job i ett steg slutar med fel markeras hela steget som failed, och efterföljande steg startas inte som standard. Nedan finns ett exempel på en pipeline för ett mobilprojekt:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner stöder flera executor (utförare): Docker (rekommenderas), Kubernetes, SSH, VirtualBox och Parallels. Det populäraste alternativet är Docker-utföraren, som kör varje job i en separat container. En runner kan registreras som specifik för ett projekt eller som delad (shared) för hela gruppen. GitLab.com erbjuder gratis delade runners med en gräns på 2000 minuter per månad.

Avancerade CI/CD-funktioner

GitLab CI/CD stöder manuell start (when: manual), fördröjd start (when: delayed), parallell exekvering (parallel: 5), matris (matrix), dynamiska pipelines (child pipelines) och flernivåpipelines (parent-child). Detta gör det möjligt att bygga komplexa scenarier: till exempel att dynamiskt generera en pipeline för varje modul i ett monorepository eller köra parallella byggen för olika Android-arkitekturer (arm64, x86_64).

GitLab vs GitHub: viktiga skillnader

GitLab och GitHub — de två största konkurrenterna på marknaden för Git-plattformar, men deras filosofi och arkitektur skiljer sig fundamentalt. GitHub satsar på öppen gemenskap, ekosystem av integrationer och sociala funktioner (forks, stjärnor). GitLab fokuserar på den omfattande DevOps-cykeln och tillhandahåller alla verktyg direkt ur lådan: från planering till övervakning.

Den huvudsakliga arkitektoniska skillnaden: GitLab — är en enda monolitisk applikation som utvecklaren installerar i sin helhet. Alla funktioner (CI/CD, Container Registry, Security Scanning, Pages) är inbyggda och fungerar direkt efter installation. GitHub — är en plattform med API, där de flesta funktionerna implementeras genom integration med tredjepartstjänster: Travis CI, CircleCI, Jenkins, SonarQube. Tabellen nedan jämför viktiga egenskaper:

Valet mellan GitLab och GitHub beror på teamets behov. Om prioriteringen är snabb driftsättning med noll konfiguration och öppen gemenskap — välj GitHub. Om fullständig kontroll över infrastruktur, egen hosting och inbyggd säkerhet behövs — är GitLab att föredra. Enligt Stack Overflow-undersökningen (2024) använder 90% av utvecklarna GitHub, 33% — GitLab (ofta båda plattformarna samtidigt).

Self-Managed GitLab: installation på egen server

Self-Managed GitLab (tidigare On-Premises) gör det möjligt att installera plattformen på egen server och få fullständig kontroll över data, infrastruktur och tillgänglighet. Detta är särskilt viktigt för organisationer med efterlevnadskrav: finanssektorn, statliga myndigheter, medicinska organisationer, där data inte kan lagras på tredjepartsservrar.

Installation av GitLab stöds på Ubuntu, Debian, CentOS och via Docker. Det officiella Omnibus-paketet innehåller alla komponenter: webbserver (NGINX), databas (PostgreSQL), cache (Redis), Git-processor (Gitaly) och bakgrundsprocesser. Minimikrav: 4 GB RAM och 2 CPU för ett team på upp till 100 personer. För stora installationer med hög belastning rekommenderas separering av komponenter på olika servrar.

# Installera GitLab CE på Ubuntu via Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Installera paketet
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Visa status
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab har inga begränsningar för CI/CD-minuter — alla runners tillhör organisationen och deras kraft begränsas endast av den egna hårdvaran. Även Geo-replikering för regioner, revisionsloggar, IP-blockering och integration med företags LDAP/SAML-leverantörer är tillgängliga. GitLab släpper uppdateringar varje månad (den 22:a) med nya funktioner och säkerhetskorrigeringar.

Inbyggda säkerhetsverktyg i GitLab

Säkerhet i GitLab är inbyggd på plattformsnivå och inkluderar flera skannrar som arbetar i varje steg av pipelinen. SAST (Static Application Security Testing) analyserar källkoden för sårbarheter utan att köra applikationen och stöder över 15 språk, inklusive Java, Kotlin, Swift, Python och JavaScript. DAST (Dynamic Application Security Testing) testar den körda webbapplikationen för sårbarheter inifrån.

Ytterligare verktyg: Container Scanning kontrollerar Docker-avbildningar för sårbarheter i baslagren; Dependency Scanning analyserar projektets beroenden och varnar för kända CVE; Secret Detection hittar oavsiktligt incheckade API-nycklar, lösenord och tokens; Fuzz Testing utför automatisk testning med ogiltiga data för att hitta icke uppenbara buggar. Alla skanningsresultat visas i en gemensam Security Dashboard.

GitLab tillhandahåller även Compliance — verktyg för att uppfylla regulatoriska krav. Compliance Dashboard visar efterlevnadsstatus för alla projekt, Audit Events loggar varje åtgärd av administratör och utvecklare, och Compliance Frameworks gör det möjligt att tvingande tillämpa konfigurationspolicyer för specifika projektgrupper. Detta gör GitLab till ett populärt val i företagsmiljöer med strikta säkerhetskrav.

Container Registry och Dependency Proxy

GitLab Container Registry — är ett inbyggt Docker-register integrerat med CI/CD. Efter att ha byggt en Docker-avbildning i pipelinen kan den omedelbart publiceras i Registry med hjälp av miljövariablerna CI_REGISTRY och CI_REGISTRY_USER. Registry stöder pull-through-cache, taggning, rensningspolicyer och sårbarhetsskanning direkt i registret.

Dependency Proxy — en mekanism för att cachelagra containrar och avbildningar från externa register (Docker Hub, Quay, GCR). När pipelinen begär avbildningen ubuntu:latest kontrollerar GitLab först sin cache — om avbildningen redan har laddats laddas den inte ner igen. Detta minskar belastningen på externa register, påskyndar pipelines och skyddar mot hastighetsbegränsningar från Docker Hub.

För mobila utvecklare tillhandahåller GitLab GitLab Pages för hosting av dokumentation och testrapporter. Efter att testerna har körts kan artefakter (HTML-rapporter, skärmdumpar, loggar) publiceras som Pages och en länk kan erhållas för att skicka till QA-teamet. Detta är bekvämare än att ladda upp rapporter till molnlagring, eftersom allt placeras inom samma GitLab-projekt.

GitLab API och Webhooks

GitLab API (REST och GraphQL) ger tillgång till alla resurser på plattformen: projekt, användare, pipelines, Merge Request, register. API:et används för automatisering: skapa projekt från mall, tilldela granskare, hämta pipelinestatus. Webhooks gör det möjligt att skicka HTTP-meddelanden till externa system vid händelser: push, merge, skapande av Issue. Webhooks integreras med Mattermost, Slack, Telegram och interna övervakningssystem.

GitLab Pages för mobil dokumentation

GitLab Pages publicerar automatiskt statiska webbplatser från repositoryt. För mobila projekt är Pages användbart för att placera API-dokumentation, testtäckningsrapporter och resultat av lint-analys. Publicering sker automatiskt efter en lyckad pipeline — det räcker att ange i .gitlab-ci.yml ett deploy-steg med publicering till Pages. Resultatet är tillgängligt på adressen https://namespace.gitlab.io/projektnamn.