Merge Request Approval Rules in GitLab: Pflichtpruefer richtig konfigurieren

1. Warum ein Vier-Augen-Prinzip allein nicht reicht

Viele Teams fuehren Code Reviews als organisatorische Regel ein: Jeder Merge Request braucht ein Approval, bevor er gemerged wird. Das klingt zunaechst nach einer soliden Grundlage, scheitert in der Praxis aber regelmaessig an der Durchsetzung. Ohne technische Absicherung kann jedes Teammitglied mit ausreichenden Rechten die Regel schlicht ignorieren, sei es aus Zeitdruck, Unwissenheit oder weil ein Hotfix schnell raus muss. Am Ende des Quartals stellt sich dann heraus, dass ein Viertel aller Merges ohne echtes Review passiert ist.

GitLab loest dieses Problem mit Approval Rules, die auf Projekt- oder Merge-Request-Ebene definiert werden und in Kombination mit Branch Protection technisch verhindern, dass ein Merge Request ohne die geforderten Freigaben in den geschuetzten Branch gelangt. Der entscheidende Unterschied zur reinen Teamregel: Die Durchsetzung liegt nicht mehr bei den Entwicklern, sondern bei der Plattform selbst. Das reduziert Diskussionen ueber Ausnahmen erheblich, weil die Regel fuer alle gleich gilt und nicht individuell interpretiert werden kann.

2. CODEOWNERS als Basis fuer bereichsbezogene Pruefpflichten

Die CODEOWNERS-Datei im Projektroot (oder unter .gitlab/ bzw. docs/) definiert, welche Personen oder Gruppen fuer bestimmte Pfade im Repository verantwortlich sind. GitLab liest diese Datei aus und kann daraus automatisch Approval Rules ableiten, sodass etwa Aenderungen am Zahlungsmodul zwingend von der Payments-Gruppe freigegeben werden muessen, waehrend Frontend-Aenderungen von einem anderen Team geprueft werden. Das verhindert, dass ein Reviewer Code freigibt, fuer dessen fachlichen Kontext er gar nicht zustaendig ist.

Wichtig ist die Reihenfolge der Regeln: Spaetere, spezifischere Eintraege ueberschreiben fruehere, allgemeinere. Ein Wildcard-Eintrag * am Anfang der Datei deckt das gesamte Repository ab, waehrend gezielte Pfadmuster weiter unten fuer kritische Bereiche wie app/code/Vendor/Payment/ zusaetzliche, striktere Anforderungen definieren. So laesst sich ein abgestuftes Schutzniveau abbilden, ohne dass jede einzelne Datei manuell gepflegt werden muss.

# .gitlab/CODEOWNERS

# Standardregel: mindestens ein Review aus dem Core-Team
* @mironsoft/core-reviewers

# Zahlungs- und Checkout-Code: zwingend Payments-Team
app/code/Vendor/Payment/**       @mironsoft/payments-team
app/code/Vendor/Checkout/**      @mironsoft/payments-team @security-lead

# Frontend/Theme: Frontend-Team ist zustaendig
app/design/frontend/**           @mironsoft/frontend-team

# CI/CD-Konfiguration: nur Platform-Team darf Pipelines aendern
.gitlab-ci.yml                   @mironsoft/platform-team
/ci/**                           @mironsoft/platform-team

3. Mindestanzahl an Freigaben pro Regelgruppe festlegen

Neben der CODEOWNERS-Zuordnung erlaubt GitLab, fuer jede Approval-Gruppe eine eigene Mindestanzahl an Freigaben zu definieren. Ein einzelnes Approval reicht fuer die meisten Aenderungen, aber sicherheitskritische Bereiche wie Authentifizierung oder Zahlungsabwicklung profitieren von zwei unabhaengigen Freigaben aus unterschiedlichen Teams. Diese Granularitaet ist der eigentliche Mehrwert gegenueber einer globalen Ein-Approval-Regel, weil sie Aufwand und Risiko in ein sinnvolles Verhaeltnis setzt, statt jeden Tippfehler-Fix genauso streng zu behandeln wie eine Aenderung an der Zahlungslogik.

In der Projektkonfiguration unter Settings > Merge requests > Merge request approvals lassen sich mehrere Regeln parallel definieren, jede mit eigener Zielgruppe, eigenem Pfadfilter und eigener Mindestanzahl. GitLab wertet bei einem Merge Request alle zutreffenden Regeln aus und verlangt, dass jede einzelne erfuellt ist, bevor der Merge-Button aktiv wird. Das erlaubt eine feingranulare Eskalationslogik, ohne dass ein separates externes Tool noetig ist.

# Beispielhafte Approval-Rule-Definition via GitLab API
# (POST /projects/:id/approval_rules)
{
  "name": "Payments Security Review",
  "approvals_required": 2,
  "user_ids": [],
  "group_ids": [4821, 4903],
  "protected_branch_ids": [1],
  "applies_to_all_protected_branches": false
}

# Zweite, allgemeinere Regel fuer den Rest des Codes
{
  "name": "Standard Code Review",
  "approvals_required": 1,
  "group_ids": [4711],
  "applies_to_all_protected_branches": true
}

4. Typische Umgehungsmoeglichkeiten und warum sie entstehen

Selbst gut konfigurierte Approval Rules haben Schlupfloecher, wenn andere Einstellungen nicht mitziehen. Der haeufigste Fall: Ein Projekt-Maintainer besitzt genug Rechte, um Branch-Protection-Regeln temporaer zu aendern oder den Merge Request direkt per Push in den geschuetzten Branch zu umgehen. Ohne eine explizite Einschraenkung koennen Nutzer mit der Rolle Maintainer zudem Approval Rules pro Merge Request nachtraeglich anpassen und Pruefer entfernen, was den gesamten Mechanismus aushebelt, wenn niemand diese Aenderung bemerkt.

Ein zweites, subtileres Problem ist die Selbstfreigabe: Standardmaessig kann der Autor eines Merge Requests seine eigene Aenderung nicht freigeben, aber ohne die Option "Prevent approval by author" aktiviert zu haben, gilt das nicht in jeder GitLab-Konfiguration verlaesslich, insbesondere bei aelteren Projekten, die vor Einfuehrung dieser Einstellung angelegt wurden. Auch die Moeglichkeit, committende Personen als Pruefer zuzulassen, hoehlt das Vier-Augen-Prinzip aus, wenn zwei Entwickler sich gegenseitig ungeprueft durchwinken.

5. Umgehung bewusst einschraenken: die relevanten Schalter

GitLab bietet unter Settings > Merge requests mehrere Schalter, die gezielt gegen die oben beschriebenen Schlupfloecher wirken. Prevent approval by author verhindert, dass der MR-Ersteller sein eigenes Approval zaehlt. Prevent approvals by users who add commits schliesst die Luecke, dass jemand nach der initialen Freigabe unbemerkt weiteren Code nachschiebt. Prevent editing approval rules in merge requests verbietet es Maintainern, Regeln pro MR aufzuweichen, sodass nur zentrale Projekteinstellungen greifen.

Fuer wirklich kritische Repositories empfiehlt sich zusaetzlich, die Berechtigung zum Aendern von Branch-Protection-Regeln auf einen sehr kleinen Personenkreis zu beschraenken und Code owner approval required fuer den geschuetzten Branch zu aktivieren. Dadurch kann selbst ein Maintainer den CODEOWNERS-Zwang nicht mehr per Klick umgehen, sondern muesste die Branch-Protection-Konfiguration explizit und nachvollziehbar aendern, was in einem Audit-Log sichtbar bleibt.

# Relevante Einstellungen ueber die GitLab API setzen
curl --request PUT \
  --header "PRIVATE-TOKEN: <token>" \
  "https://gitlab.example.com/api/v4/projects/123/approval_rules/settings" \
  --data "prevent_approval_by_author=true" \
  --data "prevent_approval_by_commit_author=true" \
  --data "disable_overriding_approvers_per_merge_request=true"

6. Notfall-Hotfixes: Ausnahmen dokumentieren statt Regeln aufweichen

Der klassische Einwand gegen strikte Approval Rules lautet: "Was, wenn nachts ein kritischer Fehler live behoben werden muss und kein Pruefer erreichbar ist?" Die falsche Antwort darauf ist, die Regel dauerhaft aufzuweichen. Die richtige Antwort ist ein dokumentierter Ausnahmeprozess: ein kleiner, namentlich benannter Kreis von Personen mit der Rolle Owner darf im Notfall Branch-Protection-Regeln temporaer aendern, muss dies aber in einem Incident-Ticket begruenden und die Aenderung nach Behebung des Problems sofort rueckgaengig machen.

Praktisch bewaehrt sich eine feste Checkliste fuer solche Faelle: Ausnahme im Team-Chat ankuendigen, Ticket-Referenz im Merge Request verlinken, nach dem Merge ein nachtraegliches Review durch ein zweites Teammitglied einholen und die temporaere Rechteanpassung binnen 24 Stunden zuruecksetzen. Dieser Prozess erhaelt die Sicherheit der Regel, ohne im Ernstfall zum Hindernis zu werden, und macht jede Ausnahme im Audit-Log sichtbar statt sie stillschweigend zu ermoeglichen.

7. Approval-Events nachvollziehen: wer hat wann was freigegeben

GitLab protokolliert jede Freigabe, jede Entfernung eines Approvals und jede Aenderung an Approval Rules im projektbezogenen Audit-Log (bei Premium/Ultimate-Lizenzen auch gruppenweit). Diese Historie ist mehr als eine Formalitaet: Sie erlaubt es, im Nachhinein zu klaeren, warum ein bestimmter Merge Request trotz kritischer Aenderungen nur ein statt zwei Freigaben hatte, oder ob eine Regel kurzfristig deaktiviert wurde. Fuer regulierte Branchen oder ISO-27001-Audits ist dieses Log oft ein Pflichtnachweis fuer funktionierende Change-Management-Prozesse.

Ueber die API laesst sich der Freigabestatus jedes Merge Requests auch automatisiert auswerten, etwa um ein monatliches Reporting zu erzeugen, wie viele Merge Requests ohne die geforderte Mindestanzahl an Freigaben gemerged wurden (was bei korrekt konfigurierten Regeln null sein sollte) oder wie oft die Notfall-Ausnahme tatsaechlich gezogen wurde. Ein Anstieg dieser Zahl ist meist ein Signal, dass entweder die Personaldecke im Reviewer-Pool zu duenn ist oder die Regeln an der falschen Stelle zu streng greifen.

# Freigabestatus eines Merge Requests per API abfragen
curl --header "PRIVATE-TOKEN: <token>" \
  "https://gitlab.example.com/api/v4/projects/123/merge_requests/456/approvals" \
  | jq '{approved: .approved, approved_by: [.approved_by[].user.username]}'

8. Schrittweise Einfuehrung statt Big-Bang-Umstellung

Approval Rules von heute auf morgen mit maximaler Strenge einzufuehren, fuehrt in gewachsenen Teams meist zu Frust und findigen Umgehungsversuchen. Bewaehrt hat sich ein dreistufiges Vorgehen: Zunaechst wird nur eine einzige, allgemeine Regel mit einer Mindestfreigabe fuer das gesamte Repository aktiviert, ohne CODEOWNERS-Differenzierung. Nach zwei bis drei Wochen Gewoehnung folgt die Aufteilung in fachliche Bereiche per CODEOWNERS, sodass Teams gezielt fuer ihre eigenen Module verantwortlich werden.

Erst in der dritten Stufe werden die haerteren Schalter wie Prevent approval by author und erhoehte Mindestanzahlen fuer sicherheitskritische Pfade aktiviert, begleitet von einer kurzen Team-Kommunikation, warum diese Aenderung sinnvoll ist. Dieses stufenweise Vorgehen erzeugt Akzeptanz, weil Entwickler die Regeln als Unterstuetzung statt als buerokratische Huerde erleben, und reduziert die Zahl der Ausnahmeantraege in der Einfuehrungsphase spuerbar.

9. Haeufige Fehler bei der Konfiguration und wie man sie vermeidet

Ein wiederkehrender Fehler ist, Approval Rules zu definieren, ohne den Ziel-Branch tatsaechlich als Protected Branch zu markieren. Ohne diesen Schutz lassen sich Aenderungen weiterhin per direktem Push umgehen, unabhaengig davon, wie streng die Merge-Request-Regeln konfiguriert sind. Ebenso haeufig ist eine CODEOWNERS-Datei mit ueberlappenden, widerspruechlichen Pfadmustern, bei denen am Ende niemand mehr genau weiss, welche Gruppe fuer welchen Ordner tatsaechlich verantwortlich ist.

Die folgende Tabelle fasst die wichtigsten Stellschrauben zusammen und zeigt, welches Verhalten sie jeweils absichern. Sie eignet sich als Checkliste fuer ein Konfigurations-Review, bevor Approval Rules produktiv fuer ein kritisches Repository scharf geschaltet werden.

10. Zusammenfassung

11. FAQ: Approval Rules: Das Wichtigste auf einen Blick