Stellen Sie sich eine fantastische Situation vor - der Direktor des Unternehmens beschließt, DevOps zu implementieren. Selbst ohne Druck von Technikfreaks. Ohne überzeugendes Beispiel von Wettbewerbern. Das Management selbst erkannte, dass es ohne DevOps-Tools unmöglich ist, die Produktqualität, Vorhersehbarkeit, Transparenz und Wiederholbarkeit von Geschäftsprozessen bei der Entwicklung und Implementierung von Software zu verbessern.
Präsentiert? Hat es geklappt? Sie haben den Test für die reichste Fantasie erfolgreich bestanden!
In der Tat ist dies natürlich nicht so. In den meisten Fällen entspricht das Management nicht unseren IT-Anforderungen. Deshalb muss man überzeugen. Aber wie?
Wenn ein Argument vorgebracht wird, um die Kommunikationskultur zwischen Programmierern und Systemadministratoren zu verbessern, kann man leicht auf ein Gegenargument stoßen: Sind Sie jetzt unzivilisiert, oder was? Oder sie erinnern Sie sogar an die Kosten, die dem Unternehmen bereits vor ein oder zwei Jahren entstanden sind, als Sie zusammen zu Agile gezogen sind. Gibt es in der IT jedes Jahr eine Funktion, die Prozesse auf revolutionäre Weise vorantreiben kann?
Um die Qualität des Produkts zu verbessern, können Sie auch stammeln. Aber sei vorsichtig. Da die Aufgabe der fehlerfreien Programmierung noch nicht abgebrochen wurde. Ja, es gibt in keiner Weise Fehler, aber deshalb hat das Unternehmen eine "ganze Abteilung von Testern", oder?
Die Vorhersagbarkeit von Prozessen ist im Allgemeinen ein solcher subjektiver Faktor, der nur schwer zu rechtfertigen und Witze über Wang und Nostradamus zu vermeiden ist.
Wenn es sich um ein typisches Unternehmen handelt, gibt es in einem solchen Unternehmen höchstwahrscheinlich bereits ein etabliertes IT-Team. Und dieses Team im alten (außer agilen) Gewohnheitsrhythmus arbeitet seit vielen Jahren zusammen und brennt kaum vor dem Wunsch (wieder), etwas zu ändern. Alles passt zu jedem, außer natürlich der Führung. Da in ihrer Software ständig Fehler gestreamt werden, werden die Bedingungen für die Veröffentlichung neuer Versionen verschoben.
Natürlich kann eine weitere Option angenommen werden, wenn eine Person mit Erfahrung in DevOps in das Unternehmen kommt und klar darstellt, was das Problem ist und wie es gelöst werden sollte. Und wer kann der Führung seine Meinung mitteilen. Hoffen wir jedoch nicht auf einen Wunderonkel.
Und viele brechen daran. Sie beginnen zu sagen, dass niemand sie unterstützt, dass es unmöglich ist, irgendetwas in diesem Sumpf zu implementieren, und gehen dann einfach zu einer anderen Firma, wo sich der Zyklus wiederholt.
Es stellt sich ein Teufelskreis heraus? Nein, nur allmählich kommen wir zu dem Schluss, dass Sie bei einem Unternehmen nur in einer Sprache sprechen müssen, die er versteht - in der Sprache des Geldes. Zu diesem Zweck erhalten wir den Haupttrumpf aus den Beinen mit den weiten Ärmeln - die Verkürzung der Markteinführungszeit. Wir müssen zeigen, dass dank DevOps neue Versionen des Produkts wie Hotcakes veröffentlicht werden. Lassen wir den Rest der oben genannten Vorteile aus der Implementierung von DevOps für die Abschlusspräsentation, die wir für den Regisseur erstellen, wenn alles klappt. Viele werden sagen, dass dies zu offensichtlich ist. Nein!
Wir brauchen etwas, das uns ein Minimum an Zeit und Ressourcen kostet (schließlich wird niemand erlauben, Mannmonate für die Implementierung eines bestimmten DevOps abzuschreiben und keine dringend neuen Server für uns zu kaufen), aber gleichzeitig ein sehr greifbares Ergebnis liefern (es wird tatsächlich die Zeit bis verkürzen) -Markt).
Zuerst müssen Sie einen Engpass finden, aber es ist immer einer (der erste Schritt in Goldratts Theorie der Einschränkungen). Nach der erfolgreichen Implementierung von Agile (und all dies ist erst nach der Implementierung von Agile sinnvoll) müssen sie im Hinblick auf die Softwareentwicklung noch manuell getestet werden. Selbst mit einem Freihandpool können Regressionstests zwei bis drei Wochen dauern. Und von der Art und Weise, wie Tester Regressionstests „lieben“, weiß ich alles.
Wir haben also festgestellt, dass das Testen der Engpass ist. Dann müssen Sie mit der Automatisierung beginnen. Viele werden es bemerken: leichter gesagt als getan. Es wurden bereits Millionen von Codezeilen geschrieben, und es ist gut, wenn Programmierer zumindest etwas mit Komponententests abdecken. In der Tat ist nicht alles so beängstigend, wie es scheint. Die Erfahrung zeigt, dass 80% des erfolgreichen Ergebnisses in Form einer ernsthaften Verkürzung der Markteinführungszeit durch 20% der Anstrengungen erreicht werden. So viel kostet die Testautomatisierung in unserem Fall.
Absolut nach dem Pareto-Gesetz, ja.
Und am wichtigsten ist, dass Sie mit dem Testen der Automatisierung beginnen können, bevor das Management sich bereit erklärt, Ressourcen für die Implementierung der verbleibenden Teile von DevOps zuzuweisen. Ein kleines Pilotprojekt, das in ein bis zwei Wochen alleine durchgeführt werden kann.
Gleichzeitig gibt uns eine solche Situation die Chance, einen spektakulären und vor allem schnellen Sieg zu erringen. Danach können Sie mit einer positiven Einstellung und dem Segen der Führung bereits um Geld und Ressourcen bitten.
Zunächst verwenden Ihre Programmierer mit Sicherheit bereits eine Art Serversoftware für die täglichen Builds. Es kann TeamCity oder Bamboo oder Jenkins sein - es spielt keine Rolle. Die Hauptsache ist, dass es bereits einen Teil der Automatisierung gibt und dieser verwendet werden muss. Wenn nicht, ist es einfach, ihn an einem Tag bereitzustellen.
Zuerst müssen Sie die Rauchtests automatisieren. Aber wie kann man verstehen, was zu automatisieren ist? Ja, schauen Sie sich nur an, was Sie regelmäßig kaputt gemacht haben, als Sie Änderungen in den letzten sechs Monaten veröffentlicht haben.
Als Nächstes müssen Sie mehrere Tests erstellen, um den Betrieb der Hauptgeschäftsprozesse zu überprüfen. Wie identifiziere ich sie? Um Ihre Analysten / Direktoren / Unternehmensvertreter zu fragen, welche Art von Störung der verärgerte Direktor in das Büro des Programmierers stürzt und Aufgaben mit erhobener Stimme festlegt.
Eine Woche, also maximal zwei, um solche Tests zu erstellen. Das Ergebnis ist eine sehr schnelle Rückmeldung für globale Fehler.
Während sich das Projekt im Proof-of-Concept-Modus befindet, müssen Sie nicht dieselbe automatische Serverbereitstellung für Tests und andere Bögen vorbereiten, sondern alles manuell ausführen. Diese Schönheit kann dann mit Vergnügen zusammen mit Admins gemacht werden.
Was dies bewirken wird, ist nicht schwer zu erraten. Entwickler werden ihre Fehler sofort erkennen (und korrigieren). Den Testern wird die Routine erspart, lange und langwierige Regressionstests durchzuführen. Sie haben einige Tage Zeit, um nur die Teile des Codes zu testen, die bearbeitet wurden. Ja genau. Wenn nicht, kehren Sie zum Anfang zurück und sprechen Sie erneut mit Analysten / Direktoren / Unternehmensvertretern über geschäftskritische Prozesse.
Der Engpass, durch den die Hauptbremsen entstanden sind, wurde beseitigt. Jetzt müssen nur noch einige neue Releases in einer produktiven Umgebung veröffentlicht, die "Was / Was" -Statistiken entfernt und diese Zahlen an das Management weitergeleitet werden. Gewinn!
Nach einem so überzeugenden Sieg können Sie bereits über die Automatisierung des Einsatzes von Ständen sprechen (zumindest zum Testen). Fragen Sie als nächstes nach Mitteln für die Überwachung und andere DevOps-Freuden. Es sollte beachtet werden, dass die verbleibenden Komponenten des Systems keinen Wow-Effekt mehr für das Geschäft haben.
Studio Beispiel
Am Ende des Beitrags halte ich es für angebracht, ein Beispiel für ein erfolgreich abgeschlossenes Projekt zur Implementierung von DevOps zu nennen, das von unserem Unternehmen implementiert wurde.
Ein großer Einzelhändler hat ungefähr 20% des Geschäfts in einem Online-Shop. Gleichzeitig ist es notwendig, sehr schnell auf die Marktsituation zu reagieren und die notwendigen Änderungen an der Software vorzunehmen. Und oft. Und hohe Qualität. Jeder Pfosten auf der Website kann die Conversion beeinflussen, die Risiken werden in echtem Geld ausgedrückt.
Um die Zeit für die Aktualisierung und Verbesserung der Qualität zu verkürzen, wurde eine spezielle Autotest-Plattform erstellt, auf der Routineaufgaben zum Testen von Änderungen und zur Regression von Websites automatisiert wurden. Darüber hinaus wurde der Prozess der Interaktion der automatisierten Testgruppe mit den Entwicklungsteams aufgebaut. Auf diese Weise konnten Entwickler Fehler im aktualisierten System sofort identifizieren und beheben, ohne auf den endgültigen Abnahmetest warten zu müssen.
Vertreter des Einzelhändlers fanden die Erfahrung erfolgreich und beschlossen, sie auf andere Softwareprodukte anzuwenden.
Und noch ein kleines Beispiel, aber aus der Praxis einer großen Versicherungsgesellschaft. Vor der Einführung der Testautomatisierung wurden alle sechs Monate Releases veröffentlicht. Nicht, weil das Geschäft es so verlangte - es hat einfach nicht öfter geklappt. Und der Kunde wollte nur. Zwei Monate nach Beginn der Einführung von Autotest-Tools wechselte das IT-Team zu zweiwöchigen Iterationen von Release-Releases.
Bedeutend genug, um damit zu beginnen, nicht wahr?
Sergey Stramnov, Vorverkaufsarchitekt des Jet Infosystems Software Solutions Center