Schneller, höher, weiter – Continuous Integration und DevOps bei EXAD 2.0

Continuous Integration und DevOps

Was sind Continuous Integration und DevOps?

Continuous Integration ist eine Technik der agilen Softwareentwicklung. Unter dem Begriff ist eine Coding-Philosophie sowie ein Methodenset zu verstehen, das geschaffen wurde, um Softwareentwickler bei der regelmäßigen Integration kleinerer Änderungen am Programmcode zu unterstützen. Darüber hinaus können Code-Teile so auf regelmäßiger Basis in Repositories zur Versionskontrolle fließen. Bei dieser Entwicklungsmethode wird Software kontinuierlich erweitert und verbessert. Die neuen Releases sind schmaler, der Umfang an Features geringer. Die Kunden profitieren dadurch von einem schnelleren Feedback und einer verbesserten User Experience.

Zu DevOps existiert keine Zertifizierungsgrundlage. Der Begriff ist am ehesten als Beschreibung eines Betriebsverfahrens in Abgrenzung zu früheren Methoden zu verstehen. In unserer Darstellung meint DevOps vor allem die Konzeption, Umsetzung und Anwendung eines CI/CD (= Continuous Delivery)-Prozesses im Rahmen der Entwicklung eines Softwareprodukts. Man spricht im Kontext von CI/CD auch von Pipelines, die diverse Schritte automatisiert abarbeiten. Alle Aufgaben mit Ausnahme der inhaltlichen Prüfung neuer oder geänderter Features laufen in solchen automatisierten Pipelines ab.

In einem CI/CD-Prozess wird die Software „kontinuierlich“ bei jeder Änderung mit allen Abhängigkeiten „integriert“ und bereitgestellt/„geliefert“. Des Weiteren erfolgen:

• Analyse der Softwarequellen und Abhängigkeiten auf typische Fehler und bekannte Sicherheitslücken.
• Erstellen einer neuen Softwareversion aus den Softwarequellen unter Berücksichtigung aller benötigten Abhängigkeiten (Build)
• Testen der Software auf verschiedenen Ebenen (Unit- und Integration-Tests)
• Die in den vorherigen Schritten erstellte und getestete Softwareversion wird jetzt ebenfalls automatisiert in eine Integrations-Umgebung (INT) ausgeliefert. Dort werden weitere Tests (Ende-zu-Ende-Tests, Smoke-Tests) automatisch durchgeführt.

All diese Schritte erfolgen bis hierher vollständig automatisch ohne menschliche Interaktion in einer Pipeline. Als nächstes folgt die Bereitstellung der neuen Softwareversion in eine QA-Umgebung (QA=Quality Assurance). Diese ist der produktiven Umgebung so weit wie möglich nachempfunden. Die technische Auslieferung erfolgt auch hier in einer automatisierten Pipeline. Den Auslöser gibt aber der Product Owner. In diesem System können (Zwischen-)Ergebnisse mit den (zukünftigen) Nutzern verifiziert werden. Wenn eine Softwareversion in der QA-Umgebung erfolgreich verifiziert wurde, kann diese Version dann in die produktive Umgebung ausgeliefert werden. Auch hier erfolgt die technische Auslieferung automatisiert in einer Pipeline. Am Ende kann durch weitere automatische Smoke-Tests in der Produktivumgebung sichergestellt werden, dass im letzten Schritt keine gravierenden Probleme aufgetreten sind. Diese Tests sind in der Regel bereits im Integrations- und QA-System ausgeführt worden. Da INT-/QA- und Produktivumgebung aber niemals völlig identisch sein können, dient dieser Schritt als zusätzliche Versicherung. In jedem Fall wurde bei der Verifikation Feedback generiert, das jetzt wieder in die Weiterentwicklung der Software einfließen kann und so den Kreis schließt.

Der Nutzen von Continuous Integration

Die Umsetzung eines CI/CD-Prozesses bringt verschiedene Vorteile mit sich. Dabei erhöht jeder zusätzlich umgesetzte automatische Schritt die Wirksamkeit dieser Vorteile.

Der offensichtliche Vorteil ist die Vermeidung von manueller repetitiver Arbeit. Durch die Automatisierung von Arbeitsschritten können Entwickler-Ressourcen für wertschaffende Aufgaben eingesetzt werden.

Der zweite Vorteil ist aber weit bedeutender. Denn durch den Einsatz eines CI/CD-Prozesses kann die Softwarequalität und damit die Zuverlässigkeit, Sicherheit und Wartbarkeit der Software auf ein Level gehoben werden, das ohne diese Automatisierung nicht erreichbar wäre. Denn:

• Manuelle Prozesse sind immer fehleranfällig.
  
• Fehler treten zwar auch in automatisierten Prozessen auf, dort können sie aber mit einer einmaligen Korrektur dauerhaft abgestellt werden.
  
• Der Umfang einer automatisierten Testsuite wächst (bei gleichem Ressourceneinsatz) zwar langsamer als der Umfang einer manuellen Testsuite, aber die „zeitliche“ Testabdeckung (Wie oft kann ich den Test durchführen?) ist schon ab dem ersten automatischeren Test höher.
  
• Im Laufe der Zeit ermöglicht dies auch einen „räumlichen“ Testumfang (Wie viel des Codes ist durch Tests abgedeckt?), der größer ist als das mit manuellen Tests möglich wäre.

Der dritte Vorteil ist für die Nutzer wahrscheinlich sogar noch wichtiger als der zweite. Denn durch den Einsatz eines CI/CD-Prozesses kann die Time-To-Market von neuen Features (und auch Fehlerbehebungen) deutlich verbessert werden. Wenn keine manuellen Tests nötig sind, kann eine neue Version schneller in der QA- oder sogar der Produktivumgebung bereitgestellt werden. Dies ermöglicht schnelleres Feedback und unterstützt so den agilen Entwicklungsprozess. Dadurch können für den Nutzer wertvolle Verbesserungen schneller bereitgestellt werden. Außerdem kann der Aufwand, der in die Umsetzung von falsch verstandenen Features investiert wird, minimiert werden. Es stehen dann mehr Ressourcen für die weitere Verbesserung zur Verfügung.

Fazit

Bei EXAD 2.0 zeigen sich im Aufbau des CI/ CD-Prozess bereits jetzt deutliche Qualitätssteigerungen in der Softwareentwicklung. Die bisher umgesetzten Schritte haben sich als sehr wertvoll erwiesen. Dies zeigt sich zum Beispiel daran, dass jeden Morgen eine getestete Softwareversion bereitsteht, die die Ergebnisse des vorangegangenen Tages integriert. Diese neue Version kann dann mit Hilfe von Pipelines auch von Mitarbeitern ohne ausgeprägten technischen Hintergrund selbstständig ausgeliefert und begutachtet werden. Das Kundenfeedback bestätigt den richtigen Kurs. Deshalb werden wir auch in Zukunft weiter im Bereich DevOps investieren.