🦊 Modul 3: GitLab für Netzwerkteams
Lernziele: Sie können GitLab-Projekte verwalten, Merge Requests erstellen, Code Reviews durchführen und verstehen, wie CI/CD-Pipelines funktionieren.
⏱️ Dauer: ca. 105 Minuten (inkl. 7 Praxis-Übungen)
📋 Inhaltsübersicht
- 1. Was ist GitLab?
- 2. Die GitLab-Oberfläche im Detail
- 3. Projekte und Groups
- 4. Protected Branches
- 5. Merge Request Workflow
- 6. Code Review Best Practices
- 7. Issues und Boards
- 8. CI/CD Pipeline Grundlagen
1. Was ist GitLab?
GitLab ist wie ein Bürogebäude für Ihren Code: Git speichert die Dateien, aber GitLab bietet die Infrastruktur drumherum – Projektverwaltung, Zugriffsrechte, Code Reviews, und automatische Pipelines.
GitLab = Die Plattform zum Teilen, Reviewen und Automatisieren (im Browser)
GitLab Kernfunktionen
📁 Repositories
Zentrale Ablage für Code und Konfigurationsdateien. Zugänglich für das ganze Team.
🔀 Merge Requests
Änderungen vorschlagen, reviewen und diskutieren, bevor sie live gehen.
⚙️ CI/CD Pipelines
Automatische Tests und Deployments bei jedem Push.
📋 Issues & Boards
Aufgaben und Bugs verfolgen, Arbeit planen und dokumentieren.
GitLab vs. GitHub – Kurzer Vergleich
Beide Plattformen bieten ähnliche Funktionen. Hier die wichtigsten Unterschiede:
| Aspekt | 🦊 GitLab | 🐙 GitHub |
|---|---|---|
| Self-Hosting | ✅ Kostenlos möglich (CE) | 💰 Enterprise-Lizenz nötig |
| CI/CD integriert | ✅ Vollständig eingebaut | ✅ GitHub Actions |
| Merge Request / PR | Merge Request (MR) | Pull Request (PR) |
| DevOps-Fokus | ✅ All-in-One Plattform | Eher Developer-fokussiert |
| Enterprise-Einsatz | Sehr verbreitet (on-prem) | Dominiert Open Source |
- On-Premise installiert werden kann (Datenschutz)
- CI/CD ohne externe Tools bietet
- LDAP/Active Directory Integration hat
- Approval-Workflows für Compliance unterstützt
2. Die GitLab-Oberfläche im Detail
Wenn Sie GitLab zum ersten Mal öffnen, sehen Sie die Hauptnavigation. Lassen Sie uns die wichtigsten Bereiche erkunden.
Die linke Seitenleiste
Wichtige Bereiche erklärt
📂 Repository → Files
Hier sehen Sie alle Dateien Ihres Projekts. Sie können Dateien direkt im Browser bearbeiten, die History einsehen und zwischen Branches wechseln.
📂 Repository → Branches
Übersicht aller Branches. Zeigt an, welche Branches aktiv sind, wann der letzte Commit war und ob sie protected sind. Hier können Sie auch neue Branches erstellen.
🔀 Merge Requests
Alle offenen, gemergten und geschlossenen Merge Requests. Filter nach Author, Reviewer, Labels oder Milestone möglich.
⚙️ Settings
Projekteinstellungen: Zugriffsrechte, Protected Branches, Webhooks, CI/CD-Variablen, Merge Request Approvals und vieles mehr.
Machen Sie sich mit der GitLab-Oberfläche vertraut.
- Öffnen Sie GitLab im Browser (URL vom Instructor)
- Neues Projekt erstellen:
- Klicken Sie auf
New project - Wählen Sie
Create blank project - Name:
netzwerk-config-IHRNAME - Visibility:
Private - ✅ "Initialize repository with a README" aktivieren
- Klicken Sie auf
- Projekt erkunden:
- Öffnen Sie
Repository → Files - Schauen Sie sich
Repository → Commitsan - Öffnen Sie
Settings → General
- Öffnen Sie
- Projekt klonen:
# HTTPS-URL aus GitLab kopieren (Clone-Button) git clone https://gitlab.example.com/IHRNAME/netzwerk-config-IHRNAME.git cd netzwerk-config-IHRNAME ls -la
3. Projekte und Groups
GitLab organisiert Repositories in einer hierarchischen Struktur. Das ist besonders für größere Teams wichtig.
Die Hierarchie verstehen
Warum Groups?
👥 Gemeinsame Berechtigungen
Rechte werden auf Group-Ebene vergeben und vererben sich auf alle Projekte.
📊 Übersicht
Alle Projekte eines Teams an einem Ort. Issues und MRs können gruppenübergreifend angezeigt werden.
🔄 Gemeinsame Runner
CI/CD Runner können auf Group-Ebene definiert werden und stehen allen Projekten zur Verfügung.
🏷️ Gemeinsame Labels
Labels, Milestones und Variablen können auf Group-Ebene definiert werden.
Zugriffsebenen (Roles)
| Rolle | Kann... | Typische Nutzung |
|---|---|---|
| Guest | Issues sehen, kommentieren | Stakeholder, Management |
| Reporter | Code lesen, Issues erstellen | QA, Support |
| Developer | Push, MRs erstellen, Branches | Entwickler, Netzwerk-Ingenieure |
| Maintainer | + Protected Branches, MRs mergen | Tech Leads, Senior Engineers |
| Owner | Volle Kontrolle, Projekt löschen | Team-/Abteilungsleiter |
4. Protected Branches
Protected Branches sind ein Sicherheitsmechanismus, der verhindert, dass kritische Branches (wie main oder production) versehentlich oder böswillig beschädigt werden.
main – und die automatische Pipeline deployed sie sofort auf 500 Switches. Protected Branches verhindern genau das!Was Protected Branches verhindern
🚫 Verboten
- • Direkter Push auf den Branch
- • Force Push (Überschreiben der History)
- • Branch löschen
- • Ungeprüfte Änderungen mergen
✅ Erlaubt
- • Änderungen über Merge Requests
- • Mit erforderlichen Approvals
- • Nach erfolgreicher Pipeline
- • Durch autorisierte Maintainer
Protected Branch Einstellungen
Merge Request Approval Rules
Zusätzlich zu Protected Branches können Sie Approval Rules definieren:
- Anzahl Approvals: Mindestens X Personen müssen zustimmen
- Code Owners: Bestimmte Dateien brauchen Approval vom zuständigen Team
- Eligible Approvers: Nur bestimmte Personen/Gruppen dürfen approven
- Author kann nicht approven: Vier-Augen-Prinzip erzwingen
Erstellen Sie eine strukturierte README für Ihr Projekt.
- README.md bearbeiten:
cd netzwerk-config-IHRNAME # README mit sinnvollem Inhalt erstellen cat > README.md << 'EOF' # Netzwerk-Konfiguration Dieses Repository enthält die Netzwerkkonfiguration für unser VXLAN-Fabric. ## Struktur ``` . ├── inventory/ # Geräte-Inventar ├── host_vars/ # Gerätespezifische Variablen ├── group_vars/ # Gruppenvariablen (Spines, Leafs) ├── templates/ # Jinja2-Templates └── playbooks/ # Ansible Playbooks ``` ## Verwendung ```bash # Konfiguration validieren ansible-playbook playbooks/validate.yml # Konfiguration deployen (nur auf Staging) ansible-playbook playbooks/deploy.yml -l staging ``` ## Kontakt Maintainer: IHR NAME EOF - Änderungen committen und pushen:
git status git add README.md git commit -m "docs: README mit Projektstruktur erstellt" git push origin main - In GitLab prüfen: Öffnen Sie Ihr Projekt im Browser und verifizieren Sie, dass die README angezeigt wird.
Schützen Sie Ihren main-Branch vor direkten Pushes.
- In GitLab navigieren:
- Öffnen Sie Ihr Projekt
- Gehen Sie zu
Settings → Repository - Klappen Sie
Protected branchesauf
- Branch schützen:
- Branch:
main - Allowed to merge:
Maintainers - Allowed to push and merge:
No one - Klicken Sie
Protect
- Branch:
- Testen Sie den Schutz:
# Versuchen Sie, direkt auf main zu pushen echo "# Test" >> README.md git add . git commit -m "test: direkter push" git push origin main # Erwartetes Ergebnis: FEHLER! # remote: GitLab: You are not allowed to push code to protected branches - Änderung rückgängig machen:
git reset --hard HEAD~1
5. Der Merge Request Workflow im Detail
Ein Merge Request (MR) ist wie ein formeller Änderungsantrag. Statt Änderungen direkt einzuspielen, schlagen Sie sie vor – und Kollegen prüfen sie, bevor sie live gehen.
Die Phasen eines Merge Requests
Phase 1: Draft Merge Request
Ein Draft MR signalisiert: "Ich arbeite noch daran, bitte noch nicht reviewen!" – perfekt für Work-in-Progress.
# Feature-Branch erstellen und pushen
git checkout -b feature/add-vlan-100
echo "vlan_id: 100" > vlans/vlan100.yaml
echo "name: Management" >> vlans/vlan100.yaml
git add .
git commit -m "feat: VLAN 100 für Management hinzugefügt"
git push -u origin feature/add-vlan-100In GitLab:
- Klicken Sie auf
Create merge request - Wählen Sie "Mark as draft" (oder Titel beginnt mit "Draft:")
- Fügen Sie eine Beschreibung hinzu, was noch fehlt
- Wenn Sie Feedback brauchen, bevor alles fertig ist
- Wenn die Pipeline noch rot ist
- Wenn Sie den MR für sich selbst als TODO tracken wollen
- Wenn Sie mehrere Tage an einem Feature arbeiten
Phase 2: MR zur Review freigeben
Wenn Ihre Arbeit fertig ist, entfernen Sie den Draft-Status:
- Klicken Sie auf "Mark as ready"
- Weisen Sie einen Reviewer zu (Dropdown rechts)
- Optional: Setzen Sie ein Label (z.B. "needs-review")
Phase 3: Code Review
Der Reviewer prüft Ihre Änderungen. In GitLab kann er:
💬 Kommentare
An einzelnen Zeilen Fragen stellen oder Verbesserungen vorschlagen.
💡 Suggestions
Konkrete Code-Änderungen vorschlagen, die der Author mit einem Klick übernehmen kann.
🧵 Threads
Diskussionen zu einzelnen Punkten. Müssen "resolved" werden, bevor gemergt wird.
✅ Approve
Formelle Zustimmung: "Ich habe geprüft, das kann gemergt werden."
Phase 4: Approval
Nachdem alle Kommentare bearbeitet und Threads resolved wurden, klickt der Reviewer auf "Approve". Je nach Konfiguration sind mehrere Approvals nötig.
Phase 5: Merge
Wenn alle Bedingungen erfüllt sind (Approvals, Pipeline grün, keine offenen Threads), kann der MR gemergt werden:
Merge-Optionen
- Merge – Alle Commits werden übernommen (Standard)
- Squash and merge – Alle Commits werden zu einem zusammengefasst
- Delete source branch – Feature-Branch nach Merge löschen (empfohlen)
Erstellen Sie einen vollständigen Merge Request.
- Feature-Branch erstellen:
cd netzwerk-config-IHRNAME git checkout main git pull origin main git checkout -b feature/add-vlan-200 # VLAN-Konfiguration erstellen mkdir -p vlans cat > vlans/vlan200.yaml << 'EOF' --- vlan: id: 200 name: Clients description: "Client-Netzwerk für Arbeitsplätze" ip_range: "10.200.0.0/24" gateway: "10.200.0.1" dhcp_enabled: true EOF git add . git commit -m "feat: VLAN 200 für Client-Netzwerk" git push -u origin feature/add-vlan-200 - In GitLab MR erstellen:
- Klicken Sie auf den Link in der Push-Ausgabe ODER
- Gehen Sie zu
Merge requests → New merge request - Source:
feature/add-vlan-200 - Target:
main
- MR ausfüllen:
- Titel: "feat: VLAN 200 für Client-Netzwerk hinzufügen"
- Beschreibung: Was, warum, wie testen?
- Reviewer: Wählen Sie Ihren Sitznachbarn
6. Code Review Best Practices
Code Reviews sind das Vier-Augen-Prinzip für Konfigurationen. Hier sind die wichtigsten Regeln für effektive Reviews.
Für den Author (Sie erstellen den MR)
✅ Do
- • Kleine, fokussierte MRs (max. 200-400 Zeilen)
- • Aussagekräftige Commit-Messages
- • Gute Beschreibung: Was? Warum? Wie testen?
- • Selbst-Review vor Zuweisung
- • Screenshots/Logs bei UI/Output-Änderungen
❌ Don't
- • Riesige MRs mit 20+ Dateien
- • Mehrere unabhängige Features in einem MR
- • Leere Beschreibung ("fixes stuff")
- • Reviewer ohne Kontext zuweisen
Für den Reviewer (Sie prüfen den MR)
✅ Do
- • Konstruktiv sein, nicht kritisieren
- • Fragen stellen statt Befehle geben
- • Positives Feedback geben ("Gute Lösung!")
- • Suggestions statt nur Kommentare
- • Zeitnah reviewen (<24h)
❌ Don't
- • Persönlich werden
- • Nur "LGTM" ohne echte Prüfung
- • Stilfragen zum Blocker machen
- • Wochen warten lassen
Was prüfen? Checkliste für Netzwerk-Konfigurationen
- ☐ Syntax korrekt? (YAML, Jinja2, etc.)
- ☐ Naming Conventions? (VLANs, Interfaces, etc.)
- ☐ IP-Adressen/Ranges korrekt? (keine Überlappung)
- ☐ Sicherheit? (keine Secrets im Code, ACLs korrekt)
- ☐ Abhängigkeiten? (Reihenfolge, Referenzen)
- ☐ Dokumentation? (Kommentare, README aktuell)
- ☐ Tests? (Pipeline grün, Validierung erfolgreich)
Kommentar-Konventionen
Verwenden Sie Präfixe, um die Wichtigkeit zu signalisieren:
| Präfix | Bedeutung | Beispiel |
|---|---|---|
| blocker: | Muss gefixt werden | blocker: Diese IP ist bereits vergeben! |
| suggestion: | Verbesserungsvorschlag | suggestion: VLAN-Name könnte sprechender sein |
| question: | Frage/Klärungsbedarf | question: Warum /24 statt /23? |
| nit: | Kleinigkeit, kein Blocker | nit: Trailing whitespace |
| praise: | Lob! | praise: Sehr saubere Struktur! 👍 |
Reviewen Sie den Merge Request Ihres Sitznachbarn und umgekehrt.
- MR Ihres Partners öffnen:
- Gehen Sie zu
Merge requests - Finden Sie den MR, bei dem Sie als Reviewer eingetragen sind
- Öffnen Sie den Tab
Changes
- Gehen Sie zu
- Code prüfen:
- Klicken Sie auf eine Zeile, um einen Kommentar zu hinterlassen
- Fügen Sie mindestens 2 Kommentare hinzu (Frage, Vorschlag oder Lob)
- Nutzen Sie die Präfixe:
question:,suggestion:, etc.
- Suggestion erstellen:
- Bei einem Kommentar auf das
Suggestion-Icon klicken - Konkreten Änderungsvorschlag im Code-Block schreiben
- Bei einem Kommentar auf das
- Auf Kommentare des Partners reagieren:
- Gehen Sie zu Ihrem eigenen MR
- Antworten Sie auf Kommentare
- Bei Suggestions: Klicken Sie
Apply suggestion - Resolven Sie bearbeitete Threads
Schließen Sie den Review-Prozess ab.
- MR des Partners approven:
- Öffnen Sie den MR Ihres Partners
- Stellen Sie sicher, dass alle Threads resolved sind
- Klicken Sie auf
Approve
- Ihren eigenen MR mergen:
- Nachdem Ihr Partner approved hat
- Klicken Sie auf
Merge - Option:
Delete source branchaktivieren
- Lokal aktualisieren:
git checkout main git pull origin main # Prüfen, dass die Änderungen da sind ls vlans/ cat vlans/vlan200.yaml
7. GitLab Issues und Boards
Issues sind das Aufgaben-Management in GitLab. Sie tracken Bugs, Features, Tasks und alles, was erledigt werden muss.
Issue-Anatomie
Issue-Templates
Templates sorgen für konsistente Issues. Erstellen Sie.gitlab/issue_templates/ in Ihrem Repo:
## Beschreibung
<!-- Was soll geändert werden? -->
## Betroffene Geräte/VLANs
- [ ] Switches
- [ ] Router
- [ ] Firewalls
- [ ] VLANs:
## Geplante Änderungen
```yaml
# Beispiel-Konfiguration
```
## Rollback-Plan
<!-- Wie wird zurückgerollt, falls etwas schief geht? -->
## Checkliste
- [ ] Change-Antrag genehmigt
- [ ] Staging getestet
- [ ] Maintenance-Window geplant
- [ ] Rollback-Plan dokumentiertIssue Boards
Boards sind Kanban-Ansichten Ihrer Issues. Sie helfen, den Arbeitsfortschritt zu visualisieren.
Issues mit Merge Requests verknüpfen
Verknüpfen Sie MRs mit Issues, um automatische Schließung zu ermöglichen:
# In der MR-Beschreibung oder Commit-Message:
Closes #42
Fixes #42
Resolves #42
# Mehrere Issues:
Closes #42, #43, #44
# Nur verknüpfen (nicht schließen):
Related to #42Erstellen Sie ein Issue und lösen Sie es mit einem Merge Request.
- Issue erstellen:
- Gehen Sie zu
Issues → New issue - Titel: "VLAN 300 für Gäste-WLAN einrichten"
- Beschreibung:
## Anforderung Gäste-WLAN benötigt eigenes VLAN mit Internetzugang. ## Technische Details - VLAN ID: 300 - Name: Guest-WiFi - IP-Range: 10.30.0.0/24 - Gateway: 10.30.0.1 ## Akzeptanzkriterien - [ ] VLAN konfiguriert - [ ] Gateway erreichbar - [ ] Internet-Zugang funktioniert - Label hinzufügen:
feature - Merken Sie sich die Issue-Nummer (z.B. #1)
- Gehen Sie zu
- Feature-Branch mit Issue-Referenz:
git checkout main git pull origin main git checkout -b feature/issue-1-vlan-300 # VLAN-Konfiguration erstellen cat > vlans/vlan300.yaml << 'EOF' --- vlan: id: 300 name: Guest-WiFi description: "Gäste-WLAN mit Internet-Zugang" ip_range: "10.30.0.0/24" gateway: "10.30.0.1" dhcp_enabled: true internet_access: true internal_access: false EOF git add . git commit -m "feat: VLAN 300 für Gäste-WLAN Closes #1" git push -u origin feature/issue-1-vlan-300 - MR erstellen:
- In der Beschreibung:
Closes #1 - Prüfen Sie, dass das Issue verknüpft angezeigt wird
- In der Beschreibung:
- MR mergen und Issue prüfen:
- Nach dem Merge: Öffnen Sie das Issue
- Es sollte automatisch geschlossen sein!
8. CI/CD Pipeline Grundlagen
Eine Pipeline ist wie ein Fließband in einer Fabrik: Bei jedem neuen Commit läuft automatisch eine Reihe von Schritten ab – testen, validieren, deployen.
Was bedeutet CI/CD?
CI – Continuous Integration
Bei jedem Push werden automatisch Tests ausgeführt. Fehler werden sofort erkannt, nicht erst bei der Produktion.
CD – Continuous Delivery/Deployment
Änderungen werden automatisch in Staging/Produktion deployed. Entweder manuell freigegeben (Delivery) oder vollautomatisch (Deployment).
Eine einfache Pipeline
# GitLab CI/CD Pipeline für Netzwerk-Konfiguration
stages:
- validate # Stufe 1: Prüfen
- test # Stufe 2: Testen
- deploy # Stufe 3: Deployen
# Job 1: YAML-Syntax prüfen
validate-yaml:
stage: validate
image: python:3.11-slim
before_script:
- pip install yamllint
script:
- echo "🔍 Prüfe YAML-Syntax..."
- yamllint vlans/
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == "main"
# Job 2: Konfiguration gegen Schema validieren
validate-schema:
stage: validate
image: python:3.11-slim
before_script:
- pip install jsonschema pyyaml
script:
- echo "📋 Prüfe gegen Schema..."
- python scripts/validate_schema.py
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
# Job 3: Auf Staging deployen (nur bei MR)
deploy-staging:
stage: deploy
script:
- echo "🚀 Deploye auf Staging..."
- ansible-playbook -i staging playbooks/deploy.yml
environment:
name: staging
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: manual # Manueller Klick erforderlich
# Job 4: Auf Produktion deployen (nur main)
deploy-production:
stage: deploy
script:
- echo "🚀 Deploye auf Produktion..."
- ansible-playbook -i production playbooks/deploy.yml
environment:
name: production
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual # Sicherheit: Manueller Klick
needs:
- validate-yamlPipeline-Konzepte
| Konzept | Beschreibung |
|---|---|
| Stages | Phasen der Pipeline (laufen nacheinander) |
| Jobs | Einzelne Aufgaben (laufen parallel innerhalb einer Stage) |
| Runner | Die Maschine/Container, die Jobs ausführt |
| Artifacts | Dateien, die zwischen Jobs weitergegeben werden |
| Variables | Umgebungsvariablen (Secrets, Konfiguration) |
| Rules | Bedingungen, wann ein Job läuft |
Pipeline-Status im MR
Im Merge Request sehen Sie den Pipeline-Status:
main landen.Settings → Merge requests → Merge checks:
✅ "Pipelines must succeed"
Zusammenfassung
✅ Das haben Sie gelernt
- ☑️ GitLab-Oberfläche navigieren
- ☑️ Projekte und Groups verstehen
- ☑️ Protected Branches einrichten
- ☑️ Merge Requests erstellen
- ☑️ Code Reviews durchführen
- ☑️ Issues und Boards nutzen
- ☑️ Issues mit MRs verknüpfen
- ☑️ CI/CD Pipelines verstehen
🔑 Key Takeaways
- Merge Requests = Kontrollierte Änderungen mit Review
- Protected Branches = Sicherheitsnetz für kritische Branches
- Code Reviews = Qualitätssicherung durch Vier-Augen-Prinzip
- CI/CD = Automatisierte Validierung und Deployment
- Issues = Strukturierte Aufgabenverwaltung
📋 GitLab Cheat Sheet
# Projekt klonen
git clone https://gitlab.example.com/group/project.git
# Feature-Branch erstellen
git checkout -b feature/mein-feature
git push -u origin feature/mein-feature
# Nach Änderungen
git add .
git commit -m "feat: Beschreibung der Änderung"
git push
# MR über CLI erstellen (falls glab installiert)
glab mr create --title "Mein Feature" --description "Closes #42"
# Branch aktualisieren mit main
git checkout main
git pull origin main
git checkout feature/mein-feature
git merge main # oder: git rebase main