Agile Softwareentwicklung mittels DevOps-Workflows

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. In der RISC Software GmbH haben wir 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.

Kontakt

Autor

Florian Haßler

Software Engineer