Datenbasierte DevOps Orchestrierung
Problem
Aufwand und Kosten für DevOps sind hoch. Time-to-market für neue Releases ist trotzdem zu lang, Optimierung scheint nur mit deutlichem Mehraufwand möglich. Überblick über den gesamten SDLC fehlt: was von der Planung in welcher Form in einer Release landet und warum, ist nur schwer nachzuvollziehen.
Lösung
Datenbasierte end-to-end Orchestrierung des SDLC schafft Überblick. Funktionell mit Daten verbundene Automatisierung schafft zwingend korrekte und aktuelle Sicht auf den gesamten SDLC. Optimierungspotential wird sichtbar und dank flexibler, Python-basierter Automatisierung mit geringem Aufwand umsetzbar. Zusammenarbeit zwischen Teams steigt, time-to-market wird kürzer.
Das Problem
- Kosten für DevOps sind hoch: Es wird viel Zeit in die Wartung von CI/CD Pipelines und DevOps Tools investiert.
- Mehrwert von Automatisierung wird nicht voll realisiert: time-to-market für neue Features ist weiterhin hoch und die Release Frequenz niedrig. Automatisierung ist nicht end-to-end: vieles wird weiterhin manuell durchgeführt.
- Informationsfluss zwischen Teams ist niedrig, Abhängigkeiten zwischen Teams führen zu Konflikten und Fehlern.
- End-to-end Sicht auf den gesamten Software-Development-Lifecycle (SDLC) von Planung bis Deployment fehlt. Beispiel: Status von Build und Tests sind im CI/CD Tool sichtbar, Deployments jedoch nicht. Oder: Release-Planung findet im Ticketing-System statt. Da keine Verbindung vom Ticket zur weiteren Pipeline besteht ist nicht eindeutig nachvollziehbar, welche Tickets / Features in genau welcher Form in einer Release enthalten sind.
Die Lösung
- Datenbasierte Analyse des DevOps Prozesses zeigt Flaschenhälse, Lücken und Abhängigkeiten
- Daten werden aus bestehenden Systemen ausgelesen. Automatisierung verbleibt in bestehenden Systemen (wo vorhanden) und wird von der darüberliegenden Datenbasis orchestriert. Mehrwert bestehender Pipelines und Tools wird weiter genutzt, während Lücken durch flexible, Python-basierte Automatisierung geschlossen werden können
- Bereitstellung von Informationen über den gesamten SDLC erhöht Informationsfluss zwischen den Teams, erleichtert Zusammenarbeit und die Handhabung von Abhängigkeiten und schafft einen Überblick über den Gesamtprozess.
- Funktionell mit den Daten verbundene Automatisierungen ermächtigen Entwickler:innen, DevOps Expert:innen und andere Stakeholder, indem sie direkt Werkzeuge darstellen, mit denen die eigene Arbeit schneller und leichter wird
So funktioniert es
Flexibles Datenmodell für SDLC: Schneller Start mit einem best-practice Basismodell, um den Software Development Lifecycle abzubilden. Das Datenmodell ist flexibel und voll auf Ihre Bedürfnisse anpassbar. Durch schrittweise Erweiterung und Anpassung des Datenmodells werden mit der Zeit immer detailliertere Einblicke in Ihren SDLC möglich.
Wo leben die Daten?
- Daten werden in einem Master Data Management (MDM) System oder eine relationalen Datenbank (z.B. PostgreSQL) abgelegt.
- Wenn Sie bereits ein MDM oder vergleichbares System verwenden, kann dieses angebunden werden.
- Alternativ stellen wir als Teil der Cloudomation Engine-Plattform ein MDM oder eine DB für die Datenhaltung zur Verfügung.
Wie sieht das Datenmodell aus?
- Um einen schnellen Start zu ermöglichen bieten wir ein generisches, leichtgewichtiges best-practice Modell an, das kompatibel mit allen gängigen Software-Entwicklungsmethoden ist.
- Das Datenmodell beschreibt, welche Entitäten für Ihre Software-Entwicklung wichtig sind, und wie diese zueinander stehen. Es bildet eine Ontologie für Ihren SDLC.
- Beispiel: die Entität „commit“ wird im Datenmodell mit einer ID und den Eigenschaften push_id, commit_sha, author_name, author_email, message und timestamp abgebildet. Weitere Felder sowie weitere Entitäten können einfach hinzugefügt werden – z.B. um zusätzliche Informationen zum author eines commits zu hinterlegen.
- Ziel des Datenmodells ist es, Ihnen einen schnellen Start und schrittweise Optimierung zu ermöglichen. Fokus liegt dabei auf dem richtigen Maß an best-practice Rahmen, den wir Ihnen empfehlen und maximaler Flexibilität, um das Datenmodell auf genau Ihre Befürdnisse und Datenlage anzupassen.
Anbindung bestehender Tools: Abbildung des SDLC ist keine „trockene Dokumentationsarbeit“ sondern findet statt, indem bestehende Tools live an das Datenmodell angebunden werden. Daten werden kontinuierlich aus bestehenden Systemen ausgelesen bzw. entgegengenommen (z.B. über Webhooks). Links zu Detailinformationen in Quellsystemen schaffen einen zentralen Überblick mit der Möglichkeit, jederzeit zu jedem Punkt weiterführende Informationen abzurufen.
Welche Tools können angebunden werden?
- Sie können beliebige Tools wie z.B. Ansible, Jenkins, Terraform, alle gängigen Cloud Services, Ticketing Systeme etc. anbinden. Solange ein Tool irgendeine Form von externem Zugriff erlaubt kann es über Cloudomation Engine angesprochen und orchestriert werden.
- Sie können auch Skripte in beliebigen Programmiersprachen über Cloudomation Engine auslösen und deren Ausführung überwachen. Wenn sie z.B. bestehende Skripte in bash oder powershell (oder jeder sonstigen Sprache) in Ihren DevOps Prozessen verwenden können Sie diese weiter nutzen und über Cloudomation Engine zentral verwalten, loggen und orchestrieren.
- Auch umgekehrt ist es möglich, dass andere Tools Cloudomation Engine aufrufen. So kann z.B. eine Pipeline, die bereits in Jenkins definiert ist, an einem bestimmten Punkt von Jenkins an Cloudomation Engine übergeben werden, oder Cloudomation Engine „nur“ mit Daten über die Pipeline gefüttert werden, während die Automatisierungen in Jenkins verbleiben.
- Ziel ist, Ihnen maximale Flexibilität zu geben, um schrittweisen Einstieg und kontinuierliche Optimierung zu ermöglichen. Nutzen Sie weiter, was bereits funktioniert und investieren Sie nur dort Ihre Zeit, wo es Probleme gibt.
Wie werden Tools angebunden?
- Eine Vielzahl an Konnektoren erlauben Anbindung von Tools über Standard-Schnittstellen und Protokolle, wie z.B. REST APIs, ssh, oder DB Anbindungen. So kann Cloudomation Engine aktiv auf Drittsysteme zugreifen und Daten auslesen.
- Der API Manager erlaubt, Daten und Benachrichtigungen von Drittsystemen entgegen zu nehmen. Webhooks, die in Cloudomation Engine mit einem Klick erstellt werden, können in Drittsystemen eingetragen werden und z.B. bei einem git commit Cloudomation Engine benachrichtigen. Die Definition voller benutzerdefinierter REST APIs erlaubt komplexere Integrationen, bei denen Cloudomation Engine-Daten in beliebigem Format von Drittsystemen empfängt.
- Mit Workspace Linking können mehrere Cloudomationn Engine-„Satelliten“ in unterschiedlichen Netzwerksegmenten miteinander verbunden werden, um so einfache und sichere Anbindung von Tools zu ermöglichen – z.B. Verbindung von SaaS und on-premise Lösungen.
Daten als Trigger für Automatisierungen: durch Anbindung von Automatisierungen im Datenmodell werden die Daten „funktionell lebendig“. Das Eintragen einer neuen Version für ein Deployment löst z.B. das Deployment der neuen Version aus. Der Status von Tests kann nicht nur ausgelesen, sondern die Tests auch erneut durchgeführt werden. Dabei verbleiben bestehende Automatisierungen in bereits vorhandenen Systemen.
Schrittweiser Ausbau und Schließung von Lücken: Durch die Möglichkeit, leichtgewichtige, Python-basierte Automatisierungen hinzuzufügen, welche Lücken in den Pipelines schließen oder neue Capabilities hinzufügen wird die Optimierung von DevOps Prozessen schrittweise und kontinuierlich möglich. Durch die flexiblen Orchestrierungsmöglichkeiten können auch bestehende Automatisierungen in anderen Tools erweitert werden und z.B. komplexe Abhängigkeitsgeflechte berücksichtigt werden, indem Automatisierungen in Drittsystemen erst aufgerufen werden, wenn alle im Datenmodell hinterlegten Abhängigkeiten erfüllt sind.
Das Ergebnis
Aufwand für DevOps sinkt:
- Durch automatisierte Datensammlung wird Zeit für Fehlersuche drastisch reduziert.
- End-to-end Überblick erleichtert Wartung deutlich.
Optimierung wird möglich, time-to-market sinkt:
- Da Lücken und Flaschenhälse sichtbar werden, wird klar, wo Verbesserung ansetzen muss.
- Optimierung kann schrittweise stattfinden, mit aktuell zur Verfügung stehenden Ressourcen.
Zusammenarbeit zwischen Teams verbessert sich:
- Informationen stehen allen zur Verfügung.
- Abhängigkeiten werden sichtbar.
- Teams können unabhängiger agieren, da sie selbst die Pipeline Tools bedienen können.