Wie vermeide ich durch kontinuierliche Integration verursachte Instabilitäten in Testumgebungen?

Angenommen, Sie verwenden kontinuierliche Integrationsprozesse, mit denen einige Zielumgebungen häufig aktualisiert werden, sodass "Sie" bei jeder Änderung Ihre Änderungen sofort testen können. Das gehört zu den Zielen von CI, oder?

Nehmen Sie aber auch an, dass andere Personen in Ihren Testzyklus involviert sind, z. B. Manager oder Kunden. Es ist sinnvoll, andere daran zu beteiligen, Ihre anstehenden Änderungen zu überprüfen (zu brechen?), Nicht wahr?

Wenn Sie jedoch kontinuierlich Änderungen in der Umgebung bereitstellen, in der diese anderen Personen ernsthaft versuchen, sie zu testen, können mehrere Probleme auftreten, z.

• they Verschwenden Sie möglicherweise Ihre Zeit damit, Probleme zu melden. Wenn Sie den (ausführlichen) Bericht speichern, können Sie das Problem nicht einmal mehr selbst reproduzieren (z. B. weil Sie versehentlich auf dasselbe Problem gestoßen sind und es bereits in Ihrer Umgebung behoben haben).
• you Die von ihnen gemeldeten Probleme können möglicherweise nicht reproduziert werden, da die Umgebungen, in denen sie auf ein Problem gestoßen sind, nicht mehr identisch sind (Sie (!!!) haben möglicherweise ihre Umgebung überlagert).

Was können Sie also tun (wie konfigurieren?), Um solche (frustrierenden) Situationen zu vermeiden?

Ich werde meine Erfahrungen in diesem Fall machen, vor allem, weil es zeigt, warum manche Antworten nicht immer zutreffen.

Ein wenig Kontext zum Starten:

• Wir haben 7 Umgebungen, in denen ca. 80 Anwendungen gehostet werden. Die meisten davon sind über Webservices oder gemeinsam genutzte Tabellen auf db2-iSeries aufeinander angewiesen.
• Ob gut oder schlecht, die iSeries sind unser DB-Referenzsystem.
• Dieser letzte Punkt macht jede Idee ungültig, die App mit ihren Abhängigkeiten in eine isolierte Umgebung zu bringen, da das Aufrufen eines AS400 für jede App zu viel kosten würde und wir nicht die Hardware hätten, um es trotzdem auszuführen.

Was wir tun, ist keine vollständig automatisierte kontinuierliche Lieferung. Wir haben einen Zeitplan für Veröffentlichungen, um eine zusammenhängende Menge von Anwendungen für den allgemeinen Betrieb zu erstellen. Abgesehen davon kann jedes Testteam in einer der Q / A-Umgebungen eine Freigabe für die zu testende Anwendung auslösen und eine Anwendungsversion sperren, um zu verhindern, dass eine andere Teamanforderung ihre Tests unterbricht.

Die Abhängigkeiten von Anwendungen werden vor der Freigabe geprüft, sodass das System nichts freigibt, wenn andere Anwendungen nicht aktualisiert werden können oder nicht mit den benötigten Abhängigkeiten übereinstimmen. Die Hauptidee ist es, Updates zuzulassen, wenn sie keinen Einfluss auf jemanden haben. Wenn keine Tests geplant sind, sollten sie aus der vorherigen Umgebung stammen validiert dieses 'on demand' Methodensystem).

Die Kurzversion soll ein 'Semaphor'-System für die Anwendungen in der Umgebung haben. Ein Team sollte in der Lage sein, seine Zielanwendung mit seinen Abhängigkeiten (und transitiven Abhängigkeiten) für die Zeit manueller Tests zu sperren.
Die Implementierung dieses Semaphors hängt stark von Ihrem Automatisierungssystem ab, daher werde ich darauf nicht näher eingehen.

Der einfache Weg ist natürlich, wie bereits erwähnt, eine neue Umgebung für eine Anwendung mit all ihren Abhängigkeiten zu erstellen, um das oben beschriebene Semaphor zu vermeiden.

Klingt so, als würden Sie von einer Testumgebung sprechen, die ständig wiederverwendet wird, ohne bei jeder Testausführung zuverlässig neu initialisiert zu werden. Dies macht einen solchen Test zu einem unzuverlässigen. Ähnlich ist es aus Sicht der Zuverlässigkeit mit manuellen Tests, wenn Sie möchten.

IMHO sollten Sie nicht solche Tests werden unter Verwendung innerhalb Ihres CI / CD Qualifikation Zwecke wie effektiv Ihren Qualifizierungsprozess ungültig machen (zumindest in diesem Bereich). Wenn Sie sagen, dass die Software Test X besteht, ohne Test X für jede gelieferte Softwareversion tatsächlich auszuführen, oder ohne die Gewissheit zu haben, dass das erhaltene passErgebnis nicht zufällig ist (aufgrund von falsch positiven Ergebnissen), wird das Vertrauensniveau Ihrer Tests beeinträchtigt. Falsche Negative schaden nicht der Glaubwürdigkeit, sind aber auch unerwünscht, weil sie unnötigen "Lärm" verursachen.

Es ist in Ordnung, solche Tests außerhalb Ihres CI / CD-Qualifizierungsprozesses durchzuführen . Sie würden ein fehlgeschlagenes Ergebnis in solchen Tests jedoch wie einen vom Kunden gefundenen Fehler behandeln: Sie müssten das Problem zuverlässig reproduzieren, um einen Fix dafür entwickeln und bestätigen zu können, dass der Fix funktioniert. Und das kann man nicht wirklich tun, wenn die Tests nicht zuverlässig sind.

Wenn Sie das Problem beheben möchten, sollten Sie zunächst einen automatisierten, zuverlässigen Testfall entwickeln, um das Problem zu reproduzieren. Womit Sie einen Fix entwickeln und seine Wirksamkeit bestätigen würden (Testergebnis sollte von FAIL nach PASS wechseln). Sie können (sollten?) Diesen Testfall auch in Ihren CI / CD-Qualifizierungsprozess einfügen, um ein erneutes Auftreten zu verhindern, wenn dies gewünscht wird, um die Qualität Ihrer gesamten Softwareversion zu erhöhen.

Der übliche Ansatz besteht darin, verschiedene Umgebungen zu erstellen:

DEV - das ist der Ort, an dem das Entwicklerteam die Dinge durcheinander bringt. Hier erstellen Sie alle Änderungen, stellen neue Versionen bereit und so weiter. Hier ist der Ort, an dem CI vollständig integriert ist.

PREPROD / QA - Dies ist der Ort, an dem das QA- / Test- / Validierungsteam Tests durchführt. Diese Umgebung friert normalerweise während der Tests ein. Die Integration von CI in diese Umgebung dient lediglich der Bereitstellung einer neuen Version des Produkts, von Konfigurationen usw.

PRODUKTION - muss man das erklären :)?

Wenn Sie CI / CD ausführen, bedeutet dies, dass vor der Bereitstellung (CD) einige automatische Tests durchgeführt werden. Wenn Sie in Ihrer Testumgebung viele Probleme feststellen, bedeutet dies, dass diese nicht von den Tests erfasst werden, die vor der Bereitstellung ausgeführt werden. Dies weist auf unzureichende automatische Tests hin. Wenn die Entwickler Probleme haben, bei denen Fehler in den Testumgebungen auftreten, müssen sie ihre automatisierten Testsuiten verbessern, um dies zu verhindern. Dies wird auch die Qualität und Zuverlässigkeit insgesamt bis hin zur Produktion verbessern.

Um die Antwort von Romeo Ninov zu ergänzen, müssen Sie innerhalb einer Umgebung versuchen, die Anwendungen so weit wie möglich voneinander zu trennen. Dies ist teilweise der Grund, warum Docker für Entwickler / Test so erfolgreich war. Sie können fast so tun, als ob Sie überhaupt keine Umgebung teilen.

Die andere Option besteht darin, dass die Server, auf denen die Anwendungen ausgeführt werden, sehr klar definiert sind und von der übrigen Infrastruktur, aus der Ihre Umgebung besteht, getrennt sind. Dh Alle Maschinen für das Umgebungsmanagement oder die Aktivierung werden auf separaten, langlebigen Servern ausgeführt. Anschließend schließen Sie neue kurzlebige Server an, die auf einem bekannten Image basieren, um eine Anwendung zu testen. Wenn Änderungen am Basisimage vorgenommen werden, müssen Sie diese Änderungen für jede neue Komponente überall anwenden . Was bedeutet, die Änderungen gegen alles zu testen.

Wenn ein appdev-Team nach einer Änderung fragt, durch die die Anwendung eines anderen Anwenders beschädigt wird, dann ist es ein großes Problem, dass dieser intern eine Schadensbegrenzung in seinem Code erstellt und seine spezifischen Anforderungen von den angebotenen Umgebungen getrennt hält.