Wenn Ihr Unternehmen gerade dabei ist, DevOps- oder CI/CD-Tools zu implementieren, kann es hilfreich sein, sich mit den häufigsten Fehlern vertraut zu machen, damit Sie diese nicht wiederholen und anderen auf die Füße treten.
Team habe den Artikel übersetzt .
Unwilligkeit, Kultur und Prozesse zu ändern
Schauen Sie sich das Zyklusdiagramm an Es ist klar, dass das Testen in DevOps-Praktiken eine kontinuierliche Arbeit ist, ein grundlegender Bestandteil jeder einzelnen Bereitstellung.
DevOps-Endloszyklusdiagramm
Tests und Qualitätssicherung während der Entwicklung und Bereitstellung sind ein wesentlicher Bestandteil aller Aktivitäten von Entwicklern. Dies erfordert eine Änderung der Denkweise, um Tests in jede Aufgabe einzubeziehen.
Das Testen wird Teil der täglichen Arbeit jedes Teammitglieds. Der Übergang zum kontinuierlichen Testen ist nicht einfach, darauf müssen Sie vorbereitet sein.
Fehlendes Feedback
Die Wirksamkeit 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 Meetings organisieren, haben es schwer, eine Kultur des kontinuierlichen Feedbacks in CI/CD zu implementieren. Am Ende jeder Iteration finden Retrospektivbesprechungen statt, bei denen die Gruppenmitglieder besprechen, was gut und was schief gelaufen ist. Retrospektive Meetings sind die Grundlage von Scrum/Agile, aber auch für DevOps unerlässlich.
Dies liegt daran, dass retrospektive Treffen die Gewohnheit vermitteln, Feedback und Meinungen auszutauschen. Einer der wichtigsten Momente zu Beginn ist die Organisation wiederkehrender Retro-Meetings, damit diese für das gesamte Team verständlich und vertraut werden.
Wenn es um die Softwarequalität geht, sind alle Teammitglieder für deren Aufrechterhaltung verantwortlich. Entwickler können beispielsweise Unit-Tests und Code unter Berücksichtigung der Testbarkeit schreiben und so dazu beitragen, Risiken von Anfang an zu mindern.
Eine einfache Möglichkeit, die sich ändernde Wahrnehmung des Testens widerzuspiegeln, besteht darin, Tester nicht als Qualitätssicherung, sondern als Softwaretester oder Qualitätsingenieur zu bezeichnen. Diese Änderung mag zu einfach oder sogar dumm erscheinen. Aber jemanden als „Software-Qualitätssicherungsspezialist“ zu bezeichnen, vermittelt eine falsche Vorstellung davon, wer für die Produktqualität verantwortlich ist. In Agile-, CI/CD- und DevOps-Praktiken ist jeder für die Softwarequalität verantwortlich.
Ein weiterer wichtiger Punkt ist das Verständnis, was Qualität für das gesamte Team und jedes seiner Mitglieder, die Organisation und die Stakeholder bedeutet.
Missverständnis des Etappenabschlusses
Wenn Qualität ein kontinuierlicher und gemeinsamer Prozess ist, ist ein gemeinsames Verständnis für den Abschluss einer Phase erforderlich. Wie kann man verstehen, dass die Bühne vorbei ist? Was passiert, wenn ein Meilenstein auf einem Trello-Board oder einem anderen Kanban-Board als abgeschlossen markiert wird?
Die Bestimmung eines abgeschlossenen Meilensteins (DoD) ist ein leistungsstarkes Werkzeug im Kontext von CD DevOps/CI. Es hilft, die Qualitätsstandards dessen, was und wie das Team aufbaut, besser zu verstehen.
Das Entwicklungsteam muss entscheiden, was „Fertig“ bedeutet. Sie müssen sich hinsetzen und eine Liste der Merkmale erstellen, die in jeder Phase erfüllt sein müssen, damit sie als vollständig angesehen werden kann.
Das DoD macht den Prozess transparenter und erleichtert die Implementierung von CI/CD, wenn es allen Teammitgliedern klar ist und einvernehmlich vereinbart wird.
Mangel an realistischen, klar definierten Zielen
Dies ist einer der am häufigsten zitierten Tipps, aber es lohnt sich, ihn zu wiederholen. Damit jedes ernsthafte Vorhaben erfolgreich sein kann, einschließlich der Implementierung von CI/CD oder DevOps, müssen Sie sich realistische Ziele setzen und die Leistung daran messen. Was möchten Sie mit CI/CD erreichen? Ermöglicht es schnellere Veröffentlichungen mit besserer Qualität?
Die gesetzten Ziele sollten nicht nur transparent und realistisch sein, sondern auch mit den aktuellen Aktivitäten des Unternehmens übereinstimmen. Wie oft benötigen Ihre Kunden beispielsweise neue Patches oder Versionen? Es besteht keine Notwendigkeit, Prozesse zu überlasten und schneller freizugeben, wenn kein zusätzlicher Nutzen für die Benutzer entsteht.
Außerdem müssen Sie nicht immer sowohl CD als auch CI implementieren. Beispielsweise dürfen stark regulierte Unternehmen wie Banken und Kliniken nur mit CI arbeiten.
CI ist ein guter Ausgangspunkt für jedes Unternehmen, das DevOps implementiert. Wenn es in einem Unternehmen implementiert wird, ändern sich die Ansätze zur Softwarebereitstellung erheblich. Sobald CI beherrscht wird, können Sie über eine Verbesserung des gesamten Prozesses, eine Erhöhung der Rollout-Geschwindigkeit und andere Änderungen nachdenken.
Für viele Organisationen reicht ein CI aus und CD sollte nur dann implementiert werden, wenn es einen Mehrwert bietet.
Mangel an relevanten Dashboards und Metriken
Sobald Sie Ziele festgelegt haben, kann das Entwicklungsteam ein Dashboard zur Messung von KPIs erstellen. Vor seiner Entwicklung lohnt es sich, die zu überwachenden Parameter zu bewerten.
Verschiedene Berichte und Anwendungen sind für verschiedene Teammitglieder nützlich. Scrum Master legen mehr Wert auf Status und Reichweite. Während die Geschäftsleitung möglicherweise an der Burnout-Rate von Fachkräften interessiert ist.
Einige Teams verwenden auch Dashboards mit roten, gelben und grünen Indikatoren, um den Status von CI/CD zu beurteilen und zu verstehen, ob sie alles richtig machen oder ob ein Fehler aufgetreten ist. Rot bedeutet, dass Sie auf das Geschehen achten müssen.
Wenn Dashboards jedoch nicht standardisiert sind, können sie irreführend sein. Analysieren Sie, welche Daten jeder benötigt, und erstellen Sie dann eine standardisierte Beschreibung ihrer Bedeutung. Finden Sie heraus, was für Ihre Stakeholder sinnvoller ist: Grafiken, Text oder Zahlen.
Fehlende manuelle Tests
Die Testautomatisierung legt den Grundstein für eine gute CI/CD-Pipeline. Aber automatisierte Tests in allen Phasen bedeuten nicht, dass Sie keine manuellen Tests durchführen sollten.
Um eine effiziente 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, über die Integration manueller Testbemühungen in die Pipeline nachzudenken. Sobald das manuelle Testen einiger Testfälle abgeschlossen ist, können Sie mit der Bereitstellungsphase fortfahren.
Versuchen Sie nicht, Tests zu verbessern
Eine effektive CI/CD-Pipeline erfordert Zugriff auf die richtigen Tools, sei es Testmanagement oder Integration und laufende Überwachung.
Ziel ist es, eine starke, qualitätsorientierte Kultur zu schaffen , überwachen Sie das Kundenerlebnis nach der Bereitstellung und verfolgen Sie Verbesserungen.
Hier sind einige praktische Tipps, die Sie leicht umsetzen können:
- Stellen Sie sicher, dass die Tests einfach zu schreiben und flexibel genug sind, damit sie bei einer Umgestaltung des Codes nicht abbrechen.
- Entwicklungsteams sollten in den Testprozess einbezogen werden – sehen Sie sich eine Liste der Benutzerprobleme und -anforderungen an, die während der CI-Pipelines getestet werden müssen.
- Möglicherweise verfügen Sie nicht über eine vollständige Testabdeckung, aber stellen Sie immer sicher, dass die Abläufe getestet werden, die für UX und das Kundenerlebnis wichtig sind.
Last but not least Punkt
Der Übergang zu CI/CD wird in der Regel von unten nach oben eingeleitet, ist aber letztendlich eine Transformation, die die Beteiligung des Managements, Zeit und Ressourcen des Unternehmens erfordert. Schließlich handelt es sich bei CI/CD um eine Reihe von Fähigkeiten, Prozessen, Werkzeugen und kulturellen Umstrukturierungen, solche Veränderungen können nur systematisch umgesetzt werden.
Was gibt es sonst noch zum Thema zu lesen?:
- .
- .
- .
Source: habr.com