Das maßgeschneiderte DevOps Cockpit

Leicht verliert man den Überblick in den vielen „Web-Consolen“ des gesamten DevOps-Technologiestacks. Alles ist zwar irgendwie irgendwo vorhanden, aber vor der Erkenntnisgewinn stehen u. U. viele separate Logins und Filtereinstellungen.

Die CME Workbench

Um den Überblick in größeren Projekten für das gesamte Team herzustellen, haben wir die CME Workbench entwickelt. Ein Stück Technik, das (absichtlich) zu 30% fertig ist und dann vom Team selbst an die konkreten Bedürfnisse angepasst wird. Diese Anpassung findet in der UI und über Microservices statt.

Wir bei der Consort IT sehen jeden Microservice als Analogie zu einer Biene, welche ihre spezifische Aufgabe im Bienenstock (bzw. als Microservice im Cluster) erfüllt. Wie bereits während der Entwicklung sichergestellt werden soll, dass jede Biene ihre Tätigkeit anforderungsgemäß und nach festgelegten Qualitätsstandards erfüllt, wurde bereits im Artikel Quality-Gates für Microservices erläutert.  

Die dort definierten Qualitätsstandards greifen wir hier nun wieder auf, jedoch zoomen wir vom Fokus des einzelnen Entwicklers heraus auf die übergeordnete Ebene (z.B. des Product Owner oder des interessierten Stakeholders).

 Der Quality-View der CME Workbench

Oftmals stellt sich nämlich die Frage wie dieser Ebene ein umfassender Überblick über die Softwarequalität (über unsere Microservices hinweg) innerhalb eines fachlichen Projekts ermöglicht werden kann. Dabei soll nicht nur offensichtlich gemacht werden wie der allgemeine Qualitätszustand ist, sondern es soll auch ermittelbar sein in welcher Testphase und bei welchem Quality Gate der Schuh konkret drückt.  

Unsere Antwort hierauf ist das Quality Cockpit der CME2-Workbench: 

Das Quality Cockpit in der Grundversion gibt in den acht Kacheln die Quality Gates der verschiedenen Testphasen als Kurzzusammenfassung über unsere Microservices hinweg wieder. Aus der individuellen Gewichtung der einzelnen Gates resultiert der allgemeine Qualitätsindex als übergeordnete Kennzahl zur Einschätzung des derzeitigen Qualitätszustands. Dieser spiegelt wieder, inwiefern der bisher implementierte Softwarestand nach den Qualitätskriterien bereits auslieferbar ist.  

Die Grundversion enthält sinnvolle Tests bzw. Informationsquellen, die aus unserer Erfahrung in vielen erfolgreichen(!) Microservice-Projekten anzutreffen sind:

  • SonarQube Code-Quality
  • Cucumber Integration Testing
  • Consumer-Driven Contracts
  • Logfile Analyse aus dem zentralisierten Logging
  • Protractor End2End Testing
  • OWASP Komponenten-Inspektion (Security)
  • Build-Informationen (Jenkins)
  • Bugtracker-Infos (Jira)

Natürlich sind alle diese Informationen vorgefiltert für das aktuell ausgewählte fachliche Projekt.

In großen Projekten zählen auch ausgewählte Live-Metriken (z. B. Antwortzeiten von Benutzeroberflächen) zu den wichtigen Kacheln dieses Dashboards.

Der Quality-Adapter Microservice

Um die CME Workbench flexibel zu halten und zu demonstrieren wie Microservices Microservices benutzen, haben wir den Quality-Adapter eingeführt:

 

Die benötigten Informationen für die Kacheln des Cockpits fragt die Quality-View über den Quality-Adapter Microservice ab. Dieser holt sich die benötigen Metriken von diversen anderen Microservices im Cluster. In der Pre-Integration-Phase werden

  • die Informationen zu den fehlgeschlagenen Builds,
  • den Interfacetests via Pact sowie zu
  • den Tests der Programmbibliotheken mit Hilfe des Jenkins-Adapters

abgefragt. Die Informationen über die statische Codeanalyse erhält der Quality-Adapter über die Schnittstellen des SonarQube-Services. Code, der in der Pre-Integration-Phase scheitert, wird nicht auf das Integrationssystem geliefert.

In der Integration-Phase sind als zusätzliche Datenquellen z. B.

  • der Jira-Adapter (für das Aufzeigen der offenen Bugs) sowie
  • der Kubernetes-Adapter

angesiedelt. Unser Quality-Adapter fungiert somit als zentrale Anlaufstelle (Aggregator) für die UI zur Abfrage aller qualitätsrelevanten Daten über den Entwicklungszyklus hinweg.   

Alle arbeiten an der Qualität und deren Transparenz

Die Quality View ermöglicht es einem Projektleiter somit schnell herauszufinden was ein mögliches Release bisher verhindert. Weiterführenden Views zu den einzelnen Quality Gates ermöglichen zudem ein Aufschlüsseln auf die Microservices, welche als Urheber des Qualitätsproblems in Betracht kommen. Schließlich ist das alleinige Aufzeigen von Qualitätsproblemen in der Regel nicht ausreichend, sondern es soll auch ermittelbar sein, an welche Entwickler sich man bei der Lösung des Problems zu wenden hat. 

In obiger Abbildung sieht man die Ausgestaltung des Quality-View in einem konkreten Projekt: Die Vorschläge („Grundausstattung“) der CME Workbench wurden um die für das Team(!) wesentlichen Aspekte erweitert, um die maximale Transparenz zu bieten.

DevOps steigert das Selbstbewußtsein 

Zusammenfassend ist zu sagen, dass eine übergeordnete Qualitätsübersicht nicht nur qualitative Aussagen zum aktuellen Stand der Entwicklung zulässt, sondern durch die Transparenz auch eine qualitätsbewusstere Arbeitsweise fördert. 

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.