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

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?

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.

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.

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.

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.