Wie können erfolgreich vorverifizierte Änderungen zu Regressionen führen, die hätten abgefangen werden müssen?

7

In einem CI-Kontext ist eine der häufig verwendeten Maßnahmen zur Erhöhung des Qualitätsniveaus des Integrationszweigs ein obligatorischer Satz von Qualitätsprüfungen vor dem Festschreiben (in der Regel einschließlich der Erstellung einiger Artefakte, der Durchführung von Komponententests und sogar einiger Funktions- / Integrationstests).

Einige Regressionen (Build-Brüche, verschiedene Testfehler) werden jedoch von den CI-Systemüberprüfungen in genau den Bereichen erkannt, die von diesen obligatorischen Überprüfungen vor dem Festschreiben abgedeckt werden sollten.

Während der Analyse dieser Regressionen wird häufig das Argument gehört, dass der Entwickler, der die als Grund für die Regression identifizierte Änderung begangen hat, alle derartigen Überprüfungen erfolgreich bestanden hat. Und oft wird die Behauptung durch harte Beweise gestützt, die darauf hinweisen, dass:

  • Nachdem die endgültige Version der Änderung erreicht war, wurde sie basierend auf der Spitze des Zweigs in einen neuen Arbeitsbereich portiert
  • Die erforderlichen Artefakte wurden von Grund auf neu erstellt (der Build war also völlig in Ordnung, keine Probleme mit dem Cache usw.).
  • Alle obligatorischen Tests wurden bestanden, einschließlich derjenigen, die den betreffenden Bereich abdecken, und sollten die Regression festgestellt haben
  • Keine zeitweiligen Fehlalarme beeinflussten die jeweiligen Überprüfungen
  • Beim Übertragen der Änderung in den Zweig wurden keine Dateizusammenführungen festgestellt
  • Keine der zu ändernden Dateien wurde von einer anderen Änderung in der Verzweigung berührt, seit der neue Arbeitsbereich abgerufen wurde

Ist es wirklich möglich, dass eine Softwareänderung eine solche Regression verursacht, obwohl alle vorgeschriebenen Prozesse und Praktiken korrekt befolgt wurden? Wie?

Dan Cornilescu
quelle
Mit Pre-Commit meinen Sie vor dem Aufrufen des CI-Systems (auf der Dev Workstation) oder SCM Hooks Checks? Ich sehe einen Fall bei Dev Workstaion, aber nicht bei Pre-Commit-Hooks.
Tensibai
Ich denke, es hängt vom genauen SCM-System ab. Ja, wenn sich die Hook-Ausführungen vor dem Festschreiben für zwei Änderungen, die in denselben Zweig gehen, zeitlich überschneiden können - wie dies beispielsweise bei git der Fall ist.
Dan Cornilescu
Entschuldigung, ich war unklar. Ich meine, werden Ihre Pre-Commit-Prüfungen auf der Dev-Workstation oder auf der SCM-Seite (zentrales Repository) ausgeführt? Alles in allem frage ich mich, ob es sich um Überprüfungen handelt, die ein Entwickler vor dem Festschreiben selbst startet, oder ob es sich um ein automatisiertes Testsystem handelt, das vom zentralen Server empfangen wird.
Tensibai
Ja, dorthin gehe ich. Mit dem Hinweis, dass die Regression auch bei zentralisierten Prüfungen auftreten kann - wenn sie sich zeitlich überschneiden dürfen.
Dan Cornilescu
Ok, dann rhetorische Frage (ich meine, eine, bei der Sie bereits die Antwort haben und wissen, worauf Sie warten). Das lässt überhaupt nicht viel Platz für echte Antworten.
Tensibai

Antworten:

5

Es gibt eine Möglichkeit, die ich mir vorstellen kann, wenn die Entwickler auf ihrer eigenen Workstation arbeiten und manchmal Bilder für die virtuelle Box gebacken werden, um auf ihrer Workstation ausgeführt zu werden, auf der Ihre Infrastruktur nicht genau das gleiche Image verwendet.

Der Entwickler muss während der Entwicklung einer Funktion einen JVM-Parameter oder eine beliebige Änderung an der Middleware zu Beginn seiner Arbeit hinzufügen und diese vergessen.

Vor dem Festschreiben funktionieren alle auf der Workstation ausgeführten Unit- / Integrationstests hervorragend, da das gebackene Image gemeinsam genutzt wird und auf jedem Develloper-System funktioniert.

Beim Durchlaufen von CI schlägt dies jedoch fehl, weil die Änderung an der Middleware nicht implementiert wurde, entweder weil der Entwickler vergessen hat, danach zu fragen, oder weil das Team, das für die Aktualisierung des Basis-Images / Provisioning-Systems verantwortlich ist, dies nicht getan hat die Zeit oder vergessen, das System zu aktualisieren.

Das ist eine gute Sache, die in CI kaputt geht, weil es früh vor Produktionsbeginn mitteilt, dass das System nicht wie erwartet funktioniert, aber manchmal ist es eine Hölle, den fehlenden Parameter zu finden.

Dieser letzte Punkt befürwortet, das Ablehnen von Commits zu vermeiden und nur CI in einem Feature-Zweig zu unterbrechen, damit niemand anderes blockiert wird. Lassen Sie den Entwickler das Problem frühzeitig beheben, wenn die Änderung erforderlich ist, und verhindern Sie, dass diese Änderung vergessen wird der Fluss.

FWIW, wir haben genau das hier getan, Entwickler hatten vollständigen Zugriff auf Entwicklungsmaschinen und Releases in Q / A scheiterten, weil eine Parameteränderung vergessen wurde. Wir sind zu Chef gegangen, um die Konfiguration der Middleware (jetzt Tomcat) zu übernehmen, damit jeder benötigt wird Änderungen an der Infrastruktur müssen irgendwo codiert werden und werden in allen Umgebungen reproduziert.

Tensibai
quelle
Bonuspunkte, wenn die vom Entwickler vorgenommenen Änderungen auf einer Funktion des Testframeworks beruhen, sodass sie überall außer in der Produktionsumgebung funktioniert (was ich einmal geschafft habe).
Jakub Kania
2

Sicher ist es das. Die Produktion ist immer anders. Echtes Geld. Echte Last. Echte Benutzer. Echter Schmerz. Aus diesem Grund ist es so wichtig, wesentliche Änderungen hinter ein Feature-Flag zu setzen. Ihre Bereitstellung sollte nichts ändern. Das Aktivieren einer Funktion ist das einzige, was wesentliche Änderungen an Ihrer Site vornehmen sollte.

Keine Rückerstattung Keine Rückgabe
quelle
Ich spreche von Regressionen, die vom CI-System erfasst werden - in der Integrationsbranche. Vor dem Einsatz in der Produktion.
Dan Cornilescu
Stellen Sie sich eine CSS-Änderung vor, die alle Tests besteht. In der Produktion wird jedoch festgestellt, dass der Umsatz auf 0 US-Dollar sinkt. Bei der Sichtprüfung wird festgestellt, dass der Schaltflächentext jetzt dieselbe Farbe wie der Hintergrund hat und Benutzer sich weigern, auf einen farbigen Fleck zu klicken. Die Automatisierung kann diese Art von Problem bestehen, es sei denn, Sie haben eine UI-Regression und die Regressionen werden tatsächlich überprüft. CI ist möglicherweise nicht dort, wo dieses Problem auftritt.
Keine Rückerstattung Keine Rückgabe
Ebenfalls behandelt: "Alle obligatorischen Tests wurden bestanden, einschließlich derjenigen, die den betreffenden Bereich abdecken und die Regression hätten erkennen müssen" - der gleiche Test, der bei der Überprüfung des Entwicklerimages vor dem Festschreiben bestanden wurde, jedoch mit dem nach dem Festschreiben der Änderung erstellten CI-Image fehlgeschlagen ist.
Dan Cornilescu
2

Der Bruch ist theoretisch immer möglich, da die vom Entwickler durchgeführte Überprüfung vor dem Festschreiben isoliert erfolgt und daher andere Änderungen während des Flugs, die parallel überprüft werden, nicht berücksichtigt werden können. Solche Änderungen können sich gegenseitig stören und Regressionen verursachen, ohne dass auf SCM-Ebene tatsächlich Kollisionen erkennbar sind.

Ein einfaches Beispiel für solche störenden Veränderungen:

Nehmen wir an, der Code in der neuesten Version eines Projektzweigs enthält eine bestimmte Funktion, die in einer Datei definiert und in einigen anderen Dateien aufgerufen wird. Zwei Entwickler, die parallel an diesem Projekt arbeiten, bereiten einige Änderungen am Code vor.

Entwickler A überarbeitet diese Funktion, indem ein obligatorisches Funktionsargument entfernt oder hinzugefügt wird, und aktualisiert natürlich alle Aufrufe der Funktion in allen zugehörigen Dateien, um der aktualisierten Definition zu entsprechen.

Entwickler B beschließt, einen Aufruf dieser Funktion in eine Datei einzufügen, die zuvor keinen solchen Aufruf enthielt und daher von den Änderungen von Entwickler A nicht berührt wird. Natürlich füllt Entwickler B die Argumentliste so, dass sie mit der Definition der Funktion übereinstimmt, die auf dem neuesten Etikett angezeigt wird. Dies ist die alte Definition, da die Änderungen von Entwickler A noch nicht festgeschrieben sind.

Beide Entwickler führen die Überprüfungen vor dem Festschreiben mit einem Bestehensergebnis korrekt durch und fahren mit dem Festschreiben ihrer Codeänderungen fort. Da die beiden Änderungssätze nicht dieselben Dateien berühren, findet keine endgültige Zusammenführung statt. Dies ist normalerweise ein Hinweis auf potenzielle Probleme, was eine genauere Betrachtung und möglicherweise eine erneute Ausführung der Überprüfung vor dem Festschreiben rechtfertigt. Nichts kann auch nur einen subtilen Hinweis darauf geben, dass etwas schief gehen könnte.

Das Endergebnis ist jedoch katastrophal - der Build ist fehlerhaft, da der von Entwickler B hinzugefügte Funktionsaufruf nicht mit der von Entwickler A aktualisierten Funktionsdefinition übereinstimmt.

Dan Cornilescu
quelle
1

Wenn Sie diese Art von Problem finden, sollten Sie einige neue, extrem schnell ablaufende Abnahmetests schreiben, mit denen diese Probleme behoben werden können, und sie zu Ihren Build-Überprüfungstests hinzufügen, die vor Ihren Integrationstests ausgeführt werden. Sie sollten ständig nach links wechseln und versuchen, die Rückkopplungsschleife für die Entwickler zu verkürzen, die Änderungen vornehmen. Wenn Sie keinen Weg finden, dies zu tun, ist Ihre Architektur möglicherweise nicht so agil, wie es sein muss.

@Dan Cornilescu - Ihr Szenario gilt für eng gekoppelte Architekturen, weshalb sich lose gekoppelte Architekturen (Microservices von versionierten RESTful-APIs) als aktuelle Best Practice in leistungsstarken Organisationen herausgestellt haben. Diese Matrix von Dienstleistungsunternehmen muss jedoch andere Komplexitäten überwinden.

Manchmal müssen Sie Ihre gesamte Architektur umgestalten, um solche Probleme zu lösen. Ich glaube, sowohl Google als auch eBay haben ihre Plattformen aufgrund von Einschränkungen, die ihnen durch ihre frühere Architektur auferlegt wurden, fünfmal (innerhalb von etwa zehn Jahren) vollständig überarbeitet.

icewav
quelle
Ich denke, Sie haben den Punkt der Frage übersehen: Die in der Frage erwähnten obligatorischen Qualitätsprüfungen vor dem Festschreiben enthalten bereits die Abnahmetests, über die Sie sprechen. Sie werden von Entwicklern vor ihren Commits und Pass ausgeführt und vom CI-System ausgeführt. Sie scheitern, nachdem beide Commits
eingegangen
Das war mein Punkt, vielleicht ist eine völlig neue Architektur die angemessene Antwort auf dieses Problem, die von der aktuellen Architektur nicht gelöst werden kann.
icewav
Sie meinen Produktarchitektur oder Prozessarchitektur?
Dan Cornilescu
Eine neue Produktarchitektur, wenn die aktuelle Prozessarchitektur das Problem nicht lösen kann.
icewav
Die Produktarchitektur ist irrelevant, die Frage gilt für so ziemlich jede Produktarchitektur, außer vielleicht für sehr kleine, triviale SW-Produkte. Siehe das Beispiel in meiner Antwort.
Dan Cornilescu