Wie implementiere ich eine eingefrorene Testumgebung?

Hier ist ein Teilzitat aus einer Antwort auf die Frage " Wie vermeide ich durch kontinuierliche Integration verursachte Instabilitäten in Testumgebungen? ":

Diese Umgebung friert normalerweise während der Tests ein.

Meine Frage: Was sind Beispielimplementierungen einer eingefrorenen Umgebung? Dh was können Sie tun, um technisch durchzusetzen, dass niemand (außer wenn dies von einem autorisierten Benutzer wie einem Release Manager erlaubt wird) in einer solchen eingefrorenen Umgebung etwas ändern kann?

Erläuterungen :

• Ich spreche nicht darüber, was (glaube ich) während der (z. B.) Verarbeitung zum Jahresende in Banken als "eingefrorene Perioden" bezeichnet wird. Dies bedeutet, dass keine Änderungen an Produktionsumgebungen vorgenommen (wiederholt) werden dürfen, um das Risiko zu verringern, dass neue Änderungen / Korrekturen eingeführt werden, die sich auf die Verarbeitung zum Jahresende auswirken können.

• Angenommen, Benutzer, die Änderungen trotzdem genehmigen / anwenden dürfen (wie der Release-Manager in meinem Beispiel), tun dies nur in Ausnahmefällen. Zum Beispiel, wenn beim Testen ein Problem mit hohem Schweregrad auftritt, bei dem es nicht möglich ist, einen Fix auf eine nächste Version zu verschieben (da die Produktion gefährdet wäre, wenn die Version ohne einen solchen Fix aktiviert würde).

• Hierbei kann es sich lediglich darum handeln, ein automatisiertes Update während des Tests auszusetzen. Der Punkt ist: Vermeiden Sie, dass eine andere Person eine Anwendung A auf Version Y aktualisiert, während ein anderes Team noch Anwendung B in Version X testet, die auf Anwendung A basiert. Dies kann bedeuten, dass ein Wachmann ein Testteam vermeidet, um eine Aktualisierung einer Abhängigkeit unter zu verlangen Prüfung.

Meine Antwort im Zusammenhang mit der Frage ist eine sehr teure Testumgebung (wie z. B. Mainframes oder sehr große Telekommunikationsgeräte), die voraussichtlich von mehreren Benutzern für mehrere Tests gemeinsam genutzt wird, sogar gleichzeitig.

In vielen Fällen verfügt ein solches Gerät über ein Software-Management-System, das unter anderem für die Steuerung der (Un-) Installation / Upgrades / Downgrades / etc. Welches einen Mechanismus zum Blockieren solcher Operationen haben sollte (was, wenn ich die Frage richtig verstehe, gleichbedeutend mit dem Einfrieren der Umgebung wäre), basierend auf einigen mehr oder weniger programmierbaren Richtlinien.

In einem solchen Fall könnte eine spezifische Richtlinie genau entwickelt werden, um den gewünschten Einfrierplan zu unterstützen, der für die Testumgebung erforderlich ist. Idealerweise automatisiert, wobei Auslöser zum Einfrieren / Auftauen von externen Quellen akzeptiert werden, bei denen es sich um Testausführungs-Wrapper oder CI-Systeme handeln kann. Und vielleicht mit vom Menschen ausgelösten Überschreibungen, wenn dies als notwendig erachtet wird.

Natürlich wäre eine solche Funktion des Software-Management-Systems hilfreich, wenn andere Komponenten des Geräts getestet werden, aber möglicherweise nicht für Tests des Software-Management-Systems selbst.

TeamCity verfügt über eine Build-Funktion für gemeinsam genutzte Ressourcen , mit der Sie eine Ressource definieren können, von der mehrere Build-Definitionen abhängen. Build-Definitionen können entweder eine Lesesperre oder eine Schreibsperre erfordern. Sie können auch definieren, ob diese Sperren exklusiv sind oder einen gewissen Grad an Parallelität zulassen.

Wenn wir die folgenden Annahmen über eine gemeinsam genutzte Umgebung mit dem Namen PreProd treffen :

• Es gibt eine gemeinsam genutzte Ressource mit dem Namen "PreProd".
• Alle Build-Definitionen, z. B. Bereitstellungen, die Änderungen an dieser Umgebung vornehmen, verfügen über eine exklusive Schreibsperre für "PreProd".
• Alle Build - Definitionen, wie nicht-restriktive Tests, die schreibgeschützt auf der Umwelt durchführen nehmen eine nicht-exklusive Lesesperre auf „PreProd“.
• TeamCity ist der einzige Prozess, der auf PreProd etwas tun kann, wenn auch möglicherweise über ein anderes Tool.

Daher gilt Folgendes:

• Wenn eine Bereitstellung stattfindet, kann PreProd von nichts anderem verwendet werden. Sie werden in die Warteschlange gestellt.
• Wenn ein Test ausgeführt wird, wird jede Bereitstellung in die Warteschlange gestellt, bis die Tests abgeschlossen sind.

Sie können einen ähnlichen Mechanismus mit Jenkins verwenden, indem Sie das Ausschluss-Plugin verwenden . Tatsächlich können Sie diese Funktionalität mithilfe von Sperren oder Semaphoren in jeden Prozess integrieren - zum Beispiel Apache ZooKeeper oder HashiCorp Consul .

Das klingt für mich nach einem Anti-Muster. Ich glaube, jeder oder niemand sollte Zugang zu allen Umgebungen haben.

Wenn Benutzer den Prozess untergraben, würde ich mir den Prozess ernsthaft ansehen, um sicherzustellen, dass er den Menschen nicht im Weg steht.

Die Implementierung eines automatisierten Mechanismus, der einen bestimmten Zustand erzwingt, ist auch nützlich, um Menschen zu ermutigen, die Dinge richtig zu machen. Dies kann über das Konfigurationsmanagement oder die Zerstörung einer unveränderlichen Instanz erfolgen, wenn jemand SSHs dazu bereitstellt