DevOps und APIOps in der Praxis: Erfolgsfaktoren und Best Practices

Im letzten Teil unserer Serie beleuchten wir die praktische Anwendung von DevOps und APIOps. Gerade für Teams, die an modernen, verteilten Systemen arbeiten und DevOps-Methoden optimal umsetzen wollen, ist die Integration von APIOps ein entscheidender Faktor. Dieser Artikel zeigt anhand eines realen Projekts, wie beide Ansätze erfolgreich in der Praxis umgesetzt werden können.

Zielsetzung

Ein Versicherungsunternehmen beschäftigt mehrere Teams, die an separaten Software-Produkten arbeiten. Diese Teams agieren unabhängig voneinander und folgen eigenen Release-Zyklen. Das Ziel des Unternehmens ist es, echte DevOps-Prozesse einzuführen. Da die verschiedenen Software-Produkte über APIs kommunizieren, sollen die DevOps-Prozesse auch die API-Landschaft abdecken und APIOps eingeführt werden.
Die Ziele sind dabei:

•   Unabhängige und eigenverantwortliche Nutzung durch die Teams
•   Übergreifende Einführung von Automatisierung
•   Qualitätskontrollen nach zentralen Vorgaben
•   Einheitliche Prozesse zur Verwaltung des API-Lebenszyklus

Aufbau

Für die Umsetzung entscheiden wir uns für GitHub Actions. Mit diesem Werkzeug können wir sehr einfach vordefinierte Bausteine mit eigenen Aktionen ergänzen. Dadurch erhalten wir einfache Wiederverwendbarkeit von häufig eingesetzten Aktionen und zugleich die Freiheit, komplexere Abläufe selbst zu steuern. Gleichzeitig bietet uns GitHub-Actions eine einfache Art, CI/CD direkt mit unserer Codeverwaltung zu integrieren. Wir ergänzen die vordefinierten Actions mit Custom-Actions, also selbst definierten Aktionen. Diese Aktionen können durch die einzelnen Teams in ihre eigene Pipeline in den Workflow integrieren werden.

Abbildung 1: Exemplarischer Lauf der Pipeline

Erste Schritte: OpenAPI-Scans und Tests

Die erste Action scannt alle OpenAPI-Dateien im Projektordner und prüft sie mit einem Linter als statischem Analysetool zunächst auf syntaktische Korrektheit sowie auf die Einhaltung der unternehmenseigenen REST-Guideline. Am Ende werden Warnungen und Verstöße gegen verpflichtende Regeln in einer Zusammenfassung des Pipeline-Laufs tabellarisch dargestellt. Darüber hinaus werden alle OpenAPI-Spezifikationen auf Änderungen überprüft, und mittels eines Diff-Tools wird die Rückwärtskompatibilität dieser Änderungen geprüft. Diff-Tools vergleichen zwei Versionen einer API und prüfen auf Änderungen, die potenziell bestehende Clients beeinträchtigen könnten. So wird sichergestellt, dass Änderungen rückwärtskompatibel sind und keine unerwarteten Fehler in den abhängigen Systemen auftreten. So wird der Entwickler direkt nach dem Commit darauf hingewiesen, ob die vorgenommenen Änderungen an der OpenAPI für bestehende Clients problematisch sind und welche Änderungen das konkret betrifft. Optional kann dieses Vorgehen durch die Einbindung von Consumer Driven Contract Tests mit Pact ergänzt werden. Diese Tests ermöglichen es, den Servicevertrag zwischen verschiedenen Services zu testen. Dies stellt sicher, dass Änderungen in der API keinen unerwarteten Bruch bei den Consumer-Diensten verursachen.

Erspüren von Anpassungsbedarfen

Diese Systematik der Team-Topologien und ihrer Kommunikationsmodi ermöglicht eine gezielte Strukturierung der Inter-Team-Kommunikation im Hinblick auf das Gesetz von Conway zur Erreichung der gewünschten Systemarchitektur, die Angleichung der tatsächlichen kognitiven Last auf die Teamkapazität und den gleichermaßen effizienten wie effektiven Einsatz von Kommunikationsaufwänden. Das Definieren der Kommunikationsstruktur einer Organisation ist jedoch keine einmalige Aufgabe. Ändern sich Voraussetzungen, die einer gewählten Struktur zugrunde liegen, so muss auch die Struktur dem geänderten Bedarf angepasst werden - entweder temporär oder dauerhaft. Daher muss eine Organisation solche Anpassungsbedarfe aktiv erspüren und systematisch darauf reagieren.

Ein exemplarischer Lauf der Pipeline mit der beschriebenen GitHub Action:

Im Beispiel sehen wir, dass beim letzten Commit zwei Dateien geändert wurden: cats.yml und dogs.yml. Daraufhin wird die GitHub Action (on-push Trigger) ausgeführt und ermittelt, welche OpenAPI-Dateien geändert wurden. Für jede der OpenAPI-Dateien läuft nun ein weiterer Schritt, in dem die Überprüfungen durch Linter und Diff durchgeführt werden: Dieser Schritt stellt fest, dass die Datei dogs.yml derart geändert wurde, dass Consumer betroffen sind. Deshalb schlägt der Build fehl, da eine der geänderten Dateien die automatische Prüfung nicht bestanden hat.
Das Ergebnis eines erfolgreichen Pipeline-Laufs wäre, dass die API veröffentlicht wird und für die Consumer bereitsteht. Da jedoch noch eine Abhängigkeit zur Version der Software besteht, wird die veröffentlichte API noch nicht unter dem öffentlichen DNS-Namen der Software bereitgestellt, sondern nur für den internen Gebrauch freigegeben. Die Umschaltung des DNS-Eintrags auf die neue Version erfolgt erst, wenn Software und API aktualisiert wurden.

Nächste Schritte: Bau und Release der Anwendung

Weitere Actions kümmern sich um den Bau, die Analyse und das Testen der Anwendung. Mithilfe von SonarQube führen wir statische Code-Analysen durch, um die grundlegende Qualität sicherzustellen. Anschließend werden automatisierte Tests durchgeführt. Sind alle Qualitätschecks erfolgreich, wird die Anwendung auf die Zielumgebung deployed, und die API in der neuen Version wird aktiviert.

Ausblick

In modernen, containerisierten Umgebungen, die oft auf Kubernetes basieren, spielen Pipelines eine entscheidende Rolle bei der Orchestrierung der Deployments. Infrastructure as Code (IaC), z. B. mit Terraform oder Ansible, ermöglicht dabei eine automatisierte Bereitstellung und Verwaltung der Infrastruktur, wodurch DevOps- und APIOps-Prozesse weiter skalierbar und wiederholbar werden. Die enge Verzahnung dieser Technologien erleichtert es Teams, kontinuierlich neue Versionen sowohl von Anwendungen als auch von APIs zu entwickeln, zu testen und auszurollen, während gleichzeitig die Infrastruktur konsistent bleibt.

Auswirkungen auf die Teams

Die Bereitstellung der Pipeline-Bausteine und deren Wartung erfolgt durch ein Platform-Team, das als Dienstleister für die Stream-Aligned-Produktteams fungiert. Auch der Betrieb der ausführenden Pipeline-Infrastruktur mit GitHub wird vom Platform-Team übernommen. Um den Produktteams die Erstellung und Nutzung der Tools zu erleichtern, wird ein Enabling-Team geschaffen, das Coaching und Onboarding anbietet. Da die Produktteams jedoch unabhängig voneinander ihre Pipelines aufbauen und verwalten können, erreichen wir eine hohe Skalierbarkeit der Arbeitsaufwände und können die Kommunikation zwischen den beteiligten Teams gut steuern. So wird die kognitive Last der Beteiligten nicht überstrapaziert.
Eine Gefahr besteht darin, dass die Stream-Aligned-Teams im Laufe der Zeit unbeabsichtigte Nutzungsmöglichkeiten der Pipelines entwickeln oder sogar parallele Lösungen entstehen. Um dem entgegenzuwirken, werden die Projekte regelmäßig vom Enabling-Team geprüft. Falls eine Verwilderung der DevOps-Tools festgestellt wird, kann das Enabling-Team korrigierend eingreifen und die Teams zur korrekten Nutzung zurückführen.

Fazit

Das Thema DevOps und CI/CD ist nicht neu. Seit etlichen Jahren beschäftigt sich die Industrie mit diesen Praktiken, und es werden ständig neue Trends gesetzt. Dennoch stellen wir oft fest, dass der tatsächliche Einsatz dieser Praktiken auf Herausforderungen stößt. Besonders schlechte Kommunikation oder unklare Verantwortungsbereiche führen schnell zu Hindernissen. Dadurch steigt der Aufwand, der in die Anwendung von DevOps investiert werden muss, und die beteiligten Mitarbeiter entwickeln Frustration. Wir haben aufgezeigt, was aus unserer Sicht getan werden kann, um in diesem Umfeld gute Voraussetzungen für effiziente Kommunikation zu schaffen. Mit den vorgeschlagenen Teamschnitten können Fähigkeiten