18 Code Review mit GitLab: Merge Requests und Qualitätssicherung

Nachdem wir die fundamentalen Git-Konzepte und allgemeinen Best Practices behandelt haben, wenden wir uns nun GitLab als konkreter Plattform zu. Dieses Kapitel fokussiert auf Merge Requests – GitLabs Mechanismus für Code Review und Integration – und die spezifischen Features, die GitLab für Qualitätssicherung und Kollaboration bietet.

Merge Requests (MRs) sind GitLabs Äquivalent zu GitHubs Pull Requests. Die Konzepte sind identisch, aber GitLab bietet zusätzliche Integrationsmöglichkeiten mit CI/CD, Security-Scanning und Approval-Workflows, die wir im Detail betrachten werden.

18.1 Von Git zu GitLab: Der Übergang zur Plattform

Bisher haben wir Git als verteiltes Versionskontrollsystem behandelt – ein Tool, das lokal und auf jedem Server läuft. GitLab ist eine Plattform um Git herum, die zusätzliche Funktionen bietet:

Weboberfläche für Repository-Management
Merge Requests für strukturierte Code-Integration
CI/CD Pipelines für Automatisierung
Issue Tracking für Projektmanagement
Security Scanning für Vulnerabilities
Container Registry für Docker Images
Package Registry für Artefakte

Git selbst kennt keine “Merge Requests”. Das ist eine Abstraktion der Hosting-Plattform. Technisch ist ein Merge Request eine Kombination aus: - Einem Branch (der zu mergende Code) - Metadaten (Beschreibung, Assignees, Labels) - Diskussionen (Kommentare, Reviews) - CI/CD Pipelines (automatisierte Checks) - Approval-State (wer hat genehmigt)

Alles außer dem Branch ist GitLab-spezifisch und liegt nicht in .git/, sondern in GitLabs Datenbank.

18.2 Anatomie eines GitLab Merge Requests

18.2.1 Erstellung: Von der Kommandozeile zur Weboberfläche

Der typische Workflow:

# 1. Feature-Branch erstellen
git checkout -b feature/payment-gateway

# 2. Entwickeln, committen
git add .
git commit -m "feat(payment): add Stripe integration"

# 3. Branch pushen
git push origin feature/payment-gateway

Nach dem Push zeigt GitLab automatisch einen Link zum Erstellen eines Merge Requests:

remote: 
remote: To create a merge request for feature/payment-gateway, visit:
remote:   https://gitlab.com/myproject/-/merge_requests/new?merge_request[source_branch]=feature/payment-gateway

Alternativ: Direkt in der GitLab-Weboberfläche unter “Merge Requests” → “New merge request”.

18.2.2 MR-Komponenten

Ein vollständiger Merge Request besteht aus:

Header: - Titel: Klar, beschreibend (oft aus erstem Commit übernommen) - Source Branch: Der Branch mit Änderungen (feature/payment-gateway) - Target Branch: Wohin mergen (main, develop)

Body: - Beschreibung: Markdown-formatiert, erklärt “Warum” und “Was” - Issue-Verlinkung: Closes #123, Related to #456 - Checklists: - [ ] Tests added, - [ ] Docs updated

Sidebar: - Assignee: Wer ist verantwortlich - Reviewers: Wer soll reviewen - Labels: bug, feature, high-priority - Milestone: Sprint, Release-Version - Approval Status: X von Y Approvals

Tabs: - Overview: Beschreibung, Diskussion - Commits: Alle Commits im Branch - Changes: Unified Diff, Side-by-Side View - Pipelines: CI/CD Status - Security: SAST, DAST, Dependency Scan Ergebnisse

18.2.3 Template für konsistente MRs

.gitlab/merge_request_templates/Default.md:

## Problem
<!-- Welches Problem löst dieser MR? -->

## Solution
<!-- Wie wird das Problem gelöst? -->

## Changes
<!-- Technische Änderungen, kurz aufgelistet -->
- 
- 

## Testing
<!-- Wie wurde getestet? -->
- [ ] Unit Tests
- [ ] Integration Tests
- [ ] Manual Testing

## Screenshots / Videos
<!-- Falls UI-Änderungen -->

## Checklist
- [ ] Tests hinzugefügt/aktualisiert
- [ ] Dokumentation aktualisiert
- [ ] Keine Breaking Changes (oder dokumentiert)
- [ ] CI Pipeline grün
- [ ] Ready for Review

Closes #

Bei MR-Erstellung wird dieses Template automatisch eingefügt. Fördert Konsistenz und Vollständigkeit.

18.3 GitLab CI/CD Integration: Pipelines in Merge Requests

Der mächtigste Aspekt von GitLab MRs: automatisierte CI/CD Pipelines laufen bei jedem Push.

18.3.1 Merge Request Pipelines

In .gitlab-ci.yml können Pipeline-Jobs spezifisch für MRs konfiguriert werden:

stages:
  - build
  - test
  - security
  - deploy

# Läuft bei allen Commits
build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

# Läuft bei allen Commits
test:
  stage: test
  script:
    - npm test
  coverage: '/Lines\s*:\s*(\d+\.\d+)%/'

# Nur in Merge Requests
test:integration:
  stage: test
  script:
    - npm run test:integration
  only:
    - merge_requests

# Security Scanning nur in MRs
security:sast:
  stage: security
  image: returntocorp/semgrep
  script:
    - semgrep --config auto --json -o sast-report.json
  artifacts:
    reports:
      sast: sast-report.json
  only:
    - merge_requests

# Deploy Preview nur in MRs
deploy:preview:
  stage: deploy
  script:
    - deploy.sh $CI_MERGE_REQUEST_IID
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.preview.example.com
    on_stop: stop_preview
  only:
    - merge_requests

stop_preview:
  stage: deploy
  script:
    - cleanup.sh $CI_MERGE_REQUEST_IID
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  only:
    - merge_requests

18.3.2 MR-spezifische Variablen

GitLab stellt Umgebungsvariablen für MR-Kontext bereit:

print_mr_info:
  script:
    - echo "MR IID: $CI_MERGE_REQUEST_IID"
    - echo "MR Title: $CI_MERGE_REQUEST_TITLE"
    - echo "Source Branch: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME"
    - echo "Target Branch: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME"
    - echo "Author: $GITLAB_USER_EMAIL"
  only:
    - merge_requests

Nützlich für dynamische Preview-URLs, Benachrichtigungen, Kontext-spezifische Deployments.

18.3.3 Pipeline-Status als Merge-Blocker

GitLab kann MRs nur mergen lassen, wenn Pipeline erfolgreich:

Projekt-Einstellungen → Merge Requests → Merge Checks: - ☑ Pipelines must succeed - ☑ All threads must be resolved - ☑ Status checks must pass

Pipeline fehlgeschlagen → Merge-Button disabled. Erzwingt Qualität.

18.3.4 Code Quality Reports

GitLab kann Code Quality Metriken aus der Pipeline extrahieren:

code_quality:
  stage: test
  image: docker:stable
  services:
    - docker:dind
  script:
    - docker run --rm 
        --volume "$PWD":/code 
        --volume /var/run/docker.sock:/var/run/docker.sock 
        codeclimate/codeclimate analyze -f json > code-quality.json
  artifacts:
    reports:
      codequality: code-quality.json

GitLab zeigt Code Quality-Änderungen direkt im MR:

Code Quality
3 issues found (-2 from target branch)

▲ Complexity increased in calculateTotal() (from 5 to 12)
▼ Duplication removed in UserService
✓ ESLint violations reduced by 5

Reviewer sehen auf einen Blick, ob Code-Qualität besser oder schlechter wurde.

18.4 Approval Rules: Formale Review-Workflows

GitLab bietet Approval Rules: Definiere, wer wieviele Approvals geben muss, bevor ein MR merged werden kann.

18.4.1 Einfache Approval Rule

Projekt-Einstellungen → Merge Requests → Approval Rules:

Rule: Default
Approvals required: 2
Eligible Approvers: All project members

Jeder MR braucht 2 Approvals von beliebigen Projekt-Mitgliedern.

18.4.2 Code Owner Approvals

.gitlab/CODEOWNERS:

# Backend Team muss Backend-Änderungen approven
/backend/** @backend-team

# Frontend Team muss Frontend-Änderungen approven
/frontend/** @frontend-team

# Security Team muss Auth-Änderungen approven
/backend/auth/** @security-team

# Tech Lead muss CI/CD-Änderungen approven
.gitlab-ci.yml @tech-lead

Approval Rule:

Rule: Code Owners
Approvals required: 1 per code owner
Code Owner Approval: Required

Ein MR, der /backend/auth/ ändert, braucht Approval von: 1. Jemand aus @backend-team 2. Jemand aus @security-team

18.4.3 Conditional Approval Rules

Projekt-Einstellungen → Merge Requests → Approval Rules → Add approval rule:

Rule Name: High Risk Changes
Target Branch: main
Files: *.sql, database/migrations/*
Approvals required: 3
Eligible Approvers: @database-admins

MRs mit Database-Migrations brauchen 3 Approvals von Database-Admins. Automatisch detektiert.

18.4.4 Security Approval Gate

Rule: Security Review
Approvals required: 1
Eligible Approvers: @security-team
Trigger: On Security Vulnerability found

Wenn SAST/DAST/Dependency Scan Vulnerabilities findet → Security Team muss approven.

18.5 Code Review Features: GitLabs Werkzeuge

18.5.1 Inline Code Review

GitLab bietet mehrere View-Modi für Diffs:

Inline View: Alte und neue Version untereinander

- const timeout = 30
+ const timeout = 60

Side-by-Side View: Alte und neue Version nebeneinander (besser für große Änderungen)

Kommentare: Click auf Zeile → Kommentar schreiben - Single Line Comments: Kommentar zu einer Zeile - Multi Line Comments: Kommentar zu Bereich (Zeile X bis Y) - Discussions: Threads mit Replies - Resolvable Threads: “Resolve”-Button, Tracking von offenen Punkten

18.5.2 Suggestions: Änderungen vorschlagen

Reviewer können direkte Code-Änderungen vorschlagen:

```suggestion
const timeout = 60;
`` `

Author kann Suggestion mit einem Click übernehmen → automatisch committed. Beschleunigt Review-Zyklen.

18.5.3 Review Summary

GitLab zeigt Review-Status prominent:

Reviews
✓ Approved by @jane (2 hours ago)
⏳ Pending from @bob
⏳ Pending from @alice

Discussions
5 threads (2 unresolved)

Klar ersichtlich, wer noch reviewen muss, welche Diskussionen offen sind.

18.5.4 Quick Actions

In Kommentaren können Quick Actions genutzt werden:

/approve          - MR approven
/unapprove        - Approval zurückziehen
/assign @user     - User assignen
/unassign @user   - User unassignen
/label ~bug       - Label hinzufügen
/unlabel ~bug     - Label entfernen
/milestone %v1.0  - Milestone setzen
/merge            - Auto-merge aktivieren (wenn Checks passen)
/draft            - Als Draft markieren
/ready            - Draft-Status entfernen

Schnelle Aktionen ohne UI-Navigation.

18.6 Security Scanning: Automatisierte Vulnerability Detection

GitLab bietet integrierte Security-Scanner (Ultimate-Tier oder via Open-Source-Tools).

18.6.1 SAST (Static Application Security Testing)

Analysiert Source Code auf bekannte Vulnerabilities:

include:
  - template: Security/SAST.gitlab-ci.yml

# Auto-detektiert Sprache (JavaScript, Python, Go, etc.)
# Läuft automatisch in MRs

GitLab zeigt Ergebnisse im MR:

Security Scanning
1 new vulnerability (1 high, 0 medium, 0 low)

HIGH: SQL Injection in UserController.getUser()
File: backend/controllers/UserController.js:45
CWE-89: SQL Injection

Recommendation: Use parameterized queries

Security Team kann dann gezielt reviewen.

18.6.2 Dependency Scanning

Scannt Dependencies auf bekannte CVEs:

include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml

Zeigt verwundbare Packages:

Dependency Scanning
3 vulnerabilities detected

HIGH: lodash 4.17.20 (CVE-2021-23337)
Update to: 4.17.21

MEDIUM: express 4.17.1 (CVE-2022-24999)
Update to: 4.18.2

18.6.3 DAST (Dynamic Application Security Testing)

Testet laufende Applikation (in Preview-Environment):

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_WEBSITE: https://$CI_COMMIT_REF_SLUG.preview.example.com

Findet Runtime-Vulnerabilities (XSS, CSRF, etc.).

18.6.4 Security Dashboard

GitLab aggregiert alle Security-Findings:

Security & Compliance → Vulnerability Report: - Alle Vulnerabilities aus SAST, DAST, Dependency Scanning - Status: New, Confirmed, Dismissed, Resolved - Assignees für Remediation - Tracking über Zeit

18.7 Auto-Merge und Merge Trains

18.7.1 Auto-Merge

Aktiviere Auto-Merge auf einem MR:

✓ All checks passed
✓ 2 Approvals received
✓ No unresolved threads

[Enable Auto-Merge]

MR wird automatisch gemerged, sobald alle Bedingungen erfüllt. Nützlich, wenn man auf letzte Pipeline wartet.

18.7.2 Merge Trains (GitLab Premium)

Problem: Mehrere MRs gleichzeitig ready. Alle sind gegen main getestet. Aber nach erstem Merge ist main anders → andere MRs könnten nun Probleme haben.

Merge Trains: GitLab mergt MRs sequenziell, testet jeden gegen den vorherigen.

Merge Train:
1. MR #123 → Testing against main
2. MR #124 → Testing against main + MR #123
3. MR #125 → Testing against main + MR #123 + MR #124

Wenn MR #123 fehlschlägt, wird er aus Train entfernt, #124 und #125 bleiben. Verhindert kaputte main-Historie.

18.8 Draft Merge Requests: Work in Progress

MRs als “Draft” oder “WIP” markieren:

Methode 1: Titel beginnt mit Draft: oder WIP:

Draft: Add payment gateway integration

Methode 2: Quick Action /draft

Effekte: - Badge “Draft” deutlich sichtbar - Merge-Button disabled - Signalisiert: “Noch nicht fertig, aber Feedback willkommen”

Nutzung: Früh öffnen für Visibility, Diskussion, frühe Reviews. Wenn fertig: /ready → Draft-Status entfernt.

18.9 Merge Request Dependencies

MRs können abhängig voneinander sein:

In MR-Beschreibung:

## Dependencies
Depends on !123
Blocks !125

GitLab zeigt abhängige MRs prominent. Hilft, Merge-Reihenfolge zu planen.

18.10 Review Apps: Live-Previews von MRs

Review Apps deployen jeden MR in eigene Environment:

deploy_review:
  stage: deploy
  script:
    - kubectl apply -f k8s/review-app.yml
    - kubectl set image deployment/review-app-$CI_MERGE_REQUEST_IID app=myapp:$CI_COMMIT_SHA
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.review.example.com
    on_stop: stop_review
  only:
    - merge_requests

stop_review:
  stage: deploy
  script:
    - kubectl delete namespace review-app-$CI_MERGE_REQUEST_IID
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  only:
    - merge_requests

Im MR:

Environments
✓ review/feature-payment-gateway
   https://feature-payment-gateway.review.example.com
   
[View Deployment]  [Stop Environment]

Reviewer (und Product Owner, Designer, etc.) können MR live testen. Drastisch besseres Feedback als nur Code-Review.

18.11 Advanced: Merge Request API

Für Automatisierung bietet GitLab REST API für MRs:

# MR erstellen via API
curl --request POST \
  --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  --form "source_branch=feature/new-api" \
  --form "target_branch=main" \
  --form "title=Add new API endpoint" \
  --form "description=Implements REST endpoint for user search" \
  "https://gitlab.com/api/v4/projects/$PROJECT_ID/merge_requests"

# MR approven
curl --request POST \
  --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "https://gitlab.com/api/v4/projects/$PROJECT_ID/merge_requests/$MR_IID/approve"

# MR mergen
curl --request PUT \
  --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "https://gitlab.com/api/v4/projects/$PROJECT_ID/merge_requests/$MR_IID/merge"

Nützlich für Bot-Automatisierungen, Custom Workflows, Integration mit externen Tools.

18.12 Best Practices: GitLab-spezifische Empfehlungen

18.12.1 Templates nutzen

Erstelle Templates für konsistente MRs: - .gitlab/merge_request_templates/Feature.md - .gitlab/merge_request_templates/Bugfix.md - .gitlab/merge_request_templates/Hotfix.md

18.12.2 Labels strategisch einsetzen

Labels organisieren MRs: - type::feature, type::bug, type::refactor - priority::high, priority::medium, priority::low - status::needs-review, status::changes-requested, status::approved - workflow::blocked, workflow::ready

18.12.3 Milestones für Releases

MRs zu Milestones zuordnen: - Sprint 23 - v2.1.0 - Q1 2024

Gibt Überblick, was in welchem Release kommt.

18.12.4 Discussions vs. Comments

Comments: Informativ, keine Antwort nötig
Discussions: Require Resolution, blockieren Merge (wenn konfiguriert)

Nutze Discussions für wichtige Punkte, Comments für FYI.

18.12.5 Merge Commits vs. Squash

Projekt-Einstellungen → Merge Requests → Merge Method: - Merge Commit: Behält alle Commits (verzweigte Historie) - Merge Commit with Semi-linear History: Rebase auf Target, dann Merge (cleaner) - Fast-Forward Merge: Nur wenn möglich (lineare Historie) - Squash Commit: Alle Commits zu einem (sauberste Historie auf main)

Team-Entscheidung. Viele Teams nutzen Squash für main-Sauberkeit.

18.13 Zusammenfassung: GitLab als Kollaborationsplattform

GitLab Merge Requests sind mehr als Git-Merges mit UI. Sie sind ein vollständiges Kollaborationssystem:

Code Review: Inline Comments, Suggestions, Discussions, Approvals

Automatisierung: CI/CD Pipelines, Security Scans, Code Quality Checks

Governance: Approval Rules, Code Owners, Merge Checks

Visibility: Review Apps, Preview Environments, Status Tracking

Integration: Issue Tracking, Milestones, Labels, API

Die Kombination dieser Features macht Code Review von manuellem Prozess zu automatisiertem, durchgesetztem Workflow. Qualität wird nicht gehofft, sondern erzwungen.

Im Gegensatz zu reinem Git, wo jeder direkt zu main pushen könnte, etabliert GitLab Governance-Schichten: 1. Branch Protection (niemand pusht direkt zu main) 2. MR-Pflicht (alle Änderungen gehen durch MR) 3. Approval Rules (mindestens N Reviews nötig) 4. Pipeline Checks (Tests, Linting, Security müssen passen) 5. Manual Approval (für kritische Änderungen)

Das ist nicht Bürokratie. Das ist Engineering Discipline, die Scale ermöglicht. Ein Team, das diese Praktiken nutzt, kann schneller wachsen, Qualität halten, und Vertrauen in Deployments haben.

GitLab ist die Plattform, die Git’s technische Leistungsfähigkeit mit organisatorischen Prozessen verbindet. Master Merge Requests, und Code Review wird von Bottleneck zu Enabler.