GitLab — basis, mogelijkheden en CI/CD

Wat is GitLab?

GitLab — is een volledig DevOps-platform met open source onder MIT-licentie. In tegenstelling tot GitHub, dat verschillende diensten combineert via integraties, biedt GitLab één enkel hulpmiddel voor de hele levenscyclus van ontwikkeling: van codebeheer en code review tot CI/CD, monitoring, beveiliging en implementatie. Het platform heeft geen externe diensten nodig voor de meeste DevOps-taken.

De geschiedenis van GitLab begon in 2011 als een intern project van Oekraïense ontwikkelaars. De eerste openbare versie werd uitgebracht in september 2011, en in 2015 werd GitLab het eerste project op GitLab.com, waarmee cloudhosting werd gelanceerd. In 2017 onderging GitLab een pijnlijk maar leerzaam migratieproces — de verplaatsing van de volledige infrastructuur van Azure naar Google Cloud, die live werd uitgezonden en gedocumenteerd in een reeks artikelen.

De architectuur van GitLab bestaat uit drie hoofdcomponenten: GitLab Rails (webapplicatie in Ruby on Rails), GitLab Shell (verwerking van Git-bewerkingen via SSH) en Gitaly (gRPC-server voor toegang tot Git-gegevens). CI/CD wordt verzorgd door GitLab Runner — een aparte applicatie die op buildservers wordt geïnstalleerd en jobs uitvoert in geïsoleerde omgevingen (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipelines en runners

GitLab CI/CD — is een ingebouwd systeem voor continue integratie en levering, dat een belangrijk voordeel van het platform is. In tegenstelling tot GitHub Actions, was GitLab CI/CD vanaf het begin in de architectuur opgenomen en vereist het geen aparte configuratie: elk project krijgt automatisch CI/CD na toevoeging van het bestand .gitlab-ci.yml in de root van de repository.

Een pipeline (pipeline) bestaat uit fasen (stages) die sequentieel of parallel worden uitgevoerd: build → test → deploy. Elke fase bevat een of meerdere jobs die op runners worden uitgevoerd. Als een job in een fase met een fout eindigt, wordt de hele fase als failed gemarkeerd en worden volgende fasen standaard niet gestart. Hieronder staat een voorbeeld van een pipeline voor een mobiel project:

# .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 ondersteunt meerdere executors (uitvoerders): Docker (aanbevolen), Kubernetes, SSH, VirtualBox en Parallels. De populairste optie is de Docker-executor, die elke job in een aparte container uitvoert. Een runner kan worden geregistreerd als specifiek voor één project of als gedeeld (shared) voor de hele groep. GitLab.com biedt gratis shared runners met een limiet van 2000 minuten per maand.

Geavanceerde CI/CD-mogelijkheden

GitLab CI/CD ondersteunt handmatig starten (when: manual), vertraagd starten (when: delayed), parallelle uitvoering (parallel: 5), matrix (matrix), dynamische pipelines (child pipelines) en meerniveau-pipelines (parent-child). Dit maakt het mogelijk om complexe scenario’s te bouwen: bijvoorbeeld het dynamisch genereren van een pipeline voor elke module in een monorepository of het starten van parallelle builds voor verschillende Android-architecturen (arm64, x86_64).

GitLab versus GitHub: belangrijkste verschillen

GitLab en GitHub — de twee belangrijkste concurrenten op de markt van Git-platforms, maar hun filosofie en architectuur verschillen fundamenteel. GitHub richt zich op de open gemeenschap, het ecosysteem van integraties en sociale functies (forks, sterren). GitLab richt zich op de complete DevOps-cyclus en biedt alle tools uit de doos: van planning tot monitoring.

Het belangrijkste architectuurverschil: GitLab — is een enkele monolithische applicatie die de ontwikkelaar in zijn geheel installeert. Alle functies (CI/CD, Container Registry, Security Scanning, Pages) zijn ingebouwd en werken direct na installatie. GitHub — is een platform met een API, waar de meeste functies worden gerealiseerd via integratie met externe diensten: Travis CI, CircleCI, Jenkins, SonarQube. De onderstaande tabel vergelijkt de belangrijkste kenmerken:

De keuze tussen GitLab en GitHub hangt af van de behoeften van het team. Als prioriteit snelle implementatie met nulconfiguratie en een open gemeenschap is — kies dan GitHub. Als volledig beheer van infrastructuur, eigen hosting en ingebouwde beveiliging nodig is — heeft GitLab de voorkeur. Volgens de Stack Overflow-enquête (2024) gebruikt 90% van de ontwikkelaars GitHub, 33% — GitLab (vaak beide platforms tegelijk).

Self-Managed GitLab: installatie op eigen server

Self-Managed GitLab (voorheen On-Premises) maakt het mogelijk om het platform op uw eigen server te installeren en volledige controle te krijgen over gegevens, infrastructuur en beschikbaarheid. Dit is vooral belangrijk voor organisaties met compliance-eisen: financiële sector, overheidsinstellingen, medische organisaties waar gegevens niet op servers van derden kunnen worden opgeslagen.

Installatie van GitLab wordt ondersteund op Ubuntu, Debian, CentOS en via Docker. Het officiële Omnibus-pakket bevat alle componenten: webserver (NGINX), database (PostgreSQL), cache (Redis), Git-processor (Gitaly) en achtergrondprocessen. Minimale vereisten: 4 GB RAM en 2 CPU voor een team tot 100 personen. Voor grote installaties met hoge belasting wordt scheiding van componenten op aparte servers aanbevolen.

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

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

# Status bekijken
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab heeft geen CI/CD-minutenlimiet — alle runners zijn eigendom van de organisatie en hun kracht wordt alleen beperkt door de eigen hardware. Ook zijn Geo-replicatie voor regio’s, auditlogboeken, IP-blokkering en integratie met zakelijke LDAP/SAML-providers beschikbaar. GitLab brengt maandelijks (op de 22e) updates uit met nieuwe functies en beveiligingspatches.

Ingebouwde beveiligingstools van GitLab

Beveiliging in GitLab is ingebouwd op platformniveau en omvat meerdere scanners die in elke fase van de pipeline werken. SAST (Static Application Security Testing) analyseert de broncode op kwetsbaarheden zonder de applicatie uit te voeren, met ondersteuning voor meer dan 15 talen, waaronder Java, Kotlin, Swift, Python en JavaScript. DAST (Dynamic Application Security Testing) test de actieve webapplicatie van binnenuit op kwetsbaarheden.

Aanvullende tools: Container Scanning controleert Docker-images op kwetsbaarheden in de basislagen; Dependency Scanning analyseert projectafhankelijkheden en waarschuwt voor bekende CVE’s; Secret Detection vindt per ongeluk gecommitte API-sleutels, wachtwoorden en tokens; Fuzz Testing voert automatische tests uit met onjuiste gegevens om niet voor de hand liggende bugs te vinden. Alle scanresultaten worden weergegeven in een enkel Security Dashboard.

GitLab biedt ook Compliance — tools voor het voldoen aan wettelijke vereisten. Compliance Dashboard toont de nalevingsstatus van alle projecten, Audit Events registreert elke actie van beheerder en ontwikkelaar, en Compliance Frameworks maken het mogelijk om configuratiebeleid dwingend toe te passen voor bepaalde projectgroepen. Dit maakt GitLab een populaire keuze in bedrijfsomgevingen met strenge beveiligingseisen.

Container Registry en Dependency Proxy

GitLab Container Registry — is een ingebouwd Docker-register, geïntegreerd met CI/CD. Na het bouwen van een Docker-image in de pipeline kan deze onmiddellijk worden gepubliceerd in het Registry met behulp van de omgevingsvariabelen CI_REGISTRY en CI_REGISTRY_USER. Het Registry ondersteunt pull-through caching, tagging, opschoningsbeleid en kwetsbaarheidsscanning direct in het register.

Dependency Proxy — een mechanisme voor het cachen van containers en images van externe registers (Docker Hub, Quay, GCR). Wanneer de pipeline de image ubuntu:latest opvraagt, controleert GitLab eerst zijn eigen cache — als de image al is geladen, wordt deze niet opnieuw gedownload. Dit vermindert de belasting van externe registers, versnelt pipelines en beschermt tegen snelheidslimieten van Docker Hub.

Voor mobiele ontwikkelaars biedt GitLab GitLab Pages voor het hosten van documentatie en testrapporten. Na het uitvoeren van tests kunnen artefacten (HTML-rapporten, screenshots, logs) worden gepubliceerd als Pages en kan een link worden verkregen om naar het QA-team te sturen. Dit is handiger dan rapporten naar cloudopslag te uploaden, omdat alles wordt geplaatst binnen hetzelfde GitLab-project.

GitLab API en Webhooks

GitLab API (REST en GraphQL) biedt toegang tot alle bronnen van het platform: projecten, gebruikers, pipelines, Merge Requests, register. De API wordt gebruikt voor automatisering: een project maken van een sjabloon, een reviewer toewijzen, de pipelinestatus opvragen. Webhooks maken het mogelijk om HTTP-meldingen naar externe systemen te sturen bij gebeurtenissen: push, merge, aanmaken van Issue. Webhooks integreren met Mattermost, Slack, Telegram en interne monitoringssystemen.

GitLab Pages voor mobiele documentatie

GitLab Pages publiceert automatisch statische websites uit de repository. Voor mobiele projecten is Pages handig voor het plaatsen van API-documentatie, testdekkingsrapporten en lint-analyseresultaten. Publicatie vindt automatisch plaats na een succesvolle pipeline — het volstaat om in .gitlab-ci.yml een deploy-stap met publicatie naar Pages op te geven. Het resultaat is beschikbaar op https://namespace.gitlab.io/projectnaam.