Welche Rolle spielt CI/CD bei DevOps?
Continuous Integration, Continuous Delivery und Continuous Deployment (im Folgenden „CI/CD“ genannt) sind DevOps-Methoden. Mit anderen Worten: Sie sind Techniken, mit denen die DevOps-Ideale umgesetzt werden. Wenn Sie mit dem Begriff nicht vertraut sind, fragen Sie sich vielleicht: Was genau bedeutet „DevOps“? Und wie ist der Zusammenhang zur Agile-Softwareentwicklung? Einen allgemeinen Überblick über den geschichtlichen Verlauf der Entwicklungsmethoden zu haben und die Probleme zu kennen, die Agile und DevOps zu lösen versuchen, kann Ihnen dabei helfen, mehr aus Ihrem CI/CD-Prozess herauszuholen.
Wie Agile das Spielfeld verändert hat
Dank der digitalen Revolution haben Software und IT ihre reine Unterstützungsrolle, die sie in vielen Unternehmen (abgesehen von Softwareherstellern) spielten, abgelegt; inzwischen sind sie ein integraler Bestandteil vieler Wirtschaftssektoren.
Vom Banken- und Finanzwesen über die Branchen Handel, Reisen und Unterhaltung bis hin zu Behörden wird die Softwareentwicklung in einer ganzen Reihe von Bereichen zu einem zentralen Teil der Geschäftsaktivitäten. Apps und Onlineservices unterstützen und ermöglichen den Zugriff auf Produkte und Dienstleistungen, während interne Computersysteme entscheidend für reibungslose Betriebsabläufe sind.
Im Jahr 2001, als dieser Trend an Fahrt gewann, verfasste eine Gruppe von Softwareentwickler*innen das Agile-Manifest. Es war ihre Antwort auf einige Probleme, die sie in den damaligen Abläufen der Softwareentwicklung erkannt hatten. Das Manifest definiert eine Reihe von Werten und Prinzipien für die Entwicklung von Software. Um diese in die Praxis umsetzen, sind verschiedene Frameworks entstanden – Scrum dürfte eines der bekanntesten sein.
Agile erkennt, dass der Fokus auf der Bereitstellung funktionierender Software liegen sollte und dass Menschen, die effektiv kommunizieren und zusammenarbeiten, eine zentrale Rolle beim Erreichen dieses Ziels spielen. Der Agile-Ansatz wurde als Reaktion auf den langen Planungshorizont der Wasserfallprojekte geboren. In jener Zeit wurden Softwareanwendungen in der Regel erst Jahre nach der Festlegung der Anforderungen bereitgestellt, als sich die Benutzeranforderungen und der Verwendungskontext womöglich längst geändert hatten. Der Agile-Ansatz ist darauf ausgerichtet, mit Änderungen in den Anforderungen zurechtzukommen.
Bei Agile-Frameworks und -Methoden geht es darum, iterativ zu arbeiten, regelmäßig kleine, funktionierende Softwareteile bereitzustellen, Feedback zu sammeln und als Reaktion darauf Anpassungen vorzunehmen. Dies stellt eine deutliche Abkehr vom Wasserfall-Ansatz dar, bei dem in linearen Phasen – Design, Entwicklung, Test und Veröffentlichung – gearbeitet wird.
DevOps verstehen
Während Entwicklungsteams ihre Herangehensweise an die Softwareentwicklung durch die Übernahme der Agile-Prinzipien änderten, gab es tendenziell nur wenig Zusammenarbeit mit Teams, die im nachgelagerten Teil des Prozesses aktiv waren.
Es war nicht ungewöhnlich, dass Operations-Teams – zuständig für die Infrastrukturverwaltung und die Bereitstellung der Software für den Live-Betrieb – völlig anders arbeiteten und kommunizierten als das Programmierteam, das den Code schrieb.
Auch wenn die Entwickler*innen durch die Beschränkung auf ihr eigenes Team möglicherweise effizienter arbeiteten, kam der Prozess nach der Übergabe des Builds an das Operations-Team für das Staging oft zum Erliegen. Fehlende Abhängigkeiten, Probleme mit der Umgebungskonfiguration und Fehler, die nicht auf den lokalen Systemen des Entwicklungsteams reproduziert werden konnten, führten zu einem ausgedehnten Hin und Her zwischen den Teams und zu Auseinandersetzungen darüber, welche Seite für die Behebung des Problems verantwortlich war.
Oft wurde dies mit einer Wasserfall-Releasestrategie kombiniert: Die Änderungen wurden zwar von der Entwicklung inkrementell bereitgestellt, aber sie wurden in den nachfolgenden Schritten weiterhin zu großen Releases in weiten Abständen zusammengefasst. Dadurch wurde die Chance auf schnelles Benutzerfeedback verschenkt.
Ein Kulturwandel
Das Kunstwort „DevOps“ kombiniert die Begriffe „Development“ (Entwicklung) und „Operations“ (Betrieb) und betont dadurch die Notwendigkeit, die Aktivitäten beider Teams zu integrieren, um funktionsfähige Software effizient bereitzustellen. Dies gilt jedoch nicht nur für diese beiden Bereiche – alle an der Softwareentwicklung und -bereitstellung beteiligten Funktionen müssen auf das gemeinsame Ziel ausgerichtet werden, die Benutzergemeinde mit funktionierender Software zu versorgen.
Zentral für den DevOps-Erfolg ist die Schaffung einer Kultur der gemeinsamen Verantwortung, des gegenseitigen Vertrauens und der offenen Kommunikation. Entwicklungsteams können ihre Arbeit nicht als erledigt abhaken, sobald die Software in einem lokalen Build funktioniert. Um produktionsreifen Code bereitzustellen, benötigen Entwickler*innen Einblicke in die Schritte zwischen ihnen und der Veröffentlichung. Dies erfordert, die Trennmauern aufzubrechen und mit den Teams für Qualitätssicherung, Sicherheit und Infrastruktur zusammenzuarbeiten, um deren Anteil am Prozess zu verstehen.
DevOps-Tools und -Automatisierung
Eine engere Zusammenarbeit zwischen den Teams lässt sich zwar auch mit manuellen Abläufen erreichen. Viel effizienter ist es jedoch, die Arbeit durch den Einsatz von Tools so weit wie möglich zu automatisieren. Durch die Automatisierung von Build-, Test- und Bereitstellungsschritten kann die Arbeit schneller erledigt werden – und dies wiederum bedeutet, dass die Ergebnisse aus diesen Phasen viel früher verfügbar sind. Die Automatisierung ist für den DevOps-Ansatz von zentraler Bedeutung, da erst dadurch die kurzen Feedback-Schleifen ermöglicht werden, die eine „eingebaute“ Qualität gewährleisten und die Verschwendung von Ressourcen verhindern.
Effiziente Prozesse
DevOps entstand zu einer Zeit, als das Prinzip des Lean Manufacturing (schlanke Fertigung) zunehmend auch auf die Softwareentwicklung angewendet wurde. Beim Lean-Prinzip geht es darum, Verschwendung zu vermeiden, indem alle Phasen eines Prozesses optimiert, Qualität eingebaut und den beteiligten Personen Respekt entgegengebracht wird.
Unter Berücksichtigung dieser Überlegungen versucht DevOps, die Softwareentwicklung effizienter zu gestalten, indem der gesamte Prozess optimiert und mithilfe kurzer Feedback-Schleifen so früh wie möglich Rückmeldungen zu den Build-Ergebnissen gegeben werden.
Dazu gehört auch, Aktivitäten, die zuvor der Entwicklung nachgelagert waren, früher durchzuführen und die Probleme, die dabei zutage treten, gleich zu beheben – egal ob es sich um nicht bestandene Tests, Sicherheitslücken oder Buildprobleme handelt.
Da die Verantwortung für die Bereitstellung der Software von allen Beteiligten gemeinsam getragen wird, reicht die altbekannte Antwort „auf meinem System läuft es“ nicht mehr aus. Der DevOps-Ansatz bietet dem Entwicklungsteam einen viel genaueren Einblick in die Nutzung der Software und die dabei auftretenden Herausforderungen, und dadurch kann das Team diese Probleme auch leichter beheben.
Durch die Einführung von DevOps sind die Vorteile von Agile über das Entwicklungsteam hinaus zu spüren. Die Anpassung an das Arbeitstempo der Entwicklung und das Arbeiten mit kleineren Einheiten erleichtert das Erkennen und Isolieren von Problemen, da weniger Variablen im Spiel sind. Ebenso wird durch zeitnahes Feedback der überflüssige Aufwand für das Testen und Staging eines Builds, der später ohnehin verworfen wird, vermieden. Auf diese Weise profitiert das gesamte Unternehmen von der Arbeit in kleineren Schritten.
DevOps in der Praxis
Durch den Aufbau einer automatisierten CI/CD-Pipeline werden diese DevOps-Ideale in die Praxis umgesetzt.
Die in der Continuous Integration üblichen häufigen Commits fördert kleinere Arbeitseinheiten, die schnell die Pipeline durchlaufen. Durch ein automatisiertes Build- und Testsystem kann jede Änderung geprüft und Feedback viel schneller gegeben werden als bei einem manuellen Prozess.
Für Entwickler*innen ist schnelles Feedback zum gerade geschriebenen Code effizienter, da der Kontext der Änderung mit größerer Wahrscheinlichkeit noch präsent ist und der Arbeitsfluss („Flow“ in der Lean-Terminologie) nicht gestört wird. Häufige automatisierte Tests steigern auch die Qualität, da durch frühzeitiges Erkennen und Beheben von Fehlern vermieden wird, dass die weitere Entwicklung auf fehlerhaften Code aufbaut.
Die automatisierte Bereitstellung auf Vorproduktionsservern sorgt für einen einheitlichen und zuverlässigen Prozess und ermöglicht die verstärkte Nutzung von Staging-Umgebungen für Tests und Feedback. Die regelmäßige Übernahme kleiner Änderungen in die Produktion, anstatt sie in großen, seltener veröffentlichten Releases zu bündeln, verringert das Risiko, dass in der Live-Umgebung etwas schiefläuft, da es weniger Variablen gibt, deren Kombination zu unbeabsichtigten Konsequenzen führen könnte.
Sollte doch einmal ein Fehler auftreten, lässt er sich dank des geringeren Codeumfangs schneller eingrenzen und beheben. Durch die inkrementelle Veröffentlichung von Updates bieten Sie Ihrer Benutzergemeinde regelmäßig neuen Mehrwert, und das erhaltene Feedback kann in die weitere Entwicklung einfließen, um Ihr Produkt stetig zu verbessern.
Fazit
Das Ziel von CI/CD und allgemein von DevOps besteht darin, die Bereitstellung wertvoller Software zu beschleunigen, ohne Kompromisse bei der Qualität einzugehen. Die DevOps-Prinzipien überschneiden sich mit den Ideen der Agile- und Lean-Konzepte oder ergänzen diese. Wenn Sie den gesamten Ablauf der Softwareentwicklung im Blick behalten und jede Phase optimieren, können Sie die Bereitstellung beschleunigen und dadurch auch schnellere Rückmeldungen erhalten. Dies ermöglicht einen Kreislauf der kontinuierlichen Entwicklung und Verbesserung.