DevOps für Einsteiger — CI/CD erklärt

Software-Releases sollten kein Abenteuer sein

Freitagabend, 18 Uhr. Der Entwickler klickt auf “Publish”. Dann hält er die Luft an und hofft, dass nichts schiefgeht. Das Deployment dauert 45 Minuten, ist manuell und wird von einer einzigen Person durchgeführt, die als Einzige den Prozess kennt.

Falls Sie diese Situation kennen: Sie sind nicht allein. In vielen Unternehmen — auch in solchen, die gute Software entwickeln — sind Deployments noch immer manuelle, stressige und fehleranfällige Prozesse. Genau hier setzen CI/CD und DevOps an.

Was ist DevOps?

DevOps ist keine Technologie und kein Tool. Es ist eine Philosophie, die zwei traditionell getrennte Welten zusammenbringt: Entwicklung (Dev) und Betrieb (Ops).

In der klassischen Welt entwickelt das Dev-Team Features und wirft sie über die Mauer an das Ops-Team, das sie in Produktion bringt und betreibt. Das Ergebnis: Konflikte, lange Release-Zyklen und gegenseitige Schuldzuweisungen bei Problemen.

DevOps bricht diese Mauer auf. Entwicklung und Betrieb arbeiten zusammen, teilen Verantwortung und nutzen Automatisierung, um Software schneller, sicherer und zuverlässiger auszuliefern.

Die drei Säulen von DevOps:

1. Kultur: Zusammenarbeit statt Silos, gemeinsame Verantwortung
2. Automatisierung: Alles, was automatisiert werden kann, wird automatisiert
3. Messung: Entscheidungen basieren auf Daten, nicht auf Bauchgefühl

CI/CD: Das Herzstück von DevOps

CI/CD steht für Continuous Integration und Continuous Delivery (oder Continuous Deployment). Es beschreibt eine automatisierte Pipeline, die Code vom Entwickler-Laptop bis in die Produktionsumgebung bringt.

Continuous Integration (CI)

Continuous Integration bedeutet: Jeder Entwickler integriert seine Codeänderungen mindestens einmal täglich in einen gemeinsamen Hauptbranch. Bei jeder Integration wird der Code automatisch gebaut und getestet.

Ohne CI:

• Entwickler arbeiten wochenlang an einem Feature-Branch
• Beim Merge gibt es massive Konflikte
• Fehler werden spät entdeckt, wenn sie teuer zu beheben sind

Mit CI:

• Kleine, häufige Änderungen statt großer Releases
• Automatisierte Tests fangen Fehler sofort ab
• Merge-Konflikte sind klein und leicht lösbar

Was eine CI-Pipeline typischerweise tut:

1. Code aus dem Repository auschecken
2. Abhängigkeiten installieren
3. Code kompilieren (Build)
4. Unit-Tests ausführen
5. Code-Analyse (Linting, Security Scanning)
6. Build-Artefakte erstellen

Continuous Delivery (CD)

Continuous Delivery geht einen Schritt weiter: Nach erfolgreicher CI wird die Software automatisch in eine Staging-Umgebung deployt und dort durch weitere Tests validiert. Ein Deployment in Produktion ist jederzeit auf Knopfdruck möglich.

Continuous Deployment — die Steigerung — bedeutet, dass auch das Produktions-Deployment automatisch erfolgt, ohne manuellen Eingriff. Das ist der Goldstandard, aber nicht für jedes Unternehmen sofort erreichbar.

Was eine CD-Pipeline typischerweise tut:

1. Build-Artefakt aus der CI-Phase übernehmen
2. Deployment in die Staging-Umgebung
3. Integrationstests und E2E-Tests ausführen
4. Performance-Tests (optional)
5. Deployment in Produktion (automatisch oder auf Knopfdruck)
6. Smoke-Tests in Produktion
7. Monitoring und Alerting aktivieren

Ein konkretes Beispiel: GitHub Actions

GitHub Actions ist eines der populärsten CI/CD-Tools und ideal für den Einstieg. Hier ein vereinfachtes Beispiel für eine .NET-Anwendung:

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Restore
        run: dotnet restore

      - name: Build
        run: dotnet build --no-restore

      - name: Test
        run: dotnet test --no-build --verbosity normal

  deploy-staging:
    needs: build-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Staging
        run: echo "Deploy to staging environment"

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Deploy to Production
        run: echo "Deploy to production"

Dieses Beispiel zeigt die Grundstruktur: Build und Test laufen bei jedem Push und Pull Request. Das Staging-Deployment erfolgt automatisch bei Änderungen auf dem Main-Branch. Das Produktions-Deployment erfordert eine manuelle Freigabe (über die “environment: production”-Konfiguration).

Die wichtigsten CI/CD-Tools im Vergleich

GitHub Actions

• Ideal für: Teams, die bereits GitHub nutzen
• Vorteile: Nahtlose GitHub-Integration, großer Marketplace, kostenlos für Open-Source
• Nachteile: Limitierte kostenlose Minuten für private Repos

Azure DevOps Pipelines

• Ideal für: Unternehmen im Microsoft-Ökosystem
• Vorteile: Tiefe Azure-Integration, umfassendes ALM-Tool (Boards, Repos, Pipelines, Artifacts)
• Nachteile: Komplexere Konfiguration, steilere Lernkurve

GitLab CI/CD

• Ideal für: Teams, die eine All-in-One-Lösung bevorzugen
• Vorteile: Repository, CI/CD, Container Registry und mehr in einem Tool
• Nachteile: Self-Hosted-Variante erfordert Wartung

Jenkins

• Ideal für: Teams mit speziellen Anforderungen und hohem Customizing-Bedarf
• Vorteile: Extrem flexibel, riesiges Plugin-Ökosystem
• Nachteile: Erfordert eigene Infrastruktur und Wartung, veraltete Oberfläche

Der Weg zur ersten Pipeline: Schritt für Schritt

Schritt 1: Versionskontrolle einführen

Falls noch nicht geschehen: Allen Code in Git versionieren. Kein Code mehr auf lokalen Festplatten oder Netzlaufwerken. Das ist die absolute Grundvoraussetzung.

Schritt 2: Branching-Strategie definieren

Für die meisten Teams empfehlen wir Trunk-Based Development oder GitHub Flow:

• Ein Hauptbranch (main)
• Kurzlebige Feature-Branches
• Pull Requests mit Code Review
• Merge nur nach bestandenen Tests

Schritt 3: Build automatisieren

Der Build-Prozess muss reproduzierbar und automatisiert sein. Keine manuellen Schritte, keine lokalen Abhängigkeiten. Wenn der Build auf dem CI-Server läuft, muss er überall laufen.

Schritt 4: Tests automatisieren

Beginnen Sie mit den Tests, die am meisten Wert liefern:

• Unit-Tests für kritische Geschäftslogik
• Integrationstests für Datenbankzugriffe und API-Aufrufe
• Smoke-Tests nach dem Deployment (funktioniert die Anwendung überhaupt?)

Perfektion ist nicht das Ziel. Ein einzelner automatisierter Test ist besser als kein Test.

Schritt 5: Deployment automatisieren

Dokumentieren Sie zuerst den manuellen Deployment-Prozess. Dann automatisieren Sie ihn Schritt für Schritt. Infrastructure as Code (Terraform, Bicep, Pulumi) hilft, auch die Infrastruktur reproduzierbar zu machen.

Schritt 6: Monitoring einrichten

Eine Pipeline ohne Monitoring ist wie Autofahren ohne Tacho. Sie müssen wissen, ob das Deployment erfolgreich war und ob die Anwendung danach korrekt läuft. Tools wie Azure Application Insights, Datadog oder Grafana liefern diese Transparenz.

Messbare Ergebnisse

Die Vorteile von CI/CD sind nicht nur theoretisch. Das DORA-Team (DevOps Research and Assessment) hat über Jahre hinweg gemessen, was die besten Teams von den schwächsten unterscheidet:

Metrik	Low Performer	High Performer
Deployment-Frequenz	1x pro Monat bis 1x pro Halbjahr	Mehrmals täglich
Lead Time for Changes	1-6 Monate	Weniger als 1 Stunde
Change Failure Rate	46-60%	0-15%
Time to Restore	1 Woche bis 1 Monat	Weniger als 1 Stunde

Die Korrelation ist eindeutig: Teams, die häufiger und automatisiert deployen, haben weniger Fehler und erholen sich schneller von Problemen.

Häufige Fehler beim Einstieg

Zu viel auf einmal wollen: Bauen Sie nicht sofort die perfekte Pipeline. Starten Sie mit einem automatisierten Build und erweitern Sie schrittweise.

Tests vernachlässigen: Eine Pipeline, die nur baut aber nicht testet, bringt wenig. Investieren Sie in automatisierte Tests — sie sind das eigentliche Sicherheitsnetz.

Kultur ignorieren: CI/CD ist eine technische Lösung, aber der Erfolg hängt an der Kultur. Wenn Code Reviews als Kontrolle statt als Qualitätssicherung wahrgenommen werden, scheitert das Vorhaben.

Umgebungen vernachlässigen: Staging sollte möglichst identisch mit Produktion sein. “Funktioniert bei mir” ist kein akzeptabler Qualitätsstandard.

Fazit

CI/CD ist keine Raketenwissenschaft. Die Tools sind ausgereift, die Patterns sind bewährt und die Ergebnisse sind messbar. Der schwierigste Teil ist nicht die Technik, sondern der erste Schritt.

Wenn Ihre Deployments heute noch manuell sind, wenn Releases Stress bedeuten und wenn Sie sich bei jedem Update Sorgen machen, dann ist jetzt der richtige Zeitpunkt, um CI/CD einzuführen. Fangen Sie klein an, aber fangen Sie an.

Bei IT-Trail unterstützen wir Teams bei der Einführung von DevOps-Praktiken und CI/CD-Pipelines — von der Auswahl der richtigen Tools bis zur Implementierung und Schulung.

---

Sie möchten CI/CD und DevOps in Ihrem Unternehmen einführen? IT-Trail GmbH unterstützt Sie von der Strategie bis zur Umsetzung. Vereinbaren Sie ein kostenloses Erstgespräch und lassen Sie uns gemeinsam Ihre Möglichkeiten besprechen.