Umgang mit Fehlern während Ihrer Entwicklung hin zu CD & DevOps

In diesem Gastbeitrag erläutert Paul Swartout, ein IT-Experte und Autor von Continuous Delivery und DevOps – Ein Quickstart-Guideerklärt, wie mit Fehlern während der Einführung von CD und DevOps umgegangen werden sollte.

Auf Ihrem Weg zur Einführung von CD und DevOps werden gelegentlich Dinge schief gehen; dies ist unvermeidlich und nichts, wofür man sich fürchten oder schämen müsste. Es kann Situationen geben, die Sie nicht vorhergesehen haben, oder Schritte im bestehenden Prozess, die während der Elefantenexposition nicht aufgegriffen wurden. Es könnte so einfach sein wie ein Problem innerhalb des ausgewählten Toolsets, das nicht das tut, was Sie sich erhofft hatten, oder einfach fehlerhaft ist.

Ihre natürliche Reaktion könnte darin bestehen, solche Fehler zu verbergen oder zumindest die Tatsache, dass ein Fehler aufgetreten ist, nicht zu verbreiten. Das ist nicht klug. Sie und Ihr Team arbeiten hart daran, ein Gefühl von Offenheit und Ehrlichkeit zu vermitteln, also ist das Schlimmste, was Sie tun können, genau das Gegenteil. Denken Sie zurück an das, was wir zuvor in Bezug auf das schnelle Versagen beim Auffinden von Fehlern behandelt haben. Der gleiche Ansatz funktioniert auch hier.

Eine Niederlage einzugestehen, sich in Embryonalstellung zusammenzurollen und wimmernd in der Ecke zu liegen, ist ebenfalls keine Option. Wie bei jeder Änderung gehen die Dinge schief, also überprüfen Sie die Situation, überprüfen Sie Ihre Optionen und machen Sie weiter. Sobald Sie eine Möglichkeit haben, das Problem zu umgehen oder zu überwinden, kommunizieren Sie dies. Stellen Sie sicher, dass Sie offen sagen, was das Problem ist und was getan wird, um es zu überwinden. Dies wird anderen zeigen, wie sie auf Veränderungen reagieren und damit umgehen können – eine Art Vorbildfunktion.

Sie könnten besorgt sein, dass das Eingeständnis von Fehlern den Nachzüglern mehr Munition liefern könnte, um die Adoption zu entgleisen; Ihr Sieg wird jedoch nur von kurzer Dauer sein, sobald die Innovatoren und Anhänger eine Lösung gefunden haben. Halten Sie fest, bleiben Sie standhaft und haben Sie Vertrauen.

Wenn Sie agile Techniken wie Scrum oder Kanban verwenden, um die Einführung von CD und DevOps voranzutreiben, sollten Sie in der Lage sein, die Richtung relativ schnell zu ändern, ohne den Fortschritt zu behindern.

Okay, das ist also alles sehr positive Einstellung (PMA) und kann von einigen von Ihnen, die zynischer als der Rest sind, als heiße Luft und Plattitüden des Managements angesehen werden. Schauen wir uns also ein Szenario an, in das ein fiktives IT-Unternehmen namens ACME Systems verwickelt ist.

ACME-Systeme implementierten ein Bereitstellungstransaktionsmodell, um Abhängigkeiten zu verwalten und sicherzustellen, dass zu einem beliebigen Zeitpunkt nur eine Änderung an das Produktionssystem weitergegeben wurde. Das funktionierte eine Zeit lang gut, aber die Dinge fingen an, sich zu verlangsamen. Automatisierte Integrationstests, die zuvor funktionierten, begannen zeitweise zu versagen; Es wurden Mängel in Funktionsbereichen gemeldet, die zuvor als kugelsicher angesehen wurden.

Diese Verlangsamung begann sich auf die Lieferfähigkeit des gesamten F&E-Teams auszuwirken, und der Geräuschpegel begann zu steigen, insbesondere von den stimmlichen Nachzüglern. Es folgten offene und ehrliche Diskussionen zwischen allen Beteiligten, und nach vielen Diskussionen stellte sich heraus, dass die Hauptursache des Problems eine sehr einfache Abhängigkeit war und das Änderungsmanagement nicht mit der Bereitstellungsgeschwindigkeit Schritt halten konnte.

Im Wesentlichen gab es keinen sicheren Weg, um zu bestimmen, welche Software-Asset-Änderung vor einer weiteren Software-Asset-Änderung abgeschlossen sein würde, und es gab keine einfache Möglichkeit, verschiedene Szenarien in Bezug auf die Integration auszuprobieren. Es lief darauf hinaus: Wenn Änderungen in Asset A von Änderungen in Asset B abhängig waren, musste Asset B zuerst live geschaltet werden, um vollständige Integrationstests zu ermöglichen.

Wenn Asset A jedoch zuerst bereit war, musste es warten – manchmal tage- oder wochenlang. Die Bereitstellungstransaktion begann zu behindern Kontinuierliche Lieferung (CD).

Hier ist ein einfacher Prozess, den ACME-Systeme als Bereitstellungstransaktion bezeichnet haben:
1.png

Alle waren sich einig, dass die Deployment-Transaktion gut funktionierte und eine funktionierende Alternative zur Abhängigkeitshölle darstellte. Wenn es jedoch im Zorn verwendet wurde, enthüllte es einen Fehler, der begann, echte und schmerzhafte Probleme zu verursachen. Selbst wenn Features durch Feature-Flags abgeschaltet werden könnten, gab es keine Möglichkeit, die Integration vollständig zu testen, ohne alles in der Produktion und der Live-Umgebung bereitzustellen.

Dies war zuvor kein Problem, da die Geschwindigkeit der Veröffentlichungen sehr langsam war und die Assets zusammengeballt wurden. ACME-Systeme konnten nun sehr schnell in der Produktion bereitgestellt werden und hatten nun ein neues Problem: In welcher Reihenfolge bereitgestellt? Es fanden viele Diskussionen statt und es wurden komplizierte Optionen in Betracht gezogen, aber am Ende war die Lösung ganz einfach: Verschieben Sie die Grenze der Bereitstellungstransaktion und ermöglichen Sie vollständige Integrationstests, bevor die Assets in die Produktion gehen.

Es lag dann an den verschiedenen F&E-Teams, manuell auszuarbeiten, in welcher Reihenfolge die Dinge bereitgestellt werden sollten.

Das folgende Diagramm zeigt die überarbeitete Transaktionsgrenze für die Bereitstellung:
2.png

ACME hatte also einen potenziellen Showstopper, der ihre CD- und DevOps-Adoption vollständig hätte entgleisen lassen können. Das Problem wurde sehr sichtbar und viele Fragen wurden gestellt. Die Anhänger begannen, an den Innovatoren zu zweifeln, und die Nachzügler wurden lautstark. Mit etwas guter altmodischer Zusammenarbeit und ehrlichen Diskussionen wurde das Problem schnell überwunden.

Auch hier sind offene und ehrliche Kommunikation und mutiger Dialog der Schlüssel. Wenn Sie immer wieder überprüfen und zuhören, was die Leute sagen, haben Sie eine viel bessere Gelegenheit, potenzielle Hürden zu erkennen, bevor sie Ihren Fortschritt vollständig blockieren.

3.PNG

Eine andere Sache, die Ihre Implementierung scheitern und das Vertrauen untergraben kann, sind inkonsistente Ergebnisse.

Prozesse, die nicht wiederholbar sind

Techniker tendieren dazu, alles zu automatisieren, was sie berühren, wie z. B. das automatisierte Bauen eines Ingenieurarbeitsplatzes, das automatisierte Bauen von Software und das automatische Einschalten der Kaffeemaschine, wenn die Bürobeleuchtung angeht. Das ist nichts Neues, und an diesem Ansatz ist nichts auszusetzen, solange der Prozess wiederholbar ist und konsistente Ergebnisse liefert. Wenn die Ergebnisse nicht konsistent sind, werden andere zögern, die Automatisierung zu verwenden, an der Sie viele Stunden, Tage oder Wochen gearbeitet haben.

Wenn es um CD und DevOps geht, sollte der gleiche Ansatz gelten, insbesondere wenn es um Tools geht. Sie müssen den Ergebnissen vertrauen, die Sie immer wieder erhalten.

Einige glauben, dass interne Tools und arbeitssparende Lösungen oder Prozesse, die nicht in der feindlichen Kundenwelt eingesetzt werden, keine Produktionsqualität haben müssen, da sie nur von Mitarbeitern im Unternehmen, hauptsächlich von Technikern, verwendet werden. Das ist zu 100 Prozent falsch.

Schauen wir uns ein sehr einfaches Beispiel an: Wenn Sie ein Softwareentwickler sind, verwenden Sie eine IDE, um Code zu schreiben, und Sie verwenden einen Compiler, um die bereitzustellende Binärdatei zu generieren. Ich werde ein SQL-Verwaltungsprogramm verwenden, um Ihre Datenbanken zu verwalten und SQL zu schreiben. Sie werden erwarten, dass diese Tools zu 100 Prozent funktionieren und konsistente und wiederholbare Ergebnisse liefern. Sie öffnen eine Quelldatei und die IDE öffnet sie zum Bearbeiten, und Sie führen etwas SQL aus, und das SQL-Verwaltungstool führt es auf dem Server aus.

Wenn Ihre Tools immer wieder abstürzen oder unerwartete Ergebnisse liefern, werden Sie ein wenig verärgert sein (höflich ausgedrückt) und werden die besagten Tools zweifellos nicht mehr verwenden. Es kann Sie verrückt machen.

Dasselbe gilt für die (technischen und nicht-technischen) Tools, die Sie für Ihre CD- und DevOps-Einführung erstellen und/oder implementieren. Diese Tools müssen so gut (wenn nicht sogar besser) sein wie die Software, die Ihre Teams erstellen.

Die Benutzer der implementierten Tools/Prozesse müssen darauf vertrauen können, dass sie dieselben Ergebnisse erzielen, wenn sie immer wieder dieselben Aktionen ausführen. Wenn dieses Vertrauen wächst, wächst auch das Vertrauen in das Tool/den Prozess. Letztendlich wird das Tool/der Prozess als selbstverständlich angesehen und die Leute werden es ohne einen zweiten Gedanken verwenden.

Folglich werden die Leute auch darauf vertrauen, dass, wenn die Ergebnisse vom letzten Lauf abweichen, etwas Schlechtes eingeführt wurde (z. B. ein Softwarefehler erstellt wurde), das sofort behoben werden muss.

Überlegen Sie, wie viel Vertrauen und Zuversicht untergraben werden, wenn das Tool/der Prozess ständig fehlschlägt oder andere und/oder unerwartete Ergebnisse liefert. Sie müssen daher sehr zuversichtlich sein, dass die Werkzeuge/Prozesse für den Zweck geeignet sind.

Auf mögliche Hürden in Bezug auf Unternehmensrichtlinien, Bürokratie und Standards haben wir bereits eingegangen. Stellen Sie sich vor, wie viel Spaß es Ihnen machen wird, die Gatekeeper davon zu überzeugen, dass CD und DevOps kein Risiko darstellen, wenn Sie keine konsistenten Ergebnisse für wiederholbare Aufgaben liefern können. Okay, Spaß ist vielleicht nicht das richtige Wort; Vielleicht ist Schmerz besser.

Ein weiterer Vorteil konsistenter, wiederholbarer Ergebnisse kommt bei der Betrachtung von Metriken ins Spiel. Wenn Sie darauf vertrauen können, dass die Bereitstellung desselben Assets auf demselben Server bei jeder Bereitstellung dieselbe Zeit in Anspruch nimmt, können Sie beginnen, Probleme zu erkennen (z Infrastrukturproblem oder etwas Grundlegendes hat sich in der Konfiguration geändert).

Alles in allem mag es langweilig und nicht sehr innovativ klingen, aber mit konsistenten und wiederholbaren Ergebnissen können Sie aufhören, sich um das Alltägliche zu sorgen, und Ihre Aufmerksamkeit auf die Probleme lenken, die gelöst werden müssen, wie z transformierendes oder transformiertes Unternehmen.

Wenn Sie diesen Artikel gerne gelesen haben, können Sie ihn überprüfen Continuous Delivery und DevOps – Ein Quickstart-Guide. Dieses Buch behandelt Szenarien aus der realen Welt und bietet Beispiele, Tricks und Tipps, um Ihnen den Weg zur CD- und DevOps-Einführung zu erleichtern. Sie werden durch die verschiedenen Phasen der Einführung geführt, um sicherzustellen, dass Sie für den Erfolg gerüstet sind und sich der Arbeit, Tools, Techniken und des Aufwands bewusst sind, die erforderlich sind, um die enormen Vorteile zu realisieren, die CD und DevOps mit sich bringen können.

Similar Posts

Leave a Reply

Your email address will not be published.