Wenn Ihr Unternehmen gerade DevOps oder CI/CD-Tools implementiert, kann es hilfreich sein, sich mit den häufigsten Fehlern vertraut zu machen, um sie zu vermeiden und nicht in die gleichen Fallen zu tappen.
Der Befehl übersetzte den Artikel .
Unvorbereitetheit auf kulturelle und prozessuale Veränderungen
Wenn man sich das zirkuläre Diagramm anschaut , erkennt man, dass das Testen in DevOps-Praktiken eine kontinuierliche Aufgabe ist, die eine fundamentale Rolle bei jedem einzelnen Deployment spielt.
Endloses zirkuläres DevOps-Diagramm
Tests und Qualitätssicherung im Entwicklungs- und Lieferprozess sind ein unverzichtbarer Teil dessen, was Entwickler tun. Es erfordert ein Umdenken, um Tests in jede Aufgabe zu integrieren.
Das Testen wird zu einem Bestandteil der täglichen Arbeit jedes Teammitglieds. Der Übergang zu konstantem Testen ist nicht einfach, man muss darauf vorbereitet sein.
Fehlendes Feedback
Die Effektivität von DevOps hängt von ständigem Feedback ab. Kontinuierliche Verbesserung ist nicht möglich, wenn es keinen Raum für Zusammenarbeit und Kommunikation gibt.
Unternehmen, die keine Retrospektiven durchführen, haben Schwierigkeiten, eine Kultur des kontinuierlichen Feedbacks im CI/CD zu etablieren. Retrospektiven finden am Ende jeder Iteration statt, bei denen die Gruppenmitglieder besprechen, was gut und was schlecht gelaufen ist. Retrospektiven sind das Fundament von Scrum/Agile, sind jedoch auch für DevOps unerlässlich.
Dies liegt daran, dass Retrospektiven die Gewohnheit fördern, Feedback und Meinungen auszutauschen. Einer der wichtigsten Punkte zu Beginn ist die Organisation regelmäßiger Retrospektiven, damit sie für das gesamte Team verständlich und vertraut werden.
Wenn es um die Qualität von Software geht, sind alle Teammitglieder für die Aufrechterhaltung verantwortlich. Beispielsweise können Entwickler modulare Tests schreiben und den Code so gestalten, dass er testbar ist, was hilft, Risiken von Anfang an zu minimieren.
Eine der einfachsten Möglichkeiten, die Sichtweise auf das Testen zu reflektieren, besteht darin, Tester nicht als QA, sondern als Softwaretester oder Qualitätstechniker zu bezeichnen. Diese Änderung mag zu simpel oder sogar töricht erscheinen. Doch die Bezeichnung „Qualitätssicherungs-Spezialist“ vermittelt ein falsches Bild davon, wer für die Qualität des Produkts verantwortlich ist. In den Praktiken von Agile, CI/CD und DevOps tragen alle die Verantwortung für die Softwarequalität.
Ein weiterer wichtiger Aspekt ist das Verständnis dafür, was Qualität für das gesamte Team und jedes einzelne Mitglied, die Organisation und die Stakeholder bedeutet.
Falsches Verständnis des Abschlusses einer Phase
Wenn Qualität ein kontinuierlicher und gemeinsamer Prozess ist, benötigt man ein gemeinsames Verständnis darüber, wann eine Phase abgeschlossen ist. Wie erkennt man, dass eine Phase beendet ist? Was passiert, wenn eine Phase auf einem Trello-Board oder einem anderen Kanban-Board als erledigt markiert wird?
Die Definition der fertiggestellten Phase (DoD) ist ein kraftvolles Werkzeug im Kontext von CI/CD und DevOps. Sie hilft, die Qualitätsstandards besser zu verstehen, die das Team für das, was und wie es erstellt, anwendet.
Das Entwicklerteam muss klären, was "Fertig" bedeutet. Sie müssen sich zusammensetzen und eine Liste von Kriterien erstellen, die zu jedem Schritt erfüllt werden müssen, damit das Projekt als abgeschlossen betrachtet werden kann.
Die Definition of Done (DoD) macht den Prozess transparenter und erleichtert die Umsetzung von CI/CD, wenn sie für alle Teammitglieder klar und mutual abgestimmt ist.
Fehlende realistische, klar definierte Ziele
Dies ist einer der häufigsten Ratschläge, aber er ist es wert, wiederholt zu werden. Für den Erfolg jeder ernsthaften Initiative, einschließlich der Implementierung von CI/CD oder DevOps, müssen realistische Ziele gesetzt und die Leistung im Vergleich dazu gemessen werden. Was möchten Sie mit CI/CD erreichen? Ermöglicht es schnellere Releases mit besserer Qualität?
Alle gesetzten Ziele sollten nicht nur transparent und realistisch sein, sondern auch zu den aktuellen Aktivitäten des Unternehmens passen. Zum Beispiel, wie oft benötigen Ihre Kunden neue Korrekturen oder Versionen? Es ist nicht notwendig, die Prozesse zu überladen und schneller zu releasen, wenn dies für die Nutzer keine zusätzlichen Vorteile bringt.
Zudem müssen Sie nicht immer sowohl CD als auch CI implementieren. Unternehmen mit hohen Regulierungsanforderungen, wie Banken und medizinische Kliniken, können ausschließlich mit CI arbeiten.
CI ist ein guter Ausgangspunkt für jedes Unternehmen, das DevOps einführt. Bei der Implementierung ändern sich in Unternehmen die Ansätze zur Softwarebereitstellung erheblich. Sobald CI beherrscht wird, kann über eine Verbesserung des gesamten Prozesses, eine Erhöhung der Bereitstellungsgeschwindigkeit und andere Änderungen nachgedacht werden.
Für viele Organisationen reicht ein einziges CI aus, und CD sollte nur implementiert werden, wenn es einen zusätzlichen Nutzen bringt.
Fehlende geeignete Dashboards und Kennzahlen
Sobald Sie Ihre Ziele festgelegt haben, kann das Entwicklungsteam ein Dashboard zur Messung der KPIs erstellen. Vor der Entwicklung dieser sollten die Parameter bewertet werden, die überwacht werden sollen.
Verschiedene Berichte und Anwendungen sind für unterschiedliche Teammitglieder nützlich. Scrum Master interessieren sich hauptsächlich für den Status und die Abdeckung, während das obere Management an der Burnout-Rate der Mitarbeiter interessiert sein könnte.
Einige Teams verwenden auch Dashboards mit roten, gelben und grünen Indikatoren zur Bewertung des CI/CD-Status, um zu verstehen, ob sie alles richtig machen oder ob ein Fehler aufgetreten ist. Rot bedeutet, dass man auf das Geschehen achten sollte.
Wenn die Informationspanels jedoch nicht standardisiert sind, können sie irreführend sein. Analysieren Sie, welche Daten für alle erforderlich sind, und erstellen Sie dann eine standardisierte Beschreibung dessen, was sie bedeuten. Finden Sie heraus, was für die Stakeholder mehr Sinn macht: Grafiken, Text oder Zahlen.
Fehlende manuelle Tests
Die Automatisierung von Tests legt die Grundlage für einen guten CI/CD-Pipeline. Aber automatisierte Tests in allen Phasen bedeuten nicht, dass man keine manuellen Tests durchführen sollte.
Um eine effektive CI/CD-Pipeline aufzubauen, sind auch manuelle Tests erforderlich. Es wird immer einige Aspekte des Testens geben, die eine menschliche Analyse erfordern.
Es lohnt sich, an eine Integration der manuellen Testanstrengungen in die Pipeline zu denken. Nachdem die manuellen Tests einiger Testfälle abgeschlossen sind, können Sie zur Bereitstellungsphase übergehen.
Versuchen Sie nicht, die Tests zu verbessern
Ein effektiver CI/CD-Prozess erfordert Zugriff auf die richtigen Tools, sei es Testmanagement oder Integration und kontinuierliches Monitoring.
Der Aufbau einer starken, qualitätsorientierten Kultur zielt darauf ab, , die Interaktion mit Kunden nach der Bereitstellung zu überwachen und Verbesserungen nachzuvollziehen.
Hier sind einige praktische Tipps, die Sie leicht umsetzen können:
- Stellen Sie sicher, dass die Tests einfach zu schreiben und flexibel genug sind, um bei Code-Refactoring nicht zu brechen.
- Entwicklungsteams sollten in den Testprozess eingebunden werden — sie sollten die Liste der Benutzerprobleme und Anforderungen sehen, die während der CI-Pipelines wichtig zu überprüfen sind.
- Vielleicht haben Sie nicht vollständige Testabdeckung, achten Sie jedoch stets darauf, dass die für UX und Kundeninteraktion wichtigen Ströme getestet sind.
Letzter, aber nicht weniger wichtiger Punkt
Der Übergang zu CI/CD wird in der Regel von unten nach oben initiiert, ist jedoch letztendlich eine Transformation, die das Engagement der Führungsebene sowie Zeit- und Ressourcenaufwand seitens des Unternehmens erfordert. CI/CD umfasst eine Kombination aus Fähigkeiten, Prozessen, Werkzeugen und einer kulturellen Umstellung, die nur systematisch umgesetzt werden kann.
Weitere Lesetipps zu diesem Thema:
- .
- .
- .
Quelle: habr.com
