CI/CD

Einführung in CI/CD

CI/CD ist ein Konzept in der Softwareentwicklung, das darauf abzielt, den Entwicklungsprozess zu automatisieren und die Bereitstellung von Software effizienter und schneller zu gestalten. In der folgenden Abbildung 1 ist der CI/CD Kreislauf dargestellt.

Continous integration

Continous Integration wurde vorallem durch die Definition von Martin Fowler geprägt: ¹

Kontinuierliche Integration ist eine Praxis der Softwareentwicklung, bei der die Mitglieder eines Teams ihre Arbeit häufig zusammenführen [...] Jede Integration wird durch einen automatisierten Build (einschließlich Test) überprüft, um Konflikte so schnell wie möglich zu erkennen.

Das bedeutet, dass CI ein automatisierter Prozess ist, der es ermöglicht die Vollständigkeit des Quellcodes jedes Mal zu überprüfen, wenn ein Teammitglied eine Änderung vornimmt. Diese Überprüfung sollte so schnell wie möglich erfolgen. ² Im Kontext dieser Projektarbeit ist CI von großer Bedeutung, da gerade der Build Prozess häufig komplexer ist als bei einer herkömmlichen Bereitstellung. CI vereinfacht es zudem Fehler im Code schnell zu entdecken und noch vor der Überführung in die Staging oder Produktivumgebung zu beheben. ³ Besonders wichtig wird CI jedoch, wenn mehrere Personen gemäß der Definition von Martin Fowler gemeinsam an einem Code arbeiten. In solchen Situationen hat CI die Aufgabe, zu verhindern, dass Codeänderungen sich gegenseitig negativ beeinflussen. Dies wird in der Praxis durch das Erstellen verschiedener Branches (oder auch Äste genannt) umgesetzt, beispielsweise für jedes Feature ein eigener Branch, die später wieder zusammengeführt (gemerged) werden.

Continour Delivery

Sobald die Continous integration erfolgreich abgeschlossen ist, besteht der nächste Schritt darin, die Anwendung automatisch bereitzustellen. Dieser Prozess wird als kontinuirliche Bereistellung CD bezeichnet

Die Bereitstellung in einer oder mehreren Nicht-Produktivumgebungen, wird auch als Staging bezeichnet und wird häufig in die CD integriert. Somit lässt sich die Anwendung in ihrer Gesamtheit vor ihrer Übertragung in eine produktive Umgebung testen.

Es ist sehr wichtig, dass das Paket, das während der CI generiert und während der CD bereitgestellt wird, dasselbe ist, das in allen Umgebungen installiert wird, und dies sollte bis zur Produktion der Fall sein. Allerdings kann es je nach Umgebung zu unterschiedlichen Transformationen der Konfigurationsdateien kommen, aber der Anwendungscode (Binärdateien, DLL und JAR) muss unverändert bleiben. Hierbei kann auch ein Container Image mit eines eindeutigen Hash Werts dienen. ⁴ Diese Unveränderlichkeit des Codes ist die einzige Garantie dafür, dass die in einer Umgebung geprüfte Anwendung die gleiche Qualität aufweist wie die in der vorherigen Umgebung eingesetzte Version und diejenige, die in der nächsten Umgebung eingesetzt wird. Wenn nach der Überprüfung in einer der Umgebungen Änderungen (Verbesserungen oder Fehlerbehebungen) am Code vorgenommen werden sollen, muss die Änderung erneut den CI- und CD-Zyklus durchlaufen.

Continuous Deployment ist eine Erweiterung von CD, diesmal jedoch mit einem Prozess, der die gesamte CI/CD-Pipeline automatisiert, und zwar von dem Moment an, in dem der Entwickler seinen Code festschreibt, bis zur Bereitstellung in der Produktion durch alle Überprüfungsschritte.

Diese Praxis wird in Unternehmen nur selten umgesetzt, da sie eine breite Palette von Tests (Unit-, Funktions-, Integrations-, Leistungstests usw.) für die Anwendung erfordert und die erfolgreiche Ausführung dieser Tests ausreicht, um das ordnungsgemäße Funktionieren der Anwendung mit all diesen Abhängigkeiten zu validieren, aber auch die automatisierte Bereitstellung in einer Produktionsumgebung ohne jegliche Genehmigungsmaßnahmen. Der kontinuierliche Bereitstellungsprozess muss auch alle Schritte zur Wiederherstellung der Anwendung im Falle eines Produktionsproblems berücksichtigen. Die kontinuierliche Bereitstellung kann durch den Einsatz und die Implementierung von Feature-Toggle-Techniken (oder Feature-Flags) realisiert werden, bei denen die Funktionalitäten der Anwendung in Features gekapselt und deren Features bei Bedarf direkt in der Produktion aktiviert werden, ohne dass der Code der Anwendung neu bereitgestellt werden muss. ⁵

Integration von Containern in CI/CD-Pipelines

Container vereinfachen die kontinuierliche Erstellung und Bereitstellung von Anwendungen. Durch die Verknüpfung mit einer CI/CD Pipeline kann die Geschwindigkeit und Zuverlässigkeit der Bereitstellung erhöht werden. ⁶ In der Abbildung 2{reference-type="ref" reference="fig:cicd-for-container"} ist exemplarisch ein solcher Prozess vereinfacht dargestellt. Es wurden in diesem Schaubild die verschiedenen Bereitstellungsmöglichkeiten exemplarisch zusammengefasst.

1. Der Quellcode der Anwendung wird durch den Entwickler geändert.

2. Ein Commit wird zum Azure Repository durchgeführt.

3. Mithilfe einer Azure Pipeline oder Jenkins Pipeline würde nun der Test und Build-Vorgang ausgelöst werden.

4. Das generierte Image wird an die ACR übertragen.

5. Der Continuous Deployment-Trigger orchestriert die Bereitstellung von Anwendungsartefakten mit umgebungsspezifischen Parametern. Zuvor können auch noch Freigabeprozesse eingebaut werden.

6. Es erfolgt eine Bereitstellung mittels AKS, ACA oder ACI.

7. Hierzu wird das jeweilige Containerimage aus der Azure Registry gezogen.

8. Über Azure Application Insights lassen sich nun Leistungs- und Analysedaten sammeln.

9. Das Backlog wird aktualisiert und der Entwickler schließt den Change.

Weiter zur Implementierung