Modernes Enterprise Software Engineering mit CI/CD-Pipelines

Für modernes Enterprise Software Engineering sind CI/CD-Pipelines unerlässlich, um Entwicklungsprozesse zu optimieren. mgm setzt dabei auf standardisierte Methoden und Umgebungen entlang des gesamten Entwicklungs-, Build- und Deployment-Prozesses. Diese sind speziell für den Betrieb von containerisierten Anwendungen in modernen Cloud-Infrastrukturen ausgelegt.

Schon vor dem Aufkommen von Build- und Deployment-Pipelines traten in klassischen Build-Prozessen häufig typische Fehler auf. Die manuelle Ausführung vieler Schritte und die Verwendung von Build- oder Shell-Skripten waren gängige Praxis, was häufig zu verteiltem Wissen und Kommunikationsengpässen führte. Die Koordination von Releases erforderte einen hohen Kommunikationsaufwand, während die Vielzahl von Deployment-Umgebungen und Konfigurationen eine komplexe Herausforderung darstellte. Zudem dauerte der Start der gesamten Build-Kette sehr lange.

Von monolithisch zu agil: Microservices-Orchestrierung als Transformationsfaktor

Heute reichen herkömmliche Build-Management-Methoden häufig nicht mehr aus, um Quellcode effizient in funktionierende Software umzusetzen. Der Grund: Moderne Entwicklungsumgebungen stehen vor der Aufgabe, sich immer stärker an agilen Anforderungen auszurichten und Software in immer kürzeren Zeiträumen bereitzustellen. Traditionelle monolithische Architekturen werden daher zunehmend durch skalierbare und flexibel einsetzbare Microservices ersetzt werden. Diese bestehen aus eigenständigen, funktionalen Diensten mit unabhängigen Codebasen, die eine schnellere Bereitstellung und Entwicklung ermöglichen. Aufgrund ihres verteilten Charakters, der komplexen Kommunikation und Datenverwaltung sowie der Herausforderungen bei der Bereitstellung und dem Testen, erfordern Microservices jedoch eine sorgfältige Planung und Implementierung. Gerade in großen oder wachsenden Projekten mit vielen Microservices kann es daher schnell unübersichtlich werden.

Wenn Build- und Integrationsprozesse in großer Zahl über mehrere Stages verteilt sind, stoßen herkömmliche Build-Tools an ihre Grenzen. Die Lösung? Orchestrierungstools – sie vereinen diese vielen Schritte und Werkzeuge zu einem harmonischen Zusammenspiel. Mit nur wenigen Klicks entfaltet sich die gesamte Abfolge vor unseren Augen. Resultate werden nicht nur präsentiert, sondern sinnvoll archiviert. Selbst bei komplexen Build- und Scripting-Schritten genügt ein einziger Mausklick, um das Endprodukt in Rekordzeit zu erschaffen und automatisiert zu prüfen.

Aus dieser Notwendigkeit heraus sind die beiden Ansätze Continuous Integration (CI) und das Continuous Delivery (CD) entstanden. Sie haben die Art und Weise, wie Software entwickelt, getestet und ausgeliefert wird, revolutioniert.

CI/CD: Definition und Nutzen

CI und CD sind agile Praktiken in der Softwareentwicklung. Agil bedeutet hier, schnell ein lauffähiges IT-Produkt zu erzeugen. Untersuchungen haben gezeigt, dass der Aufwand für Wartung und Weiterentwicklung einer Software mittlerweile mehr als die Hälfte der Gesamtkosten ausmacht. Dies bedeutet, dass eine schnelle Produktentwicklung in Verbindung mit einer frühzeitigen Fehlererkennung mit höherer Wahrscheinlichkeit zum Erfolg führt.

Hier setzt Continuous Integration an, ein Prozess, bei dem Code-Änderungen regelmäßig in einem gemeinsamen Repository, einer zentralen Ablage für Daten, Dokumente, Programme, Metadaten und Datenmodelle, zusammengeführt werden. Die Entwickler:innen integrieren ihre Änderungen mehrmals täglich, um Probleme frühzeitig zu erkennen. Das vermeidet umfangreiche Code-Änderungen mit langen Entwicklungszyklen und Verzögerungen, was die Entwicklungszeit deutlich verkürzt. Dadurch können Teams schneller auf Änderungsanforderungen reagieren und diese erfüllen.

Während bei Continuous Delivery die automatisierte Bereitstellung und das Testen im Vordergrund stehen, geht Continuous Deployment noch einen Schritt weiter, indem es zusätzlich die automatische und direkte Überführung in die Produktionsumgebung umfasst – den automatisierten Release-Prozess, bei dem Änderungen ohne menschliches Eingreifen direkt in den Live-Betrieb überführt werden.

Dies kann die Geschwindigkeit der Softwareauslieferung weiter erhöhen, birgt aber auch das Potenzial für unerwünschte Fehler oder Unterbrechungen. Deshalb ist eine gründliche Automatisierung und Testung für ein reibungsloses Continuous Deployment unerlässlich. Insgesamt ermöglichen die CI/CD-Praktiken aber eine deutlich agilere und reaktionsfähigere Softwareentwicklung als mit traditionellem Build-Management.

Wie wird CI/CD umgesetzt?

CI/CD automatisiert den Weg von der Code-Integration bis zum Deployment durch Testgetriebene Entwicklung (TDD), die in der Regel mehrere Stufen umfasst. Als erstes findet der entstandene Code seinen Weg in ein Versionskontrollsystem wie Git. Dies ermöglicht nicht nur die Nachverfolgung von Änderungen, sondern fördert auch die Zusammenarbeit mehrerer Entwickler und die Rückkehr zu früheren Codezuständen.

Im nächsten Schritt erweist sich die Continuous Integration (CI) als entscheidend. Dabei wird der Code nach jedem Commit – einer bestätigenden Freischaltung einer bestimmten oder mehreren Änderungen – automatisch auf einem integrierten Entwicklungsserver überprüft und getestet. Ziel ist es, Fehler frühzeitig zu erkennen und eine reibungslose Integration in den bestehenden Code zu gewährleisten.

Automatisierte Tests spielen eine zentrale Rolle, um sicherzustellen, dass der Code einwandfrei funktioniert und keine unerwünschten Nebeneffekte hat. Dazu gehören verschiedene Tests, von Unit-Tests über Integrationstests bis hin zu Akzeptanztests. Nach erfolgreichem Testen wird der Code in ein ausführbares Format gebracht, das für die Auslieferung bereit ist. Hier kommt entweder Continuous Delivery (CD) oder Continuous Deployment (CD) ins Spiel. Bei Continuous Delivery wird der Code in eine produktionsähnliche Umgebung eingespielt, um eine abschließende Überprüfung zu ermöglichen. Im Gegensatz dazu erfolgt beim Continuous Deployment die automatische Übertragung in die Produktionsumgebung nach bestandenen Tests. Im laufenden Betrieb wird die Anwendung kontinuierlich überwacht, um die Performance und Stabilität sicherzustellen. Diese Metriken liefern wertvolles Feedback für den Entwicklungsprozess, um kontinuierliche Verbesserungen vorzunehmen.

Bei Continuous Delivery geht es also darum, die Anwendung in einem Zustand zu halten, in dem sie jederzeit „mit ein paar Klicks“ in die Produktion überführt werden kann.

Die richtige Einstellung: gemeinsam an einem Strang

Es ist in diesem Zusammenhang wichtig zu verstehen, dass CI/CD nicht nur eine technische Strategie ist. Vielmehr geht es um die grundsätzliche Denkweise, wie an diese Prozesse herangegangen wird und was die treibende Kraft hinter der Notwendigkeit einer solchen Pipeline ist.

Die meisten Herausforderungen im Zusammenhang mit CI/CD sind eher sozialer als technischer Natur. Denn bei der Umsetzung dieses Prozesses mit CI/CD-Tools geht es nicht nur um technische Aspekte wie die Nutzung von Plattformen wie Jenkins, um die Pipeline zu erstellen und aufzubauen. Viel wichtiger ist der gemeinsame Ansatz im Unternehmen. Alle müssen das Ziel verfolgen, die Pipeline zu optimieren. Eine Kultur der gegenseitigen Unterstützung statt der Schuldzuweisungen ist entscheidend. Wenn ein Fehler in der CI/CD-Kette auftritt, geht es nicht darum, wer ihn verursacht hat, sondern darum, gemeinsam nach Lösungen zu suchen.

Deshalb ist im CI/CD-Zyklus ein klar verständliches Feedback von entscheidender Bedeutung. Ähnlich wie beim Build Management gibt es Indikatoren wie Ampeln, Sonnenschein, Regenwetter und Diagramme, die eine nachvollziehbare Historie der gesamten Continuous Integration/Continuous Delivery-Pipeline anzeigen. Diese visuellen Elemente zeigen, wie der Ablauf war, wo Fehler aufgetreten sind, und machen den Prozess archivierbar und nachvollziehbar.

Dabei spielen die Motivation aller an der CI/CD-Pipeline Beteiligten und die Fehlerkultur im Unternehmen eine zentrale Rolle. Es sollen möglichst keine ungelösten Probleme hinterlassen werden. Dieser als “no broken windows” bekannte Gedanke betont, dass keine Zustände hinterlassen werden sollen, die die gesamte Produktionskette gefährden könnten. Entscheidend ist die richtige Einstellung: Gemeinsam an einem Strang ziehen und den Fehler untersuchen, um zu verstehen, warum er aufgetreten ist – und um sicherzustellen, dass er nicht wieder auftritt. Dies ist umso einfacher, wenn eine erfolgreiche CI/CD-Pipeline vorhanden ist.

CI/CD und Low Code: die Pipelines bei mgm technology partners

mgm hat eigene, erprobte Build- und Deployment-Pipelines für die mgm A12 Low Code-Plattform entwickelt, die bereits in zahlreichen Projekten erfolgreich eingesetzt wurden. Eine schematische Übersicht verdeutlicht den grundsätzlichen Ablauf dieses Prozesses.

Die Pipeline dient als Wegweiser von der Quellcodebasis bis zur produktionsbereiten Software – ein Entwicklungspfad von links nach rechts. Jeder Schritt wird durch markierte Abschnitte dargestellt, die die verschiedenen Entwicklungsphasen repräsentieren. Ein bemerkenswerter Aspekt dieses Ansatzes ist die weitgehende Automatisierung der meisten Schritte, was nicht nur Zeit spart, sondern auch menschliche Fehler minimiert.

Das Herzstück dieses Prozesses ist der Jenkins Build Server, eine weit verbreitete Open-Source-Automatisierungsplattform. Er übernimmt eine zentrale Rolle bei der Initiierung und Koordination der Build- und Deployment-Jobs. Dieser durchdachte Ansatz für einen reibungslosen Ablauf des gesamten Entwicklungsprozesses garantiert eine erstklassige Softwarequalität.

In den ersten beiden Abschnitten der Pipeline werden die A12-Modelle und der Quellcode aus der Git-Quellcodeverwaltung extrahiert und generiert. Nach dem Kompilieren werden die generierten Ergebnisse in einer Container-Registry gespeichert. Von dort aus können diese Images in den folgenden Phasen auf Testplattformen eingespielt werden, wo sie mit spezifischen Testwerkzeugen wie Selenium, JFunk, Perfload und Cypress getestet werden. Bei Bedarf werden weitere Schritte wie Lasttests mit Tools wie Perfload durchgeführt. Nach einem erfolgreichen Build werden die Artefakte einer statischen Codeanalyse unterzogen, um mögliche Fehler und Defekte automatisch zu erkennen. Schließlich erfolgt der letzte Schritt in der Pipeline – das Deployment der Software auf ein Produktivsystem.

CI/CD – Fazit, Trends und Zukunft

CI/CD ist nicht nur eine Methode zur Optimierung von Code-Änderungen, sondern auch eine Methode zur Optimierung der Zusammenarbeit zwischen Teammitgliedern. Der proaktive Umgang mit potenziellen Problemen und die kontinuierliche Optimierung des Codes fördern eine dynamische, produktive und effiziente Entwicklungsumgebung. In einer Zeit, in der Innovation und Geschwindigkeit den Ton angeben, ist es von unschätzbarem Wert, eine Entwicklungsumgebung zu schaffen, die nicht nur technologisch auf dem neuesten Stand ist, sondern auch die Stärken jedes einzelnen Teammitglieds nutzt.

Die kommenden Jahre versprechen eine spannende Weiterentwicklung von Continuous Integration und Continuous Delivery. Die Integration von KI wird Vorhersagen optimieren, während Sicherheit und Compliance stärker in den Entwicklungszyklus integriert werden. Hybride Umgebungen und Container-Technologien erfordern flexible Bereitstellungsstrategien. Infrastructure as Code und kontinuierliches Monitoring sorgen für Konsistenz. Die DevOps-Kultur bleibt entscheidend für eine nahtlose Zusammenarbeit. CI/CD wird die Softwareentwicklung in Zukunft noch agiler, sicherer und effizienter machen.

Weiterführende Informationen:

• Unterstützung bei der Einführung von Continuous Integration- und Continuous Deployment-Prozessen: https://www.mgm-sp.com/agile-security-secure-devops/

Weiterführende Literatur:

• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, by David Farley, Jez Humble, Released July 2010, Publisher(s): Addison-Wesley Professional, ISBN: 978-0-321670-25-0
• Jenkins: The Definitive Guide, by John Ferguson Smart, Released July 2011, Publisher(s): O’Reilly Media, Inc., ISBN: 978-1-449305-35-2
• The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win, by Gene Kim, Kevin Behr, George Spafford, Released 2018, Publisher(s): IT Revolution Press, ISBN: 978-1-942788-29-4