Heute beobachten wir, wie das Wasserfallentwicklungsmodell weltweit allmählich stirbt. Sie wird nicht wegen ihrer Schwere und schlechten Reaktion auf Veränderungen geliebt. Dies wirkt sich direkt auf die Relevanz des Produkts aus und erhöht die TTM (Time-to-Market), was zu zusätzlichen Kosten führt. Entwickler bauen auf agilen Schienen um, und wir sind keine Ausnahme.
Die agile Methodik wurde ursprünglich für kleine Teams entwickelt, die ein schlüsselfertiges Produkt im End-to-End-Modus herstellen und selbst für dessen Qualität verantwortlich sind. Was aber, wenn Sie hochkritische Bankensysteme entwickeln, über die Dutzende agiler Teams arbeiten? Wie kann das Vertrauen in das Produkt erreicht werden, das lange und umfassende Tests wie im Wasserfall ermöglicht? In diesem Beitrag werden wir unsere Lösung für dieses Problem vorstellen.
Jeder löst das Problem auf unterschiedliche Weise, aber normalerweise kommt es darauf an, die Automatisierung zu testen. Es werden Tests für Stubs entwickelt. Die allgemeinen Regeln für die Bildung von Rückständen benachbarter Teams sind Rahmenbedingungen für die Interaktion zwischen Teams wie SAFe. Aufgrund der Synchronisierung des Rückstands können Teams verwandter Produkte gemeinsam Tests schreiben und durchführen, einschließlich Integrationstests. Wir haben solche Rahmenbedingungen.
Aber jetzt setzen wir uns an die Stelle des Eigentümers eines komplexen und hochkritischen Bankensystems. Wer ist schließlich für die Qualität dieses gesamten Produkts verantwortlich, wenn sie direkt in Dutzende verantwortungsbewusster agiler Teams involviert sind? Sie müssen sicher sein, dass in der Produktion nichts ausfällt. Zusätzliche Tests einführen? Hallo, Wasserfall und Tschüss, TTM.
Es gibt keine perfekte Lösung. In dieser Situation wird es immer einen Konflikt zwischen den Prinzipien der Methodik und der garantierten Zuverlässigkeit des Ergebnisses geben. Dies ist der Kompromiss, den wir gefunden haben.
Qualitätstore
Wenn die Spezifität Ihres Produkts davon ausgeht, dass es nicht vollständig von anderen isoliert ist, sollten Sie an den Kontaktpunkten nach einer Regel spielen - beachten Sie das Mindestqualitätsniveau. Der Code sollte durch Unit-Tests abgedeckt sein, keine kritischen Mängel der Informationssicherheit enthalten, Verteilungen sollten bei Lieferung Rauchprüfungen unterzogen werden. Keine Dose, aber die Anforderungen sind für alle verbindlich. Ihre Implementierung ist ein Pass für allgemeine Tests.
Im Allgemeinen sieht die Praxis von
Quality Gates also wie eine Reihe automatisierter Überprüfungen aus, die in die Devops-Pipeline jedes Systems integriert sind. Tatsächlich spiegelt es die Tendenz zu Shift-Shift-Tests wider, über die heute häufig im Rahmen von Devops gesprochen wird.
Wir haben uns mit allen Teams auf eine Reihe von Überprüfungen und Qualitätstoren geeinigt, die sie im Verlauf der Phasen des Lebenszyklus bestehen müssen.
Codierung
Vor dem Erstellen des Codes benötigen Sie eine obligatorische statische Analyse, bei der der Code auf Übereinstimmung mit den Standards einer bestimmten Programmiersprache überprüft wird. Sowie die Vollständigkeit der Abdeckung mit Unit-Tests. Hierfür gibt es verschiedene Tools. Zum Beispiel lieben wir SonarQube. Nach dem Passieren dieses Qualitätstors können die Teams sicher sein, dass sie frühzeitig nicht gegen eine Reihe von Grundregeln verstoßen haben. Beispielsweise wurde eine signifikante Duplizierung vermieden, was die Komplexität des Codes und die Wahrscheinlichkeit von Problemen erhöht.
Der zweite Test vor dem Zusammenbau ist eine IS-Prüfung. Es gibt allgemein anerkannte Methoden zur Identifizierung von IS-Problemen im Code und Tools, mit denen der Code gescannt und gefährliche Stellen identifiziert werden können. Beispielsweise kann eine falsch deklarierte Variable zu Produktionsproblemen führen. Hier haben wir uns darauf geeinigt, nicht alles, was beim Schreiben des Codes enthüllt werden kann, Pentests und komplexeren Überprüfungen zuzulassen.
Verteilungsaufbau
Beim Zusammenstellen des Distributionskits überprüfen wir immer das Ergebnis: dass die Montage ordnungsgemäß verlief, dass alle Dienste gestartet wurden und ordnungsgemäß funktionieren, dass das Distributionskit in der gewünschten Umgebung installiert werden kann und funktioniert. Ein solcher Test zur Überprüfung des Gebäudes beseitigt mögliche Missverständnisse zwischen dem Tester und dem Entwickler. In der Wasserfallpraxis war es früher so, dass der Entwickler die Arbeit beendete, die Verteilung an die Tester weitergab und sich bei der Installation auf dem Stand herausstellte, dass die Montage noch nicht einmal begann. Dann wurde der gesamte Zyklus unterbrochen, die Entwicklung wurde gedehnt und es passierte überhaupt nichts Gutes.
Unsere Integrationsinteraktion ist sehr kompliziert. Es ist wichtig, den Stand nicht zu durchbrechen, an dem andere Teams überprüft werden können. Wir können dies aufgrund einer schlechten Verteilung tun, und die Nachbarn des Standes werden vor uns davon erfahren - wir werden einfach den gesamten Arbeitsprozess für sie stören. Außerdem können dadurch die Testdaten ruiniert werden. Und ihre Vorbereitung kostet auch Geld und nimmt viel Zeit in Anspruch. Besonders wenn es um anonymisierte Benutzerdaten geht.
Rauchtests
Da das Verteilungskit auf jedem Prüfstand installiert ist, besteht es eine Reihe einfacher Rauchtests. Am Systemteststand wird die Funktionalität der Distribution getestet. Außerdem wird das Verteilungskit auf den Integrationsprüfstand gestellt, wo Integrationsinteraktionen getestet werden. Es werden auch eine Reihe von Rauchtests durchgeführt. Wenn die Verteilung sie nicht besteht, kann er nicht mit der nächsten Stufe fortfahren.
Mit diesen Qualitätsgattern erhalten wir eine erste Vorstellung von der Qualität der Verteilung. Wenn die Rauchtests erfolgreich waren, beginnt das Team mit den Tests. Wenn das Verteilungskit zu diesem Zeitpunkt die Rauchtests nicht bestanden hat, besteht es höchstwahrscheinlich keine manuellen Tests. Hier weisen wir es nur zu, wenn die Baugruppe möglicherweise bereit ist, zum Abschlussball zu gehen.
Qualitätstore als Rahmen
Wir bemühen uns sicherzustellen, dass Qualitätstore zu einem vollständigen Rahmen für das Management der Entwicklungsqualität einer großen Anzahl von Produkten in Agilität werden. Wenn ein Team nicht einmal die obligatorischen Qualitätsgatter passiert, ist dies ein Signal dafür, dass es Probleme gibt, die diskutiert und gelöst werden müssen. Auf der anderen Seite kann ein Team, das die grundlegenden Qualitätstore bereits beherrscht und in interne Verfahren integriert hat, noch weiter gehen und zusätzliche Qualitätstore einbeziehen.
In Zukunft planen wir die Einführung neuer Sätze obligatorischer Qualitätstore. Und auch optional, damit jedes Team mit einem ausreichenden Reifegrad wählen kann, was es braucht. Wenn Sie beispielsweise die Stabilität des Verteilungspakets an Integrationsteststandorten ermitteln möchten, nimmt das Team nur Qualitätstore. Wenn Sie sicherstellen müssen, dass eine komplexe Baugruppe mit mehreren Komponenten die Bereitstellung nicht behindert, wird dies von anderen übernommen. Jemand hat eine Tendenz zur Sicherheit an vorderster Front, jemand zur Überprüfung von Lasttests, Verfügbarkeit von Ständen, Reaktion, jemand vor der Integration oder Überprüfung einiger Daten. Jedes Team wird in der Lage sein, hochwertige Tore für seinen Fall zu finden.
Es ist wichtig zu beachten, dass Qualitätstore kein Ersatz für Tests sind, sondern
ein primäres Kontrollinstrument . Niemand bricht das Testen ab. Die Hauptaufgabe besteht darin, den Schaden für andere Teams durch schlechte Produktqualität so früh wie möglich zu minimieren.
Ein Beispiel für eine Pipeline eines Drittanbieters, die Qualitätsgatter enthältErgebnisse der Implementierung von Quality Gates
Zunächst haben wir die Stabilität des Produktionszyklus erhöht. Als Shift-in-Action können wir kritische Funktionsfehler sofort erkennen. Es wird weniger Zeit für verschiedene Testiterationen aufgewendet, frühere Fehler werden erkannt, sodass ihre Beseitigung billiger ist.
Die Vorlaufzeit hat sich verkürzt - die Zeit vom Beginn der Feature-Codierung bis zur Implementierung in der Produktion. Die Stabilität der Engineering-Phase von TTM hat sich aufgrund der Tatsache erhöht, dass wir die Ausfallzeiten bei der Lieferung des Distributionskits an die industrielle Umgebung reduziert haben. Wir verbringen die gleiche Zeit mit Tests, haben jedoch keine Ausfallzeiten aufgrund des Zusammenbruchs des Standes und der Notwendigkeit, auf den Wiederaufbau der Distribution zu warten.
Die für Testumgebungen verfügbare Zeit hat zugenommen. Zuvor konnten Sie eine Baugruppe darauf setzen und diese für eine Woche vergessen. In der Zwischenzeit konnten verwandte Teams in dieser Umgebung nicht getestet werden, da Ihr Build fehlerhaft ist und Sie erst nach einer Woche davon erfahren. Wenn Sie die Baugruppe auf den Boden stellen, testen Sie sie selbst auf die häufigsten Probleme. Rollen Sie sie gegebenenfalls zurück, beenden Sie sie und geben Sie sie zurück. Und die Chance, niemanden aufzuhalten, wird viel höher. Die Einführung von Qualitätstoren wird auch zu einer Reduzierung der Kosten für die Wiederherstellung von Ständen und die Umschulung von Testdaten führen.
Ihre Meinung
Wie eingangs gesagt, kann der Widerspruch zwischen den Prinzipien der agilen und integrierten Entwicklung nicht als gordischer Knoten geschnitten werden. Man kann nur darauf achten, dass es so wenig Probleme wie möglich gibt. In unserem Fall hilft die Praxis von Qualitätstoren, aber wir halten sie natürlich nicht für ideal. Wie lösen Sie dieses Problem? Es wäre sehr interessant für uns, dieses Thema zu diskutieren.
Nikolay Vorobyov-Sarmatov, Sberbank-Technologie, Sberworks
Vielen Dank an Mikhail Bizhan für die Hilfe bei der Vorbereitung des Artikels!