Software wird heute selten in großen Paketen alle paar Monate ausgeliefert. Stattdessen fließen kleine Änderungen laufend in den gemeinsamen Code und werden automatisch geprüft. CI/CD beschreibt die Praktiken und die Automatisierung dahinter, oft als Pipeline bezeichnet. Microsoft zählt CI/CD zu den zentralen Praktiken von DevOps, also der engen Verbindung von Entwicklung und Betrieb. Grundlage ist eine Versionsverwaltung wie Git.
Die Bausteine
- Continuous Integration (CI): Laut GitHub eine Praxis, bei der Code häufig in ein gemeinsames Repository übernommen wird. Jede Änderung wird automatisch gebaut und getestet. Fehler fallen dadurch früh auf, wenn sie noch günstig zu beheben sind.
- Continuous Delivery (CD): Code wird automatisch gebaut, getestet und in eine oder mehrere Test- und Produktivumgebungen ausgeliefert. Ziel ist, dass der Code jederzeit auslieferbar ist. Die Freigabe für die Produktion kann bewusst ein menschlicher Schritt bleiben.
- Continuous Deployment: Jede Änderung, die alle Prüfungen besteht, geht automatisch in die Produktion. Microsoft weist darauf hin, dass das robuste automatische Tests und sorgfältige Planung voraussetzt und nicht für jedes Team passt.
Wie eine Pipeline aussieht
- Auslöser: Ein Push oder ein Pull Request startet die Pipeline.
- Bauen: Abhängigkeiten installieren, etwa mit Composer, und die Anwendung bauen.
- Prüfen: Unit-Tests, statische Analyse, Formatprüfung, Prüfung der Abhängigkeiten auf bekannte Lücken und Suche nach versehentlich eingecheckten Zugangsdaten.
- Review: Ein Mensch prüft die Änderung im Code Review, bevor sie in den Hauptzweig übernommen wird.
- Artefakt erstellen: Ein versioniertes Paket oder Container-Abbild entsteht, das unverändert durch alle Umgebungen wandert.
- Ausliefern: Zuerst in eine Testumgebung mit Integrations- und Oberflächentests, nach Freigabe in die Produktion.
- Beobachten: Monitoring prüft nach der Auslieferung Fehlerraten und Antwortzeiten. Ein Rückweg auf die vorige Version ist vorbereitet.
Verbreitete Werkzeuge sind GitHub Actions, GitLab CI/CD und Azure Pipelines.
Nutzen für KMU
- Weniger Handarbeit und Fehler: Wiederkehrende Schritte laufen jedes Mal gleich ab, unabhängig davon, wer gerade Dienst hat.
- Schnellere Sicherheitsupdates: Ein Update einer Bibliothek ist getestet und ausgeliefert, ohne dass jemand einen Abend dafür reservieren muss.
- Nachvollziehbarkeit: Wer hat was wann geändert, geprüft und ausgeliefert? Das hilft bei Fehleranalysen und bei Nachweisen gegenüber Kunden oder Prüfern.
- Kleine Teams profitieren besonders: Wissen steckt in der Pipeline statt nur im Kopf einer Person.
Sicherheit der Pipeline
Eine Pipeline hat Zugriff auf Quellcode, Zugangsdaten und Produktivsysteme und ist deshalb selbst ein Angriffsziel. OWASP führt dafür eine eigene Liste der zehn wichtigsten CI/CD-Risiken, darunter unzureichende Ablaufkontrolle, mangelhaftes Identitäts- und Zugriffsmanagement, Missbrauch der Abhängigkeitskette, manipulierte Pipeline-Ausführung und schlechte Pflege von Zugangsdaten. Konkrete Maßnahmen:
- Kein Weg an der Prüfung vorbei: Geschützte Branches mit Pflicht-Review und Pflicht-Checks, keine direkten Änderungen an der Produktion.
- Minimale Rechte: GitHub empfiehlt, das automatische Token standardmäßig nur lesend zu konfigurieren und höhere Rechte gezielt je Job zu vergeben, nach Least Privilege.
- Fremde Bausteine festnageln: Aktionen von Drittanbietern laut GitHub auf einen vollständigen Commit-Hash festlegen und ihren Quellcode prüfen.
- Keine ungeprüften Eingaben in Skripte: Titel oder Beschreibungen von Pull Requests nicht direkt in Befehle einsetzen.
- Geheimnisse richtig ablegen: Zugangsdaten nur im Geheimnisspeicher der Plattform, getrennt je Umgebung, regelmäßig erneuert.
- Protokollieren: Ausführungen und Freigaben nachvollziehbar speichern.
Typische Stolpersteine
Unzuverlässige Tests, die zufällig fehlschlagen, untergraben das Vertrauen in die Pipeline. Lange Laufzeiten verleiten dazu, Prüfungen zu überspringen. Unterschiede zwischen Test- und Produktivumgebung lassen sich mit Infrastructure as Code verringern.
Abgrenzung
DevOps beschreibt Kultur und Zusammenarbeit, CI/CD die technische Praxis darin. Im Change Management kann eine geprüfte Pipeline den Weg für Standardänderungen bilden, während größere Änderungen weiterhin eine eigene Freigabe brauchen.
Bezug zu TOMORIS
TOMORIS entwickelt eigene Software über die interne Plattform Werft: Anforderungen laufen über isolierte Arbeitskopien, Tests und prüfbare Pull Requests, Freigabe und Deployment bleiben getrennte Schritte. Für Ihr Softwarevorhaben finden Sie den Einstieg unter Individuelle Software.
Quellen
- GitHub Docs: Continuous integration
- GitHub Docs: Secure use reference für GitHub Actions
- Microsoft Learn: What is DevOps?
- Microsoft Learn: What is continuous delivery?
- Microsoft Learn: Get started with DevOps architecture design
- OWASP: Top 10 CI/CD Security Risks
- NIST: SP 800-218, Secure Software Development Framework 1.1