Agile Softwareentwicklung mittels DevOps-Workflows

Fachbeitrag von Florian Haßler, RISC Software GmbH

23.03.2022

Das Entwickeln und Veröffentlichen von Software kann sich aufwendig gestalten. Manuelle Test-, Integrations- und Veröffentlichungsschritte nehmen sehr viel Zeit in Anspruch und sind fehleranfällig. Oft traten deshalb in der Vergangenheit Showstopper erst sehr spät im Projektverlauf in Erscheinung und zwangen alle Beteiligten, einige Schritte zurück zu gehen. Ein Mittel, um mit dieser Problematik umgehen zu können stellt ein CI/CD-DevOps-Workflow dar.

Workflow

Der Workflow grob erklärt: Die Entwickler:innen wählen ein vom Kunden erfasstes und fertig spezifiziertes Ticket. Es wird damit begonnen, Tests zu schreiben und in weiterer Folge dann das Feature in Code zu gießen (vgl. Beitrag zu Test-Driven Development). All das geschieht fernab der aktiven Codebasis der Applikation in einem abgetrennten Code-Bereich. Bevor das Feature nach Erfüllung aller Akzeptanzkriterien in die aktive Codebasis integriert wird, wird es automatisiert auf Herz und Nieren geprüft. Erst, wenn es geprüft wurde, wird es auf das Testsystem, und in weiterer Folge auf das Produktivsystem veröffentlicht. Warum automatisiert? In den Automatisations-Pipelines können Tests einmal definiert werden und damit die verbundenen Anforderungen immer ohne menschliches Zutun sichergestellt werden. Containerisierung hilft zusätzlich noch dabei, die Tests reproduzierbar zu machen. Auch das Veröffentlichen erfolgt automatisiert. Wenige Minuten nach der Umsetzung ist ein neues Feature auch schon auf dem Testsystem unserer Kund:innen sichtbar und steht für Anwender*innen-Tests zur Verfügung. Programmierfehler dringen dabei aufgrund automatisierter Tests nur äußerst selten bis zum Testsystem durch. Dadurch müssen sich Kund*innen nicht mit diesen Fehlern herumschlagen und können sich auf die Inhalte der Features konzentrieren. Im weiteren Verlauf beschreibt dieser Artikel nun, wofür die Abkürzungen CI und CD bei den Entwickler:innen der RISC Software GmbH stehen. Mit den hier vorgestellten vier Strategien wird der Arbeitsalltag für Entwickler*innen und Anwender*innen stark vereinfacht.

Erfahrung mit Pipelines

Plattformen zur Umsetzung solcher Automatisations-Pipelines gibt es einige. Die RISC Software GmbH hat Erfahrung mit Concourse, Jenkins und GitLab. Speziell bei den Web-Entwicklungs-Teams hat sich gezeigt, dass sie GitLab am besten in ihre Workflows integrieren konnten.

CI – wie: Continuous Integration

Eine Idee von Continuous Integration ist es, neue Features so schnell und so oft wie möglich automatisiert zu integrieren. Es geht hier um kurze Feedback-Schleifen. Sie helfen den Entwickler:innen, Probleme zu identifizieren und zu beheben, bevor der Kontext gewechselt (also die nächste Aufgabe gestartet) wird. Die Kernfrage lautet: Lässt sich das entwickelte Feature in die bisherige Applikation integrieren, ohne negative Auswirkungen auf bestehende Funktionen zu haben?

Vereinfacht dargestellt spielen Entwickler:innen ihre Änderungen in unserem Source-Code-Management-System (SCM) ein und die CI-Pipeline beginnt zu arbeiten. Wenn sie fertig ist, benachrichtigt sie die Entwicklerinnen über Erfolg oder Misserfolg.

Abhängig vom Typ eines Projekts kommen verschiedene Tools in der Integrations-Pipeline zum Einsatz. Fast immer wird damit gestartet, dass die Test-Suits entsprechend ihrer Stellung in der Test-Pyramide (lt Mike Cohn) durchlaufen lassen werden. Unit-Tests bilden dabei die Basis der Test-Pyramide. Getestet werden kleinstmögliche Verhaltenseinheiten. Sie stellen sicher, dass der Code wie erwartet funktioniert. Anschließend wird mithilfe von Integrationstests sichergestellt, dass die Interaktion zwischen den verschiedenen Teilen der Applikation oder mit externen Komponenten ( z.B. Datenbanken) auch funktioniert. Schlägt ein Test fehl, wird die Test-Pipeline abgebrochen und das Dev-Team erhält eine Benachrichtigung.

Beinahe immer ist der letzte Schritt in den RISC-Software-GmbH-CI-Pipelines eine statische Code-Analyse durch ein entsprechendes Tool. Dieses hilft dabei, Schwachstellen und Inkonsistenzen mit allgemein üblichen Entwicklungspraktiken zu erkennen. Das in der RISC-Software verwendete Tool enthält viele eingebaute Regeln für verschiedene Programmiersprachen. Das Ergebnis der Analyse ist eine Bewertung der technischen Qualität des Source-Codes. Wie in der Abbildung ersichtlich, werden auch die Anzahl der Fehler, Schwachstellen, Testabdeckung, Anzahl der geschriebenen Codezeilen und noch vieles mehr ausgegeben. Die Entwickler*innen erhalten eine automatisierte Bewertung ihres Codes.

CD – wie: Continuous Delivery

Ist die CI-Pipeline erfolgreich durchlaufen und der Report des Code-Analyse-Tools zufriedenstellend ausgefallen, wird die Continuous Delivery-Pipeline manuell aktiviert. Sie verfolgt das Ziel, den Veröffentlichungs-Prozess automatisiert, schnell und zuverlässig auszuführen. Die in der CI-Pipeline gebauten Artefakte werden gesammelt und auf dem Testsystem veröffentlicht. Dieser Veröffentlichungs-Schritt kann einfach sein und einfach Source-Code auf einen Server kopieren oder auch komplexer. Das Zielsystem und der Ort des Zielsystems sind für die Komplexität ausschlaggebend.

Ein Vorteil, der im Zusammenhang mit Continuous Delivery oft genannt wird ist, dass die Applikation zu jeder Zeit veröffentlicht werden kann. Es gibt keinen Zeitpunkt, in dem sich in der aktiven Code-Basis des Versionsverwaltungssystems Code befindet, der nicht funktionsfähig wäre. Melden sich Kund*innen, weil ein Problem aufgetreten ist, kann das Team zeitnahe darauf reagieren und eine neue Version veröffentlichen. Ein weiterer Vorteil ist natürlich, dass keine klassischen Releases mehr nötig sind, sondern Feature für Feature direkt von Kund*innen getestet und abgenommen werden kann.

CD – wie: Continuous Deployment

Continuous Deployment führt die Schritte von Continuous Integration und Continuous Delivery einen Schritt weiter. Hier werden alle Änderungen, welche die CI-Pipeline erfolgreich durchlaufen, sofort auch freigegeben. Dieser Prozess ist vollständig automatisiert und nur ein fehlgeschlagener Integrationsschritt verhindert, dass die Änderungen auf das Test- und in weiterer Folge Production-System übertragen werden. Das funktioniert, wenn das Vertrauen in die Entwickler:innen, den Continuous Integration- und den Continuous Delivery-Prozess sehr groß ist. Continuous Deployment hat seinen Platz hauptsächlich im groß angelegten Produktentwicklungsgeschäft; im klassischen Projektgeschäft sind die dafür notwendigen Voraussetzungen oft nicht wirtschaftlich sinnvoll umzusetzen.

CI – wie Continuous Improvement

Die Abbildung unten zeigt die Benachrichtigung, die einige Dev-Teams am Morgen nach Bekanntwerden der Sicherheitslücke in der Java-Logging-Bibliothek Log4j ereilte. Die Sicherheitschecks der verwendeten Bibliotheken laufen jede Nacht automatisch, um die von uns entwickelten Applikationen sofort nach Bekanntwerden von Sicherheitslücken mit Patches zu versorgen. Außerdem helfen sie, regelmäßig die verwendeten Softwarebibliotheken in von der RISC-Software Gmbh entwickelten Applikationen zu aktualisieren und so diese up-to-date zu halten. Verbesserungen werden dabei inkrementell umgesetzt, evaluiert und anschließend weiter verbessert. Resultat sind schlankere Arbeitsabläufe und damit einhergehend mehr Zeit für die Umsetzung neuer Features.

Durch Continuous-Integration, Delivery, Deployment und Improvement hat die RISC Software GmbH die Fähigkeit gewonnen, häufige Releases ohne Qualitätskompromisse zu veröffentlichen.