Do Less

Die Erwartungshaltung von Nutzern an Anwendungen wird von Jahr zu Jahr größer. Das hat verschiedene Gründe: Einerseits steigen Qualität und Bedienbarkeit der privaten Endgeräte wie Smartphones und Tablets. Andererseits bieten gerade Apps wie Netflix, Uber, PayPal und Instagram ein überzeugendes Bedienkonzept. Heute sind daher nicht nur professionelle Nutzer und Technikbegeisterte anspruchsvolle Anwender. Einmal an den Komfort gewöhnt, möchte der Nutzer ihn nicht mehr missen. Das setzt jeden, der eine Anwendung zur Verfügung stellen will, unter Druck.

Die Lösung: Do Less

Die Antwort auf diese Herausforderung lautet „Do Less“. Sie ist etwas provokant formuliert, dabei aber beinahe zwanzig Jahre alt. Es handelt sich hierbei um eines der Prinzipien der Agilität, bei dem eine vordergründige Schwäche („Faulheit“) zu einer Tugend („Effizienz“) wird.

Materna wird diesem Anspruch in Kundenprojekten gerecht, indem sie agiles Vorgehen mit GitOps Workflows ganzheitlich kombiniert. Kern dieses Ansatzes ist es, konsequent zu automatisieren. Das geht weit über das klassische CI/CD (Continuous Integration / Continuous Delivery) hinaus, indem zusätzlich zu der Anwendung die verschiedenen Ausführungsumgebungen je nach Bedarf automatisiert erstellt, gestartet und wieder entfernt werden. Auch die manuellen Schritte im Entwicklungsprozess, wie Peer Reviewing, Abnahme und Freigabe für die Produktion, werden durch Werkzeuge wie GitLab gesteuert. Insbesondere gleichförmig wiederkehrende Abläufe sind nicht die Stärke von Menschen und werden daher automatisiert. So bleibt weniger auf der Strecke, wird fehlerhaft ausgeführt, missverstanden und verschwendet. Dies ermöglicht, den Fokus darauf zu legen, Mehrwert zu generieren.

Im Folgenden betrachten wir die verschiedenen Facetten des „Agile GitOps“-Ansatzes. Dabei wird nichts neu erfunden oder „auf links gekrempelt“, sondern Best Practices werden aus allen Bereichen zu einem einfachen Gesamtpaket zusammengeschnürt. Keep it simple, stupid.

Agiles Vorgehensmodell

Als Grundlage dient ein agiles Vorgehensmodell, zumeist Scrum. Das alleine hilft bereits durch kurze Feedback-Zyklen und agile Prinzipien. Letztere helfen, fokussiert an einem Produkt zu arbeiten und dabei die richtigen Prioritäten zu setzen. Sie bestechen mit einfach einzuprägenden Sätzen, die das Do-Less-Prinzip stützen:

• You Aren’t Gonna Need It (YAGNI): Setze nur das um, was du später wirklich benötigst.
• Big Design UpFront (BDUF): Beginne mit dem Big Picture. Versuche nicht, alles zu Beginn durchzudenken. Lass dir die Flexibilität, die du brauchst.
• Keep It Simple, Stupid (KISS): Mach die Dinge nicht komplizierter, als sie sind. Einfache Lösungen sind die Besten.
• Think big, start small: Habe Visionen, aber beginne mit einer überschaubaren Zielsetzung.

Agile Vorgehensmodelle wie Scrum und Kanban bleiben dabei auf einem sehr hohen Abstraktionsniveau. Das macht sie vielseitig einsetzbar und bietet zugleich Freiraum, problemspezifische Lösungsansätze in diese Frameworks einzubetten. Das nutzt der Agile GitOps-Ansatz, ohne die zentralen Werte der agilen Bewegung, wie z. B. „Qualität ist King“, zu vernachlässigen. Ganz im Gegenteil – die zentralen Werte werden unterstützt.

Die Abbildung beschreibt die Continuous-Lifecycle-Prozesse und ihre Schwerpunkte im Rahmen des Entwicklungsprozesses.

Microservice Toolstack

Wenn Unternehmen ein neues Projekt aufsetzen, ist eine der zeitaufwendigen Aufgaben, Technologien auszuwählen und die geeignete Entwicklungsumgebung einzurichten. Dieses Problem wird bei der Vielzahl an zur Verfügung stehenden Open-Source-Technologien immer größer und die Verantwortlichen müssen immer mehr Parameter in die Rechnung einbeziehen. Neben der rein fachlichen und technischen Entscheidung stellen sich Fragen wie:

• Welche Unternehmen unterstützen und nutzen das Projekt?
• Wie viele Personen arbeiten an dem Projekt?
• Wie aktiv ist das Projekt und wie häufig wird released?

Materna setzt hier auf einen Standard-Toolstack, sofern es im jeweiligen Projekt möglich ist. Für die speziellen Anforderungen des jeweiligen Projekts muss dann immer noch einiges entschieden werden, beispielsweise mit welchen Tools die „speziellen Anforderungen“ umgesetzt werden sollen. Vieles steht jedoch fest. Das führt dazu, dass ein großer Anteil der Entwickler diesen Toolstack beherrschen und sie flexibel eingesetzt werden können. Ferner muss gerade zu Beginn weniger abgestimmt werden. Der Standard-Toolstack umfasst modernste Backend-Technologien für Microservice-Architekturen, die On-Premise, Hybrid oder in einer Public Cloud wie AWS gehostet werden können. Materna präferiert die Cloud-Lösung, da dort der Agile GitOps-Ansatz seine volle Wirksamkeit entfaltet. Im Frontend werden sowohl Single Page-Applikationen als auch mobile Anwendungen unterstützt. Materna setzt bei der Standardisierung jedoch noch früher an, nämlich wenn die Tools für die Entwicklung gewählt werden. Hierzu zählen die Entwicklungsumgebung, das Build-Management-Tool, der DevOps-Toolstack und der Cloud-Provider.

Infrastructure as Code

In klassischen Vorgehensmodellen war die Entwicklung vom Betrieb klar getrennt. Mit dem Aufkommen von DevOps wachsen diese Bereiche stärker zusammen. In den Anfängen hat sich das darauf beschränkt, wie Anwendungen erstellt, getestet und deployed werden. Mit Infrastructure as Code (IaC), das heißt, der Möglichkeit, formal zu beschreiben, wie die Infrastruktur einer Anwendung aussehen soll und welche Bestandteile der Software wo laufen, wird das auf ein neues Level gebracht. Dadurch wird der Aufbau einer Infrastruktur weniger fehleranfällig, wiederholbar und ist selbstdokumentierend. Auch die Infrastruktur für die Entwicklung kann so automatisiert erstellt werden. Die Grenzen zwischen Laufzeit und Compile-Zeit (Fachbegriff für Erstellungszeit) beginnen zu verschwimmen. Es ist durchaus möglich, einen Teil der Infrastruktur direkt aus der Anwendung heraus zu erweitern. Das ermöglicht insbesondere, Multi-Mandantensysteme und Produktlinien elegant umzusetzen.

Cloud

Infrastructure as Code spielt seine Stärke erst in einer Public Cloud wie AWS richtig aus, weil hier Ressourcen dynamisch und in kürzester Zeit allokiert werden können. Im Zusammenspiel mit Serverless-Diensten, das heißt, Ressourcen, bei denen der Cloud-Provider die Verwaltung und Skalierung vollständig übernimmt, kann sich ein Entwicklungsteam auf die Umsetzung der Fachlichkeit konzentrieren. Auch fortgeschrittene Betriebsthemen wie Monitoring und Alarming, Backup-Strategien, Disaster Recovery, Canary Releases, Green-Blue Deployments und Edge Computing unterstützen und vereinfachen AWS.

Die Beteiligten in einem Entwicklungsprojekt übernehmen verschiedene Scrum-Rollen mit unterschiedlichen Ausrichtungen. Der Scrum Master (SM) möchte die Performance des Teams voll ausschöpfen. Der Product Owner (PO) achtet darauf, dass die Dinge richtig priorisiert werden. Das Entwicklungsteam arbeitet möglichst selbst organisierend und achtet auf die Qualität.

CI/CQ/CD

Ein zentraler Bestandteil von „Do Less“ ist die Continuous Integration (CI), bei der auf verschiedenen Stages, das heißt, Installationen der Software auf zugehörigen Umgebungen, automatisiert getestet wird. Jede Stage führt die Gesamtanwendung näher an die Produktion und es wird in den späteren Stages immer umfassender getestet. Dadurch wird das Zusammenspiel der verschiedenen Features, Services und schließlich der produktionsnahen Umgebung inkl. pseudonymisiertem Datenbestand geprüft. Die Erfahrung zeigt, dass auf all diesen Ebenen Fehler aufgedeckt werden können. Die Teststrecke in mehrere Stages aufzuteilen, ist aus mehreren Perspektiven sinnvoll. Beispielsweise sind frühzeitige Stages kleiner, schneller zu erstellen und die Tests schneller durchgeführt. Dadurch werden Probleme zeitnah und mit weniger Aufwand zurückgemeldet. Spätere Stages, die also versuchen, die Produktionsumgebung abzubilden, sind aufwendiger aufzusetzen und daher teurer. Weiterhin können Fehler auf frühzeitigen Stages einfacher lokalisiert werden, weil sie nicht in einer komplexen Infrastruktur untergehen. Es ist daher vorteilhaft, Fehler frühzeitig im Prozess zu erkennen, zu finden und zu beheben.

Während der Tests werden Daten gesammelt, die die Qualität und Aussagekraft der Tests widerspiegeln. In dem Zuge wird der Quellcode auch statisch analysiert. Die Ergebnisse werden zu einem Tool für die Umsetzung von Continuous Quality (CQ) weitergeleitet. Dort werden sie grafisch aufbereitet und können eingesehen werden. Ferner werden Quality Gates definiert, anhand derer automatisiert entschieden wird, ob die Anwendung den Qualitätsansprüchen der Stage genügt oder nicht.

Die letzte Stage ist das Produktivsystem. Wird der Agile GitOps-Ansatz konsequent umgesetzt, ist auch der Schritt in die Produktion automatisiert. Allerdings wird er zuvor von dem Produktverantwortlichen, dem sogenannten Product Owner (PO), geprüft und abgesegnet. Dieser Schritt führt zu dem eigentlichen Clou: nämlich, dass der Entwicklungs- und Freigabeprozess Tool-gestützt durch die Versionsverwaltung Git gesteuert wird.

Git und DevOps -> GitOps

Bei GitOps wird die Staging-Strategie auf das Branching-Modell (siehe Abbildung 3) abgebildet, wobei Branches in einer Versionsverwaltung die verschiedenen Entwicklungsstände einer Software widerspiegeln. Dadurch ist auf dem zugehörigen Branch der Stand, der erfolgreich die jeweilige Stage durchlaufen hat. Neue Funktionen werden unabhängig in Feature-Branches entwickelt. Eine Anfrage, dass Änderungen aus einem Branch in einen anderen übernommen werden, wird Merge Request genannt. Über Merge Requests wird angestoßen, dass die zugehörige Stage erzeugt wird. Hierfür wird automatisiert eine neue Umgebung aufgesetzt und die einzelnen Services werden erzeugt, als Container in eine zugehörige Registry geladen, in einem Container Service deployed und die zugehörigen Tests ausgeführt.

Nur wenn die Tests erfolgreich durchlaufen und die Quality Gates erfüllt sind, wird dem Verantwortlichen der Stage die Möglichkeit gegeben, den Merge Request zu bestätigen und durchzuführen. Spätestens für die Produktionsumgebung ist das der Product Owner. Hierdurch ist gewährleistet, dass die objektivierbaren Qualitätsansprüche, die bei Scrum in der Definition of Done (DoD) festgehalten werden, erfüllt sind und auch der oder die Verantwortliche mit dem Ergebnis zufrieden ist, bevor die Anwendung in die nächste Stage bzw. die Produktion gelangt. All diese Prozesse sind automatisiert und werden durch Git gesteuert. Die Entwickler nutzen Git auf der Konsole oder ihre Entwicklungsumgebung und der Product Owner kann die Web-Oberfläche eines DevOps-Tools wie z. B. GitLab verwenden.

Auf dem Weg von einer Anforderung bis hin zu einem Merge Request getriebenen Staging-Prozess entstehen keine Medienbrüche und keine fehleranfälligen manuellen Schritte. Wenn in dem Ablauf ein Test oder Quality Gate fehlschlägt, wird ebenfalls automatisch eine Benachrichtigung an den Entwickler, der die letzte Änderung gemacht hat, gesendet und der Übergang in den nächsten Prozessschritt wird automatisch abgebrochen. Das Problem kann zeitnah von der Person, die es verursacht hat, analysiert und behoben werden.

Bei GitOps wird die Staging-Strategie auf das Branching-Modell abgebildet. Branches spiegeln in einer Versionsverwaltung die verschiedenen Entwicklungsstände einer Software wider.

Fazit

Die Erfahrung zeigt, dass dieses Vorgehen schneller ist, zu besseren Ergebnissen führt und es ermöglicht, Anwendungen zu erstellen, die den heutigen Ansprüchen von Nutzern gerecht werden. Um Agile GitOps umsetzen zu können, muss ein Entwicklungsteam diszipliniert und professionell sein sowie ein umfassendes Spektrum an Werkzeugen beherrschen. Materna zeigt in vielen Projekten der vergangenen Jahre, dass dies Teil ihrer DNA geworden ist.

Mehr zu Software-Entwicklung von Materna

Über die Autoren