Habt ihr in eurem Team oder an anderer Stelle in eurer Organisation eine der folgenden Aussagen gehört?
Joonas Jauhiainen
DevOps Lead
Joonas is a DevOps lead with experience in telecom, banking, insurance, and manufacturing, among other industries. His hobbies include investigation of IT devices, developing games and other SW projects not to mention underwater rugby!
„Die Feedbackschleife ist zu lang.“
„Ich bin mir nicht sicher, welche Tests wir durchführen.“
„Ich weiß nicht, wo unsere Testergebnisse sind.“
„Ich verstehe unsere Testergebnisse nicht.“
Solche Fragen bedeuten in der Regel, dass ihr CI/CD-Arbeitsweisen in der Entwicklung erfolgreich eingeführt habt und die Automatisierung euch Zeit für weitere Verbesserungen verschafft. Doch wie beantwortet ihr diese Fragen, bevor sie zu echten Problemen werden und die Leute das Interesse verlieren?
Zum Glück liegt die Antwort in eurer Hand! Ihr müsst relevante Metriken definieren und sie für die gesamte Organisation sichtbar machen – insbesondere für euer Team.
Welche Metriken brauche ich?
Diese Frage bekommen wir oft. Leider lautet die berüchtigte Antwort: „Es kommt darauf an.“ Etwas zu zeigen ist besser als nichts – fangt also einfach irgendwo an.
Sobald eure Organisation Daten erfassen, speichern und präsentieren kann, erkennt ihr in der Regel, welche Metriken benötigt werden. „Nun, das ist nicht gerade hilfreich“, denkt ihr vielleicht. Deshalb möchten wir euch einen interessanten Artikel vorstellen, auf den wir gestoßen sind. Darin stellen die Autoren die folgenden Metriken vor:
Nutzerzufriedenheit
In der Produktion gefundene Fehler
Testabdeckung
Fehler über mehrere Sprints hinweg
Zugesagte vs. gelieferte Stories
Dabei ist uns eine gewisse Überschneidung mit den DORA-Metriken aufgefallen.
Deployment-Häufigkeit
Diese sollte mit einer hohen „(1) Nutzerzufriedenheit“ korrelieren. Tatsächlich ist sie eine Voraussetzung dafür, diese überhaupt beobachten zu können.
Durchlaufzeit für Änderungen
Sie zeigt euch, wie schnell ihr von einer Idee bis in die Produktion gelangt. Das entspricht „(5) Zugesagte vs. gelieferte Stories“.
Fehlerquote bei Änderungen
Sie zeigt euch, wie viele Fehler ihr gefunden habt und wie lange deren Behebung gedauert hat. Anders gesagt: „(3) Testabdeckung“ hilft euch zusätzlich dabei, die Ursache eurer Fehlerquote bei Änderungen zu analysieren.
„(4) Fehler über mehrere Sprints hinweg“ ist ein detaillierteres Beispiel für die allgemeine Fehlerquote.
Zeit bis zur Wiederherstellung von Services
Sie zeigt euch, wie schnell ihr Vorfälle in der Produktion beheben könnt. Das ist die nächste Frage, nachdem ihr „(2) In der Produktion gefundene Fehler“ ermittelt habt.
Angesichts der Überschneidungen und der Tatsache, dass sich DORA-Metriken bewährt haben, halten wir sie für einen guten Ausgangspunkt.
Wo anfangen?
Nachdem wir mehrere sinnvolle Metriken definiert haben: Wie können wir sie erfassen?
Bei Eficode setzen wir auf Automatisierung und darauf, dass die Daten in Reports und Dashboards möglichst in Echtzeit verfügbar sind. Deshalb haben wir vor einigen Jahren einige Open-Source-Projekte gestartet, die solche Initiativen unterstützen:
In unseren Kundenprojekten war Jenkins CI die meistgenutzte CI/CD-Lösung. Bei der Erfassung von Metriken mit der Open-Source-Zeitreihendatenbank InfluxDB in Kombination mit dem ebenfalls quelloffenen Dashboard-Tool Grafana haben wir bereits einen erfolgreichen Proof of Concept umgesetzt.
Die Nutzung von Open-Source-Lösungen erfordert möglicherweise etwas mehr Eigenaufwand, ist aber die günstigste Option, da sie vollständig kostenlos sind. So könnt ihr schneller loslegen – denn ihr möchtet Daten sehen, um eure Metriken weiterzuentwickeln.
Beispiel für ein Setup:
Wie geht es weiter, sobald wir Daten haben?
Nachdem wir die Infrastruktur für die Erfassung und Visualisierung von Daten eingerichtet haben, erstellen wir normalerweise einige Diagramme, um häufig gestellte Fragen zu beantworten. Zum Beispiel: „Wie hoch ist die Bestehensquote der Tests, die in der Continuous Integration laufen (also die zuvor erwähnte Änderungsfehlerrate oder die Anzahl der Fehler im Sprint)?“
Die Daten stammen direkt aus eurem CI/CD-Tool und sind daher so aktuell wie möglich. Wenn die Daten für alle sichtbar sind, kann euer Team die aktuelle Situation besser nachvollziehen.
Im nächsten Schritt solltet ihr gemeinsam mit euren Stakeholdern über das Produkt nachdenken, das ihr mit eurem Team entwickelt. Nicht alle Daten sind für jeden gleich wichtig. Manager möchten beispielsweise die gesamte Bestehensquote eines Monats sehen, während Entwickler die neuesten Ergebnisse benötigen und wissen wollen, ob die Umgebung die Smoke Tests besteht.
Glücklicherweise unterstützen Grafana und andere Lösungen mehrere Dashboards. So lassen sich separate Metriken für Management, Teamleiter, QA-Teams und weitere Zielgruppen einfach visualisieren.
Wir empfehlen, jedem Stakeholder die wichtigsten Daten bereitzustellen und gleichzeitig bei Bedarf Zugriff auf alle Daten zu ermöglichen.
Wir erleben oft, dass mit der Anzeige aktueller Daten weitere Ideen dazu entstehen, was als Nächstes angegangen werden sollte. Meistens beginnen Teams dadurch, Entscheidungen auf Basis von Fakten zu treffen, statt Gründe aus der Luft zu greifen.
Warum erweitert ihr nicht euer Wissen und erfahrt mehr darüber, wie ihr Qualität in eure Software integriert?
- DevOps
- Efilife
- CI/CD
Subscribe to our newsletter
Related blogs
