Was ist der Hauptzweck und der Sinn für den Staging -Server wie die Produktion?

Question

In unserem Unternehmen haben wir Staging- und Produktionsserver. Ich versuche sie nach der letzten Veröffentlichung im Zustand 1: 1 zu haben. Wir werden auf mehreren Hosts und vielen Fällen eine Webanwendung ausgeführt.

Das Problem ist, dass ich ein Befürworter der gleichen Architektur (Struktur) von Webanwendungen für Staging- und Produktionsserver bin, um neue Funktionen problemlos zu testen und neue Fehler mit neuen Releases zu erstellen.

Aber nicht jeder stimmt mir zu, und für sie ist es keine so große Sache, eine andere Verbindung zwischen Staging -Anwendungsinstanzen zu haben. Auch vielleicht mehr Anwendung und Verbindungen zwischen Anwendung auf der Inszenierung als auf dem Produktionsserver.

Ich möchte nach Vor- und Nachteilen eines solchen Ansatzes fragen? Ich meine ein paar gute Punkte, die mir zustimmen, oder etwas schlechtes, warum ich vielleicht nicht das Recht habe. Einige Beispiele für Konsequenzen und so weiter.

Answer 1

Wenn sich Ihr Staging -Server erheblich von Ihrem Produktionsserver unterscheidet, ist die erfolgreiche Bereitstellung und Prüfung auf dem Staging -Server dies tun nicht Erzählen Sie Ihnen viel darüber, ob die Welt bei Ihnen abstürzt, wenn Sie sich endlich auf dem Produktionsserver bereitstellen.

Ich sehe keinen wirklichen Vorteil für die bevorzugte chaotische Situation Ihrer Kollegen, um diesen offensichtlichen Nachteil auszugleichen. Was behaupten sie, dass sie gewinnen, indem sie die Konfiguration des Staging -Servers vollständig mit dem des Produktionsservers synchronisieren ...?!

Answer 2

Inszenierung ist wie die Drehprobe des Einsatzes. Wenn Sie nicht das gleiche Kostüm tragen, das Sie in der Nacht tragen werden, woher wissen Sie, dass es passen wird, oder Sie werden nicht über die verwirrenden Teile stolpern.

Formaler versuchen Sie, die Staging -Umgebung so nah wie möglich an der Produktionsumgebung zu halten, um Unterschiede zu minimieren, die Probleme im Einsatz verursachen oder ausblenden können. Beachten Sie, dass ich "nah wie möglich" sage, da es nicht immer möglich ist, dasselbe Modell der Festplatte oder dasselbe Netzwerkverbindungen zu haben, aber Sie versuchen, die Dinge zu minimieren, die Sie in den verfügbaren Ressourcen können.

Answer 3

Martin Fowler Kürzlich gebloggt über identische Umgebungen, die von einem zum anderen geschnitten werden könnten, also Ihre Staging -Umgebung wird Ihre Produktionsumgebung nach dem Test. Er sagt:

Eine der Herausforderungen bei der Automatisierung der Bereitstellung ist die Ausschnitte selbst, die Software von der Endphase des Tests bis zur Live-Produktion übernimmt. Sie müssen dies normalerweise schnell tun, um Ausfallzeiten zu minimieren. Der Blue-Green-Bereitstellungsansatz ermöglicht dies, indem Sie sicherstellen, dass Sie zwei Produktionsumgebungen haben, die so identisch wie möglich sind. Sagen wir zu jeder Zeit, wenn einer von ihnen für das Beispiel blau ist, live. Wenn Sie eine neue Version Ihrer Software vorbereiten, führen Sie Ihre endgültige Testphase in der grünen Umgebung durch. Sobald die Software in der grünen Umgebung arbeitet, wechseln Sie den Router so, dass alle eingehenden Anfragen in die grüne Umgebung gehen - der blaue ist jetzt untätig.

Ich denke, ein solcher Ansatz wäre eine großartige Alternative zu der scheinbar chaotischen Umgebung, die Sie heute haben. Viel Glück, Ihr Team zu überzeugen!

Answer 4

Ich würde auch mit dem "so nah wie möglich" -Ansatz gehen, wie Ptomli vorschlug ... und das ist hauptsächlich auf den Kostenfaktor zurückzuführen. Wenn es sich um eine Farm handelt, die 5 Server enthält, würde ich nie empfehlen, dass die Inszenierung nur 1 als Standerver -Server beträgt. Dies hilft in Szenarien, in denen auch Netzwerkschicht beteiligt ist. Wenn es Patches gibt, die sich aus irgendeinem Grund (wie Sicherheit!) Die Netzwerkkonnektivität auswirken, spiegelt ein einzelner Box -Staging -Server möglicherweise nicht den "realen Affekt" des Patching wider.