Wie ähnlich sollten die Umgebungen von PreProd und Prod sein?

10

Ich war erst kürzlich an einem Projekt und während der Veröffentlichung haben wir festgestellt, dass es in der Produktion nicht funktioniert hat. Es funktioniert in allen anderen Umgebungen. Da wir jedoch ein separates Release-Team haben und die Server und Umgebungen nicht selbst einrichten können, ist die Konfiguration auf ihnen nicht sichtbar.

Wir vermuten, dass Prod einige Benutzerberechtigungen in seinem Konto oder in den IIS-Einstellungen hat, die unterschiedlich sind. Deshalb arbeiten wir jetzt daran.

Ich denke, das Ganze war eine Lernerfahrung für mich und ich möchte nicht, dass dasselbe noch einmal wiederholt wird. Ich möchte fragen, wie unterschiedlich diese Umgebungen sein sollten. Ich war immer der Meinung, dass PreProd eine identische Kopie der Prod-Umgebung sein sollte, wobei eine Kopie derselben Datenbank, eine Kopie desselben Benutzerkontos, auf denselben Servern usw. installiert werden sollte.

Aber wie weit soll ich gehen? Wenn die Website nach außen zeigt, sollte PreProd nach außen gerichtet sein? Was ist, wenn die Website Komponenten enthält, für deren Navigation kein Benutzerkonto oder Kennwort erforderlich ist? Ist es noch in Ordnung, es der Außenwelt auszusetzen?

development-process

— RoboShop
quelle

Überall, wo ich gearbeitet habe, war Pre-Prod eine direkte Kopie von Production, mit der Ausnahme, dass die Datenbank (en) eine Woche alt sind.

— Nickz

@ Nick: Ich meine nicht nur die Codebasis, ich meine wie die gesamte Einrichtung der gesamten Umgebung.

— RoboShop

6

Sie sollten auf jeden Fall in einer Umgebung testen, die so weit wie möglich mit Ihren Produktionssevern identisch ist. Wenn Sie dies nicht tun, testen Sie nicht, was Ihre Kunden verwenden werden. Wenn nichts anderes, benötigen Sie eine solche Umgebung, um Fehlerberichte zu testen.

Natürlich wird es Dinge geben, die Sie nicht identisch wollen - Links zu Zahlungssystemen fallen Ihnen ein, aber diese sollten verspottet werden, als ob sie die Realität wären . Es gibt auch Dinge, die Sie nicht replizieren können - die Größe des Systems.

Möglicherweise möchten Sie über eine externe URL testen. Wieder testen Sie, was Ihre Benutzer sehen werden. Auch beim Testen über eine externe URL wird das Netzwerk anders verwendet als bei der internen Nutzung des Systems. Berechtigungen (zum Beispiel) spielen eine Rolle, ebenso wie die verfügbare Bandbreite, Firewalls usw. Alle Benutzer werden konfrontiert, aber Sie überspringen, wenn Sie direkt auf das System zugreifen.

Ich sehe kein Problem mit Komponenten, für die kein Konto und kein Kennwort erforderlich sind. Wenn es kein Passwort benötigt, ist es nicht wichtig / sensibel. Wenn es sensibel ist, warum hat es dann kein Passwort?

— ChrisF
quelle

Wow, das ist eine dumme Antwort. Wenn Sie also in Ihrer Testumgebung einen Kauf tätigen, sollte die Kreditkarte belastet und das, was Sie gekauft haben, versendet werden. Wenn die Produktumgebung aus 150 Servern besteht, sollte die Testumgebung auch? Ich hätte "offensichtlich" gesagt, dass es Unterschiede zwischen Prod und Test geben muss, aber für ChrisF war das nicht offensichtlich.

— Malvolio

@ Malvolio - nein. Das habe ich überhaupt nicht gemeint. Ich habe mehr über die in der Frage angesprochenen Punkte mit Berechtigungen, Verbindungen usw.

— nachgedacht

11

Ich denke, die beste Vorgehensweise hierfür ist der Blue Green Deployment-Ansatz, der von Jez Humble und David Farley in ihrem Buch Continuous Delivery geprägt und von Martin Fowler in seinem Blogbeitrag Blue Green Deployment beschrieben wurde .

Die Prämisse ist sehr einfach. Aus Martin Fowlers Beitrag:

Blaugrüne Bereitstellung

Der blau-grüne Bereitstellungsansatz ... [stellt sicher], dass Sie über zwei Produktionsumgebungen verfügen, die so identisch wie möglich sind. Zu jeder Zeit ist einer von ihnen, sagen wir zum Beispiel Blau, live. Während Sie eine neue Version Ihrer Software vorbereiten, führen Sie Ihre letzte Testphase in der grünen Umgebung durch. Sobald die Software in der grünen Umgebung arbeitet, schalten Sie den Router so um, dass alle eingehenden Anforderungen an die grüne Umgebung gesendet werden - die blaue ist jetzt inaktiv.

Die blau-grüne Bereitstellung bietet Ihnen auch eine schnelle Möglichkeit zum Rollback. Wenn etwas schief geht, schalten Sie den Router wieder in Ihre blaue Umgebung um.

Dieser Ansatz würde Ihr Problem lösen, keine identischen Vorproduktions- und Produktionsumgebungen zu haben und Ihre Bereitstellungsstrategie zu optimieren.

— Paddyslacker
quelle

1+ für das coole Diagramm

— Nickz

mmm nicht sicher, ob die Datenbank synchron bleibt. Es wäre schwierig. Was ist, wenn die Transaktion über Ihren Preprod-Server erfolgt ist? Würde sich das in der Produktion db widerspiegeln?

— RoboShop

Ist geschrieben, das ist sehr teuer. Sie müssen die gesamte für die Live-Produktion erforderliche Hardware nur zum Testen duplizieren. Aber ja, cooles Diagramm.

— Malvolio

1

TECHNIK In einem englischen Gericht wurde ein Mann namens Home wegen Verleumdung angeklagt, weil er seinen Nachbarn des Mordes beschuldigt hatte. Seine genauen Worte waren: "Sir Thomas Holt hat ein Hackmesser genommen und seinen Koch auf den Kopf geschlagen, so dass eine Seite des Kopfes auf eine Schulter und die andere Seite auf die andere Schulter fiel." Der Angeklagte wurde auf Anweisung des Gerichts freigesprochen. Die gelehrten Richter waren der Ansicht, dass die Worte keinen Mord anklagten, da sie den Tod des Kochs nicht bestätigten, was nur eine Schlussfolgerung war. - Ambrose Bierce

— Malvolio

1

Ja, technisch gesehen , ich nicht brauchen die Hardware zu duplizieren , aber auch wenn Sie diese Anforderung durch fooling um mit Virtualisierung und so ausweichen, man entweder (a) Ressourcen schwer zuzuordnen, wie Bandbreite und CPU, zu jeder Umgebung, die haben würde Die gleichen Kosten wie das Duplizieren von Hardware oder (b) das Teilen von Ressourcen, was bedeutet, dass Ihre Testprobleme Ihr Produktionssystem zum Erliegen bringen können.

— Malvolio

3

Unsere endgültige Vorproduktionsumgebung ist einfach einer der Live-Server, die aus dem Load Balancer entfernt wurden. Wir stellen unseren Preproduction-Build bereit (der abgesehen von Datenbankverbindungszeichenfolgen und einigen anderen Konfigurationsänderungen im Wesentlichen mit dem Live-Build identisch ist) und testen ihn. Wenn dies in Ordnung ist, stellen wir den Live-Code bereit. Wenn sich dies als in Ordnung herausstellt, geben wir den Server an den Load Balancer zurück und stellen den Produktionsbuild nacheinander auf den verbleibenden Servern bereit.

— FinnNk
quelle

1

Sie sollten so ähnlich wie möglich sein, damit Sie Probleme an jedem Punkt im System identifizieren können, mit der möglichen Ausnahme einer Unfähigkeit zur Skalierung. Wenn möglich, besteht der einzige Unterschied zwischen Ihrer Produktionsumgebung und der Vorproduktions- / Staging- / Testumgebung in der Größe. Ich würde erwarten, dass eine Produktionsumgebung aus viel mehr Maschinen in einer großen Umgebung besteht. Sie sollten sogar die Widmungen Ihrer Computer spiegeln, z. B. Datenbankserver, Webserver usw.

Eine genaue Replikation ist jedoch unter Ihrem aktuellen Budget möglicherweise nicht möglich. Je näher es ist, desto effektiver werden die Tests und desto weniger wahrscheinlich treten Probleme während eines Produktionsschubs auf.

Ich bin anderer Meinung als ChrisF, wenn dieses Umfeld öffentlich zugänglich sein sollte. Ich sage es sollte nicht sein. Ich würde mich dafür entscheiden, auf einer Kopie der tatsächlichen Datenbanken oder zumindest einer Kopie einer Teilmenge der tatsächlichen Live-Datenbanken und einer nach innen gerichteten Umgebung zu arbeiten. Auf diese Weise können Sie anhand tatsächlicher und realistischer Daten testen und müssen sich keine Sorgen über Sicherheitslücken machen, die zu einem Leck führen. Sie können die Daten natürlich bereinigen, aber dadurch werden möglicherweise einige "schmutzige Daten" aus der Umgebung entfernt, die zur Entdeckung eines Defekts in einem Live-System führen können.

— Thomas Owens
quelle

1

Wenn Sie Sicherheitstests durchführen, sollte dies nicht öffentlich zugänglich sein, aber Sie möchten möglicherweise, dass es zum Beispiel für endgültige Abnahmetests verwendet wird.

— ChrisF

Das ist auch ein gültiger Punkt. Ich bin in der Regel eher auf Sicherheit als auf Benutzerfreundlichkeit ausgerichtet. Wenn Sie jedoch eine neue Version Ihres Systems für Abnahmetests verfügbar machen möchten (möglicherweise von Kunden oder als Teil einer öffentlichen Beta), dann ja, eine öffentlich zugängliche Version Umwelt wäre erforderlich.

— Thomas Owens

Ja, wir hatten früher einen Konkurrenten, der ungefähr eine Woche lang all seine Sachen auf einem öffentlich zugänglichen Computer testete, bevor er live ging. Sie haben nie herausgefunden, wie wir bekamen Funktionen aus immer richtig , bevor sie taten ...

— Malvolio

1

Überall, wo ich bei Banken, Telekommunikation usw. gearbeitet habe, war Pre-Prod eine direkte Kopie der Produktion, außer dass die Datenbank ungefähr eine Woche alt war. Es war ein massiver Prozess, die Daten über Pre-Prod hinweg zu pflegen, aber er wurde als wesentlich für die Unternehmen angesehen, für die ich gearbeitet habe und die Pre-Prod implementiert haben.

In der AU-Bankenabteilung verhängt die Regierung gegen Banken eine Geldstrafe wegen Dienstausfalls, z. B. Geldautomaten auf Websites usw., die jede Minute ausgefallen sind. Es ist nicht ungewöhnlich, von einem Entwicklungs- / Testteam zu hören, das wegen eines Vorfalls entlassen wurde. Pre-Prod ist nicht für jedes Unternehmen oder jeden Entwicklungsprozess geeignet, aber für einige unerlässlich.

— Nickz
quelle

3

"Es ist nicht ungewöhnlich, von einem Entwicklungs- / Testteam zu hören, das wegen eines Vorfalls gefeuert wurde" - ja, das wird helfen. Die Schläge werden fortgesetzt, bis sich die Moral verbessert.

— Malvolio