Home/Modul 3

🦊 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 vs. Git
Git = Das Werkzeug zur Versionskontrolle (lokal auf Ihrem Rechner)
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 / PRMerge Request (MR)Pull Request (PR)
DevOps-Fokus✅ All-in-One PlattformEher Developer-fokussiert
Enterprise-EinsatzSehr verbreitet (on-prem)Dominiert Open Source
ℹ️Warum GitLab im Enterprise?
Viele Unternehmen (inkl. Cisco-Kunden) nutzen GitLab, weil es:
  • 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

🦊GitLab
📁 Ihr Projekt
├── 📋 Project information
├── 📂 Repository
│ ├── Files
│ ├── Commits
│ ├── Branches
│ └── Tags
├── 📝 Issues
├── 🔀 Merge requests
├── ⚙️ CI/CD
│ ├── Pipelines
│ └── Jobs
├── 📊 Analytics
└── ⚙️ Settings

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.

🔧🔧 Übung 1: GitLab erkunden und Projekt anlegen (~10 Min)

Machen Sie sich mit der GitLab-Oberfläche vertraut.

  1. Öffnen Sie GitLab im Browser (URL vom Instructor)
  2. 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
  3. Projekt erkunden:
    • Öffnen Sie Repository → Files
    • Schauen Sie sich Repository → Commits an
    • Öffnen Sie Settings → General
  4. 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
✅ Erfolgskriterium: Sie haben ein neues Projekt in GitLab erstellt und es lokal geklont.

3. Projekte und Groups

GitLab organisiert Repositories in einer hierarchischen Struktur. Das ist besonders für größere Teams wichtig.

Die Hierarchie verstehen

gitlab.example.com (Instanz)
└── infrastructure (Group)
├── networking (Subgroup)
│ ├── datacenter-fabric (Projekt)
│ ├── campus-switches (Projekt)
│ └── firewall-rules (Projekt)
├── compute (Subgroup)
│ └── vmware-configs (Projekt)
└── shared-templates (Projekt in Group)

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)

RolleKann...Typische Nutzung
GuestIssues sehen, kommentierenStakeholder, Management
ReporterCode lesen, Issues erstellenQA, Support
DeveloperPush, MRs erstellen, BranchesEntwickler, Netzwerk-Ingenieure
Maintainer+ Protected Branches, MRs mergenTech Leads, Senior Engineers
OwnerVolle Kontrolle, Projekt löschenTeam-/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.

⚠️Warum ist das wichtig?
Stellen Sie sich vor, jemand pusht versehentlich eine fehlerhafte Konfiguration direkt auf 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

# Settings → Repository → Protected Branches
Branch:main
Allowed to merge:Maintainers
Allowed to push:No one
Require approval:1 approval required

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
🔧🔧 Übung 2: README.md erstellen und committen (~8 Min)

Erstellen Sie eine strukturierte README für Ihr Projekt.

  1. 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
  2. Änderungen committen und pushen:
    git status
    git add README.md
    git commit -m "docs: README mit Projektstruktur erstellt"
    git push origin main
  3. In GitLab prüfen: Öffnen Sie Ihr Projekt im Browser und verifizieren Sie, dass die README angezeigt wird.
✅ Erfolgskriterium: Ihre README.md wird auf der Projektseite in GitLab angezeigt.
🔧🔧 Übung 3: Branch Protection einrichten (~8 Min)

Schützen Sie Ihren main-Branch vor direkten Pushes.

  1. In GitLab navigieren:
    • Öffnen Sie Ihr Projekt
    • Gehen Sie zu Settings → Repository
    • Klappen Sie Protected branches auf
  2. Branch schützen:
    • Branch: main
    • Allowed to merge: Maintainers
    • Allowed to push and merge: No one
    • Klicken Sie Protect
  3. 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
  4. Änderung rückgängig machen:
    git reset --hard HEAD~1
✅ Erfolgskriterium: Direkte Pushes auf main werden abgelehnt. Sie sehen die Fehlermeldung "not allowed to push to protected branches".

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

1
Draft
2
Open
3
Review
4
Approved
5
Merged

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-100

In GitLab:

  1. Klicken Sie auf Create merge request
  2. Wählen Sie "Mark as draft" (oder Titel beginnt mit "Draft:")
  3. Fügen Sie eine Beschreibung hinzu, was noch fehlt
💡Wann Draft verwenden?
  • 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)
🔧🔧 Übung 4: Merge Request erstellen (~10 Min)

Erstellen Sie einen vollständigen Merge Request.

  1. 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
  2. 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
  3. MR ausfüllen:
    • Titel: "feat: VLAN 200 für Client-Netzwerk hinzufügen"
    • Beschreibung: Was, warum, wie testen?
    • Reviewer: Wählen Sie Ihren Sitznachbarn
⏳ Warten: Mergen Sie NOCH NICHT – das machen wir nach dem Code Review in Übung 6.

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äfixBedeutungBeispiel
blocker:Muss gefixt werdenblocker: Diese IP ist bereits vergeben!
suggestion:Verbesserungsvorschlagsuggestion: VLAN-Name könnte sprechender sein
question:Frage/Klärungsbedarfquestion: Warum /24 statt /23?
nit:Kleinigkeit, kein Blockernit: Trailing whitespace
praise:Lob!praise: Sehr saubere Struktur! 👍
🔧🔧 Übung 5: Code Review durchführen – Partner-Übung (~15 Min)

Reviewen Sie den Merge Request Ihres Sitznachbarn und umgekehrt.

  1. 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
  2. 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.
  3. Suggestion erstellen:
    • Bei einem Kommentar auf das Suggestion-Icon klicken
    • Konkreten Änderungsvorschlag im Code-Block schreiben
  4. 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
✅ Erfolgskriterium: Beide Partner haben Kommentare erhalten, darauf reagiert und Threads resolved.
🔧🔧 Übung 6: Merge Request genehmigen und mergen (~8 Min)

Schließen Sie den Review-Prozess ab.

  1. MR des Partners approven:
    • Öffnen Sie den MR Ihres Partners
    • Stellen Sie sicher, dass alle Threads resolved sind
    • Klicken Sie auf Approve
  2. Ihren eigenen MR mergen:
    • Nachdem Ihr Partner approved hat
    • Klicken Sie auf Merge
    • Option: Delete source branch aktivieren
  3. Lokal aktualisieren:
    git checkout main
    git pull origin main
    
    # Prüfen, dass die Änderungen da sind
    ls vlans/
    cat vlans/vlan200.yaml
✅ Erfolgskriterium: Der MR ist gemergt, der Feature-Branch gelöscht und die Änderungen sind auf main sichtbar.

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

#42VLAN 300 für Gäste-WLAN einrichten
Assignee:Max Mustermann
Milestone:Sprint 2024-Q1
Labels:featurepriority::high
Due date:2024-02-15

Issue-Templates

Templates sorgen für konsistente Issues. Erstellen Sie.gitlab/issue_templates/ in Ihrem Repo:

📄 .gitlab/issue_templates/Netzwerk-Änderung.md
## 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 dokumentiert

Issue Boards

Boards sind Kanban-Ansichten Ihrer Issues. Sie helfen, den Arbeitsfortschritt zu visualisieren.

📋 Open
#45 DNS-Server migrieren
#48 Backup-Route prüfen
🔄 In Progress
#42 VLAN 300 einrichten
👀 Review
#39 Firewall-Regeln
✅ Done
#38 VLAN 100 deployed
#35 NTP konfiguriert

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 #42
🔧🔧 Übung 7: Issue erstellen und mit MR verknüpfen (~10 Min)

Erstellen Sie ein Issue und lösen Sie es mit einem Merge Request.

  1. 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)
  2. 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
  3. MR erstellen:
    • In der Beschreibung: Closes #1
    • Prüfen Sie, dass das Issue verknüpft angezeigt wird
  4. MR mergen und Issue prüfen:
    • Nach dem Merge: Öffnen Sie das Issue
    • Es sollte automatisch geschlossen sein!
✅ Erfolgskriterium: Das Issue wurde automatisch geschlossen, als der MR gemergt wurde.

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.

ℹ️📌 Hinweis
CI/CD wird in Modul 5 ausführlich behandelt. Hier lernen Sie nur die Grundlagen, um Pipelines in GitLab zu verstehen.

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.yml
# 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-yaml

Pipeline-Konzepte

KonzeptBeschreibung
StagesPhasen der Pipeline (laufen nacheinander)
JobsEinzelne Aufgaben (laufen parallel innerhalb einer Stage)
RunnerDie Maschine/Container, die Jobs ausführt
ArtifactsDateien, die zwischen Jobs weitergegeben werden
VariablesUmgebungsvariablen (Secrets, Konfiguration)
RulesBedingungen, wann ein Job läuft

Pipeline-Status im MR

Im Merge Request sehen Sie den Pipeline-Status:

🔀Merge Request !15
Pipeline passed
✅ validate-yaml✅ validate-schema⏸️ deploy-staging (manual)
💡Pipelines blockieren Merges
Sie können konfigurieren, dass MRs nur gemergt werden können, wenn die Pipeline grün ist. Das verhindert, dass fehlerhafte Konfigurationen in 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