Agile Projekte verlangen agile Methoden – „Software-Nerds“ lieben Automatisierung
Beim Thema Automatisierung wird von manchen Skeptikern schnell der Nachteil ins Feld geführt, dass die Flexibilität und Anpassungsfähigkeit mit zunehmenden Automatisierungsgrad leidet. Möge dieses Argument mit Einschränkung für logistische Systeme als solches gelten, so gilt dies keineswegs im Rahmen agiler Softwareentwicklung. Im Gegenteil: agile Projekte, individuelle Kundeninstanzen einer Softwareapplikation fordern regelrecht Automatisierung, um eine Zusammenführung (merge) unterschiedlicher Quellcodeteile (Branches) effizient zu ermöglichen. Somit kann die Codebasis stets aktuell und kurzfristig ausgeliefert werden. Bereits im „Agilen Manifest“ heißt es im ersten Prinzip: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.“ [Quelle: http://agilemanifesto.org/iso/de/principles.html]
Unabhängig vom Agilen Manifest ist bekannt, dass mit steigender Agilität in der Softwareentwicklung zwangsläufig auch die in der Prozessplanung sogenannten Verteilzeiten steigen. Kleine Pakete (Sprints) sollen in kurzen Zyklen entwickelt (build), getestet (test) und schlussendlich bereitgestellt (deployed) werden. Der Aufwand neben der eigentlichen Quellcode-Entwicklung steigt zu Gunsten der Agilität im Gesamtprojekt, je kleiner die Pakete sind. Potenzierend für den zusätzlichen Aufwand, wirkt dabei die die Herausforderung individueller Kundeninstanzen für eine Softwarelösung. Jede einzelne Instanz muss release-fähig gehalten bzw. stets auf die aktuelle Codebasis zurückgeführt werden und die individuellen Konfigurationseinstellungen sind bei jeder Änderung spezifisch zu testen.
Der typische Entwicklungsprozess für neue Funktionen beginnt mit einer Spezifikation der Anforderungen durch einen Produktmanager und Produktmanagerinnen. Diese werden anschließend in kleinere Aufgabenpakete zerlegt und durch die Softwareentwickler und Softwareentwicklerinnen abgearbeitet. Nach Fertigstellung der Programmierung durchläuft der Code zunächst eine Reihe von statischen Tests und Analysen zur Qualitätssicherung. Anschließend wird die, um die neue Funktion erweiterte Software, auf ein Testsystem ausgerollt und wird einer Vielzahl von Funktionstests unterzogen. Diese Tests stellen sicher, dass die Umsetzung den initial definierten Anforderungen entspricht und fehlerfrei funktioniert. Zusätzlich wird überprüft, ob alle bestehenden Funktionalitäten weiterhin einwandfrei zur Verfügung stehen.
Nach erfolgreichem Abschluss der Tests und der Abnahme durch den zuständigen Produktmanager und Produktmanagerin und/oder den Kunden, wird der neue Quellcode in die aktuelle release-fähige Codebasis integriert (merge). Je nach Anforderung des Kunden, können die neuen Funktionen nun entweder unmittelbar oder zu einem späteren Zeitpunkt als Teil eines größeren Funktionsupdates auf das jeweilige Produktivsystem ausgerollt werden. Die Dauer von der Spezifikation bis zum erfolgreichen Roll-Out kann hierbei je nach Umfang zwischen wenigen Minuten und mehreren Wochen liegen.
Erkennbar ist, dass die Tests zur Qualitätssicherung unerlässlich aber zugleich, wenn manuell durchgeführt, zeitaufwändig und somit kostenintensiv sind. Somit bietet es sich an, Features zu bündeln und in größeren Batches zu releasen, um die notwendigen Testaufwände zu minimieren. Dies widerspricht jedoch dem eingangs erwähnten Ziel, unseren Kunden frühzeitig und kontinuierlich Aktualisierungen und Features zur Verfügung zu stellen. Gleichzeitig erhöht dieses Vorgehen die Komplexität der Updates, was unter Umständen dazu führen kann, dass zusätzliche Zeitaufwände für das Zusammenführen und Integrieren der einzelnen Code-Bestandteile anfallen, die sogenannte „Integration Hell“.
Um diese Lücke zu schließen und der Hölle bei der Code-Integration zu entkommen, setzt die LOGSOL GmbH zukünftig auf die Methoden Continuous Integration (CI), Continuous Delivery (CD) und Continuous Deployment (CD). Diese ergänzen die bei LOGSOL bereits etablierte agile Denkweise und DevOps-Kultur. Vielleicht lassen sie sich sogar zukünftig noch besser verbinden (siehe Abbildung).
Continuous Integration (CI) stellt die erste Stufe dar, welche zunächst einen grundsätzlichen Wandel im Workflow der Softwareentwicklung erfordert. Ziel ist es, Softwareanpassungen zukünftig nicht mehr gesammelt, sondern unmittelbar und so häufig wie möglich zu testen und zu mergen – im besten Fall mehrfach täglich. Dies würde bei einer manuellen Qualitätskontrolle einen immensen Aufwand erzeugen, welcher den eigentlichen Entwicklungsaufwand um ein Vielfaches übersteigen kann. Die Lösung hier bietet eine verstärkte Standardisierung und Automatisierung entlang des gesamten Workflows, die sogenannte CI-Pipeline. Diese Pipeline beinhaltet Tools und Funktionen, welche jedes Mal automatisch angestoßen werden, sobald ein neuer Code hinzugefügt und eine vollständig automatisierte Qualitätskontrolle des aktuellen Softwarestands durchgeführt wurde. Diese umfasst neben statischen Überprüfungen auf Konformität mit den Richtlinien zur sicheren Softwareentwicklung auch sogenannte automatische User Acceptance Tests (UAT). Die Validierung, ob die Software weiterhin den Kunden- und Nutzeranforderungen entspricht und vollumfänglich funktionsfähig ist, wird damit automatisiert. Dazu werden nicht nur die im Rahmen der Anpassung betroffenen Komponenten getestet, sondern die gesamte Software inklusive aller existierenden Funktionen untersucht. Der Grad der Testautomatisierung liegt selten über 75 %, sollte jedoch die 20 % der Software abdecken, welche für die Funktion maßgeblich sind. Durch die hohe Häufigkeit von Testdurchführungen im CI-Pipeline-Konzept ist der Break-Even zwischen Aufwand zur UAT-Erstellung und Nutzen schnell erreicht. Für die Implementierung der UAT’s wurden aktuell durch die zuständigen Produktmanagerinnen und Projektmanager alle möglichen Anwendungsfälle definiert (inklusive Negativtests). Das Test-Team setzte anschließend die UAT‘s so um, dass jeder Test vollautomatisch direkt in der Software ausgeführt und mit dem erwarteten Ergebnis verglichen wird. Im optimalen Fall werden diese Tests bereits vor Beginn der eigentlichen Programmierung definiert und erstellt, sodass Softwareentwicklerinnen und Entwickler bereits ab der ersten Codezeile ihre Lösung gegen die Spezifikation validieren können. Hierdurch reduziert sich der nötige Aufwand für das tatsächliche Testen der Software auf ein Minimum. Im Gegenzug entsteht jedoch ein einmaliger initialer Aufwand für das Erstellen, Erweitern bzw. Anpassen der automatischen User Acceptance Tests. Zukünftig kann so jedoch garantiert werden, dass jede Anpassung einem standardisierten Testprozess unterzogen wurde und die Software einwandfrei funktioniert.
Am Ende des CI-Workflows bzw. der CI-Pipeline steht somit ein Softwarestand, welcher jederzeit durch einen Mitarbeitenden gepackt, konfiguriert und auf ein Produktiv- oder Testsystem ausgerollt werden kann. In diesem Kontext geht das Konzept zum Continuous Delivery (CD) noch einen Schritt weiter und stellt die nächste Stufe der geplanten Automatisierung bei LOGSOL dar. Hierbei ist der CI-Workflow um die nötigen Schritte zu erweitern, um die Software so vorzubereiten, dass sie jederzeit ohne weitere manuelle Eingriffe ausgerollt werden kann. Am Ende der Pipeline wird die Software automatisch zusammen mit allen nötigen Komponenten in einem sogenannte Repository bereitgestellt. Von hier kann sie per Knopfdruck z. B. durch einen Produktmanager und Projektmanagerin auf ein Produktivsystem eingespielt werden. Somit obliegt die Entscheidung, wann und wo, welche Funktion in ein Live-System released werden, den zuständigen Produktmanagern in enger Abstimmung mit dem Kunden.
Continuous Deployment, als letzte Ausbaustufe, stellt alle Tools so bereit, dass auch der letzte Schritt, also das Deployment auf das Produktivsystem vollautomatisch erfolgt. Hierdurch ist es möglich, dass neue Funktionen und Anpassungen bereits Minuten nach dem Einchecken des neuen Codes auf dem Produktivsystem des Kunden zur Verfügung stehen, ohne dass manuelle Eingriffe und Zwischenschritte durch Softwareentwicklerinnen und Softwareentwickler oder Produktmanager und Produktmanagerinnen erforderlich sind. Durch eine gute und vollständige Testabdeckung innerhalb der CI/CD-Pipeline kann gleichzeitig gewährleistet werden, dass die spezifizierten Anforderungen erfüllt wurden und die bestehenden Komponenten weiterhin wie gewünscht funktionieren. Dank der LOGSOL-Entwicklungsabteilung wird die technische Basis für die Pipeline bis zum Jahreswechsel 2020-2021 bereitstehen. Doch bereits jetzt heißt es, dass neue Vorgehen kulturell zu etablieren und die automatisierten Tests stetig zu warten und zu pflegen.
Die beschriebene Automatisierung der Integrations-, Delivery- und Deployment-Prozesse in der Softwareentwicklung zu Gunsten der Agilität in den Kundenprojekten wirkt als Katalysator für die Testautomatisierung. Der Spagat bei der Entscheidung, was bzw. wie viel getestet wird und dem gegenüberstehenden Aufwand/Risiko, bleibt jedoch in jedem Fall spannend und lässt sich (noch) nicht automatisieren – wir bleiben dran!
