In mittelständischen IT-Teams ist der Weg von der Codeänderung zur Produktion oft länger als nötig. Manuelle Builds auf einem Entwickler-Notebook, Deployments per SSH und Dokumentation in Form mündlicher Überlieferung sind keine Seltenheit. Wer dann über DevOps liest, stößt auf Blogposts über Kubernetes-Operator-Patterns, Service Meshes und Platform Engineering. Diese Themen sind spannend, aber für die meisten Mittelständler der falsche Einstieg.
DevOps im Mittelstand beginnt mit einfachen, soliden Pipelines und dem Abbau manueller Schritte. Erst wenn dieser Unterbau steht, lohnen sich komplexere Muster. Dieser Artikel zeigt, wie ein pragmatischer Einstieg aussieht, ohne in die Overengineering-Falle zu tappen.
Was DevOps im Mittelstand wirklich bedeutet
DevOps ist in der Fachpresse oft von Enterprise-Setups geprägt: große Plattform-Teams, interne Developer Platforms, dutzende Microservices. Für ein Mittelstandsunternehmen mit fünf Entwicklern und drei Servern ist das nicht der richtige Maßstab. Was in der Praxis wirklich hilft, sind drei Kernprinzipien: Automatisierung manueller Schritte, kurze Feedback-Zyklen und geteilte Verantwortung zwischen Entwicklung und Betrieb.
Konkret beginnt DevOps meist an den Stellen, die am meisten weh tun. Bei vielen Kunden sehen wir zwei typische Engpässe. Erstens: Deployments passieren selten, dauern mehrere Stunden und werden von einer einzelnen Person durchgeführt, die zufällig gerade Zeit hat. Zweitens: Tests laufen nur manuell durch oder werden vor dem Release schnell übersprungen, weil die Zeit knapp wird. Beide Probleme löst ein pragmatisches CI/CD-Setup, das auf vorhandener Infrastruktur aufsetzt und keine Cloud-Revolution erfordert.
Wer noch am Anfang der Cloud-Reise steht, sollte DevOps nicht isoliert betrachten. Die Pipeline ist eng mit der Infrastruktur und der Architektur verbunden. Unser Artikel zu Cloud-Kosten optimieren zeigt, warum automatisierte Teardowns von Testumgebungen und klare Tagging-Strategien gleich von Beginn an Teil der Pipeline sein sollten.
Die erste Pipeline: Vom Commit zum Test
Die erste CI-Pipeline hat nur einen Job: Code checken, bauen, Tests laufen lassen, Artefakt ablegen. Nichts mehr. Wer das in GitLab CI abbildet, kommt mit einer einfachen .gitlab-ci.yml aus:
stages:
- build
- test
- package
build:
stage: build
image: node:20
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 week
test:
stage: test
image: node:20
script:
- npm ci
- npm run test
package:
stage: package
image: docker:24
services:
- docker:dind
script:
- docker build -t registry.example.com/app:$CI_COMMIT_SHORT_SHA .
- docker push registry.example.com/app:$CI_COMMIT_SHORT_SHA
only:
- mainDer gleiche Ablauf in GitHub Actions ist ähnlich kompakt:
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
build-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run build
- run: npm run test
- uses: actions/upload-artifact@v4
with:
name: dist
path: dist/Welches Tool im Mittelstand besser passt, hängt weniger von Features ab als von bestehender Infrastruktur. Wer bereits GitLab betreibt, bleibt dort. Wer GitHub als Hoster nutzt, ist mit GitHub Actions gut bedient. Wichtiger als die Tool-Wahl ist, dass die Pipeline schnell läuft (unter fünf Minuten als Ziel) und zuverlässig das Gleiche tut, egal ob ein Junior-Entwickler oder der Tech Lead einen Merge Request öffnet.
Zwei Stolpersteine sehen wir immer wieder. Erstens werden Pipelines mit immer mehr Spezialfällen aufgebläht, bis niemand mehr versteht, was in welcher Reihenfolge passiert. Zweitens fehlt am Anfang das Caching, sodass jeder Build alle Abhängigkeiten neu zieht und die Pipeline quälend langsam wird. Beide Probleme löst eine klare Trennung zwischen Standard-Flow und Sonderfällen und der frühe Einsatz von Dependency-Caching.
Deployment-Strategien ohne Big-Bang-Risiko
Steht die erste Pipeline, folgt der zweite Schritt: automatisiertes Deployment. Hier gehen Teams oft zu komplex ran. Canary Deployments, Service Meshes und Progressive Delivery klingen nach State of the Art, aber für die meisten Mittelständler reicht deutlich weniger.
Für den Einstieg gibt es drei solide Strategien. Rolling Updates ersetzen Instanzen nacheinander und sind der Standard in Kubernetes und den meisten Container-Orchestratoren. Blue/Green nutzt zwei identische Umgebungen, von denen immer nur eine live ist. Der Switch erfolgt über einen Load Balancer oder DNS. Das Verfahren ist simpel, braucht aber doppelte Ressourcen. Canary Deployments leiten einen kleinen Prozentsatz des Traffics auf die neue Version und erweitern schrittweise. Das ist leistungsstark, erfordert aber ausgereifte Metriken und Rollback-Automatik.
Der pragmatische Einstieg sieht so aus: Staging wird bei jedem Push auf Main automatisch deployed, Production bleibt ein manueller Trigger mit Genehmigungs-Step im Pipeline-Tool. Damit bekommen Teams sofort den Wert eines reproduzierbaren Prozesses, ohne in der Angst vor kaputten Deployments zu leben. Die nicht verhandelbare Voraussetzung: ein sauberer Rollback-Pfad. Wer kein definiertes Rückfall-Szenario hat, sollte keine automatisierten Deployments aktivieren.
Wer Kubernetes einsetzt, bekommt Rolling Updates über kubectl rollout praktisch geschenkt. Wer klassisch auf VMs oder Bare Metal deployt, nutzt einfache Blue/Green-Setups mit zwei Umgebungen hinter einem Reverse Proxy. Ansible oder Terraform sorgen für die Provisionierung, das CI/CD-Tool für den Switch.
Monitoring und Observability als zweite Stufe
Eine automatisierte Pipeline ohne Monitoring ist nur die halbe Lösung. Wenn das Deployment fünfmal pro Tag passiert, reicht es nicht, erst durch Kundenbeschwerden von Problemen zu erfahren. Beim Einstieg in Observability sollten Teams aber nicht direkt das teuerste Dashboard-Tool am Markt buchen.
Der minimal sinnvolle Stack besteht aus drei Bausteinen: strukturierte Logs im JSON-Format mit zentraler Sammlung (Loki, Elasticsearch oder CloudWatch), grundlegende Metriken (Prometheus oder die Cloud-Native-Lösung des jeweiligen Anbieters) und Alerts auf vier Golden Signals: Latenz, Traffic, Error Rate und Sättigung von Ressourcen.
Für mittelständische Setups reicht oft Open-Source-Tooling. Prometheus plus Grafana deckt Metriken und Dashboards ab, Loki ergänzt das für Logs. Wer den Betriebsaufwand scheut, findet mit Grafana Cloud Free oder Hosted-Alternativen wie Better Stack günstige Einstiegsoptionen. Der häufigste Fehler: zu viele Alerts, die niemand ernst nimmt. Besser mit fünf präzisen Alerts starten, die wirklich einen Menschen aus dem Feierabend holen dürfen, als mit fünfzig, die ignoriert werden.
Schrittweise Einführung statt Umbruch
Ein DevOps-Programm, das am Montag startet und bis Freitag fertig sein soll, scheitert. Wir empfehlen drei Phasen über sechs bis neun Monate.
Phase 1 (Monat 1 bis 2): CI etablieren. Jedes Projekt bekommt eine Pipeline, die Build und Tests automatisiert. Artefakte landen in einer zentralen Registry. Erfolgskriterium: Jeder Commit läuft durch die Pipeline, kein manueller Build mehr.
Phase 2 (Monat 3 bis 5): CD für Staging, manuelle Deployments für Production. Jedes Team definiert seinen Rollback-Pfad. Parallel werden Infrastructure-as-Code-Grundlagen gelegt, damit Umgebungen reproduzierbar sind. Der Vergleich zwischen Terraform und Pulumi hilft bei der Tool-Auswahl.
Phase 3 (Monat 6 bis 9): Observability und automatisiertes Production-Deployment. Die ersten Teams mit stabilen Pipelines und guter Testabdeckung aktivieren automatische Prod-Deployments. Monitoring und Alerts werden produktiv geschaltet.
Was in der Praxis schiefgeht: Teams versuchen, alle drei Phasen parallel zu starten. Das überfordert, und am Ende steht eine halbfertige Platform-Initiative ohne echten Nutzen. Erfolgreicher ist der iterative Weg: eine Pipeline komplett fertig bekommen, dann die nächste.
Fazit
DevOps im Mittelstand ist weniger eine Technologie-Frage als eine Disziplin-Frage. Die Werkzeuge sind verfügbar, ausgereift und oft kostenlos. Entscheidend ist, dass Teams die Automatisierung als laufende Aufgabe verstehen und nicht als einmaliges Projekt. Eine schlanke Pipeline, die zuverlässig läuft, bringt mehr als eine überladene Platform, die niemand versteht.
Wer mit dem Einstieg in CI/CD beginnen oder eine bestehende Pipeline professionalisieren möchte, findet in unseren Cloud-Services den passenden Rahmen. Oder direkt Kontakt aufnehmen, wir skizzieren eine Roadmap für Ihr Team.
Häufige Fragen
Wie lange dauert eine erste CI/CD-Pipeline?
Eine minimale Pipeline für Build und Tests ist in ein bis zwei Tagen aufgesetzt. GitLab CI und GitHub Actions bieten Templates, die man in wenigen Stunden anpassen kann. Staging-Deployments folgen eine Woche später, Production-Automation nach Stabilisierung.
Welches Tool ist besser: GitLab CI oder GitHub Actions?
Beide sind ausgereift und pragmatisch. GitLab CI passt, wenn Sie selbst GitLab betreiben. GitHub Actions ist richtig, wenn Sie GitHub als Hoster nutzen. Die Wahl sollte auf bestehender Infrastruktur basieren, nicht auf theoretischen Features.
Wie schnell sollte eine Pipeline sein?
Ziel unter fünf Minuten von Commit bis Deployment-Ready. Das ermöglicht schnelle Feedback-Schleifen. Wer länger braucht, verliert Feedback-Nähe und Entwickler-Produktivität. Caching und Parallelisierung sind typische Optimierungspunkte.
Wie sicher ist automatisiertes Deployment in Production?
Mit korrektem Setup sehr sicher. Voraussetzungen: solide Testabdeckung, klarer Rollback-Pfad, Monitoring-Alerts und ein manueller Genehmigungs-Step vor Production. Blue/Green oder Rolling Updates minimieren Ausfallrisiken erheblich.
