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

19

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?

Pierre.Vriens
quelle

Antworten:

10

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.

Tensibai
quelle
Diese Antwort ist eine Abwandlung dessen, was ich gewohnt bin (Mainframes), wo wir solche Dinge schon seit ungefähr 1,5 Jahrzehnten tun (bevor "DevOps" geboren wurde). Ich frage mich, ob es sinnvoll wäre, hier meine eigene Antwort hinzuzufügen (um diese Antwort weiter zu erweitern, wie wir dies mit CMN / ZMF für z. B. "Banken" tun) oder sie einfach auf eine neue (selbst beantwortete) Frage zu übertragen. Was denkst du? Ich bin auch neugierig auf diese Metapher-Sache, die eine neue Frage wert ist (in Bezug auf diese Antwort). PS: Stört es Sie, wenn ich einige Tippfehler korrigiere?
Pierre.Vriens
Kein Problem für die Bearbeitung :) Ich habe es allgemein gehalten, das ist nicht viel spezifisch für eine Devops-Organisation, IMHO. Wiederum ist DevOps eine Organisationsänderung, die dazu beitragen kann, eine bessere Automatisierung zu erreichen, indem sie die Bedenken teilt. Ich nenne dies ein Semaphor wie in der Programmierung. Ich halte es nicht für eine Frage, aber das liegt bei Ihnen
Tensibai,
Ok, Bearbeitung abgeschlossen (wie üblich: Rollback / Nach Belieben verbessern). Übrigens, hast du ein "s" auf deiner Tastatur?!?!?! Abgesehen davon: Dinge, über die man am Wochenende nachdenken sollte: siehe meine neueste Meta-Frage ... Gutes Wochenende! Zeit für die Gartenarbeit hier (beschneiden ...)
Pierre.Vriens
8

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.

Dan Cornilescu
quelle
In Ihrer Antwort gibt es viel zu verdauen (ich bin mir nicht sicher, ob ich sie bereits vollständig verstehe). Aber was Sie über " Ausführen solcher Tests außerhalb Ihres CI / CD-Qualifizierungsprozesses " geschrieben haben: Ich würde erwarten, dass das Endergebnis dessen, was produziert / geliefert wird, in Ihrer QS- und Produktumgebung gespeichert wird (entweder automatisch oder manuell per CD). Aber das " scheint " mir auch, dass CI dort auch seinen Output liefern sollte, während "draussen" wie Trennung oder Vervielfältigung oder so, oder?
Pierre.Vriens
Die Verweise insideund outsidebeziehen sich auf die CI-Überprüfungsschleife. Grundsätzlich stelle ich den Grund für die Existenz der QS-Umgebung in Frage - die meisten dort durchgeführten Tests sollten zuverlässig sein und schließlich im Rahmen der CI-Überprüfungen ausgeführt werden, insbesondere in einem kontinuierlichen Bereitstellungskontext - da Sie sie bei jeder CI-Iteration ausführen möchten (erfolgreich) jedenfalls bis dahin.
Dan Cornilescu
7

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 :)?

Romeo Ninov
quelle
ok, das sollte helfen die stabilität zu verbessern, merci! Meine Frage bezieht sich auf "Test" -Umgebungen, daher sollte "Produktion" offensichtlich nicht als solche betrachtet werden. Trotz derer, die "Produktion" zum Testen verwenden, kennen Sie den Spruch " Der beste Test ist, es in der Produktion zu aktivieren, und wenn es nicht funktioniert, führen Sie einfach ein Rollback / Backout durch! "?
Pierre.Vriens
@ Pierre.Vriens, "spielen" in prod IMHO ist nicht klug :) Eine solche Trennung der Umgebung ist beabsichtigt. Bei früheren Aufträgen hatten wir 5 verschiedene Umgebungen ... Ein Votre Serivce
Romeo Ninov
1
"Ich" stimme zu, dass ein solches Spielen nicht klug ist. Was kann "Sie" jedoch gegen die Cowboys tun (mein "Begriff", den ich für solche Juppies verwende), die dies immer wieder tun, und jedes Mal, wenn sie von ihren Managern die Genehmigung erhalten, die (z. B.) monatliche Release-Aktivierung zu umgehen , durch einen weiteren Bugfix (zB für ihren Bugfix vom Vortag ... der einen neuen Bug einbrachte). Glaubst du, dass das in der realen Welt nicht passiert? Übrigens: Was das "Einfrieren" in Ihrer Antwort betrifft, halten Sie es für sinnvoll, eine Frage wie "Was sind Beispielimplementierungen einer eingefrorenen Umgebung?" Zu stellen.
Pierre.Vriens
@ Pierre.Vriens, für mich ist es vollkommen sinnvoll, eine solche Frage zu posten. Normalerweise wird dies durch Unternehmensregeln geregelt, aber Entwickler schaffen ein recht dynamisches Umfeld und dies kann eine echte Herausforderung sein :)
Romeo Ninov
1
Dies ist meinen bevorzugten Ansatz, dass die Art und Weise es eine Umgebung gibt , wo die Entwickler sofort ihre Änderungen in einer integrierten Umgebung testen, aber hält QA sauber , bis der der Code fertig ist formal getestet werden
Taegost
3

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.

Adrian
quelle
3

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.

hvindin
quelle
Interessante Gesichtspunkte / Ergänzungen, obwohl es einige Dinge gibt, die Sie vielleicht verfeinern / überarbeiten möchten: (1) "Anwendungen" in diesem Kontext, was meinen Sie (einige Beispiele?) (2) eine Idee, wie dies funktionieren könnte (gute alte) Mainframe-Umgebungen (3) Was ist in diesem Zusammenhang hier ein "Milderungsfaktor"? PS: Sagen Sie mir Bescheid, wenn Sie der Meinung sind, dass ich für eines dieser "Dinge" (Aufzählungszeichen) eine neue Frage erstellen sollte.
Pierre.Vriens