Was ist eine Staging-Umgebung? Die Kopie, die nie ganz eine Kopie ist

Eine Staging-Umgebung ist eine laufende Kopie Ihrer Anwendung, so nah an der Produktion, wie Sie es sich leisten können, in der ein Release geprüft wird, bevor echte Menschen darauf treffen. Derselbe Code, dieselbe Form der Konfiguration, dieselbe Datenbankstruktur, andere Daten und ein anderes Publikum.

Die Idee ist alt und einfach: erst dort ausprobieren, wo es nicht darauf ankommt. Interessant wird sie dadurch, dass Staging nie wirklich eine Kopie ist, und jedes Problem, das es nicht abfängt, kommt aus dieser Lücke.

Wozwischen sie steht

Die meisten Teams landen bei drei oder vier Umgebungen, und die Unterschiede handeln davon, wer sie kaputt machen darf.

• Lokal ist der Rechner einer Entwicklerin. Er geht ständig kaputt, und niemanden stört es.
• Staging führt den Code aus, der gleich ausgeliefert wird, mit Daten, die niemand vermissen wird. Es geht gelegentlich kaputt, und jemanden stört es ein wenig.
• Produktion ist dort, wo die Kundinnen und Kunden sind.

Manche Teams fügen zwischen Staging und Produktion eine vierte für Last- oder Integrationstests hinzu, und manche stellen eine Preview-Umgebung pro Branch vor das Staging. Die Namen variieren stärker als die Ideen.

Wofür sie da ist

Abfangen, was eine Testsuite nicht kann. Migrationen gegen eine Datenbank mit echtem Volumen. Assets, die erst während eines Deploys kompiliert werden. Ein Konfigurationswert, den es auf der einen Maschine gibt und auf der anderen nicht. Nichts davon berührt ein Unit-Test.

Den Deploy selbst proben. Ein Release ist eine Prozedur, und die Prozedur hat auch Fehler. Wenn der Deploy nach Staging derselbe Befehl ist wie der Deploy in die Produktion, haben Sie das geübt, was sonst zum schlechtesten Zeitpunkt zum ersten Mal gemacht wird.

Nicht-Entwicklern einen Ort geben, an dem sie nachsehen können. Abnahmetests, eine Vorführung, ein Screenshot für den Support - alle brauchen etwas Echtes, das nicht echt ist.

Wie Staging abdriftet

Das ist der Teil, den man aufschreiben sollte, denn eine Staging-Umgebung, die niemand pflegt, ist schlimmer als keine: sie erzeugt Zuversicht statt Information.

Der Code driftet. Alles Gemergte geht automatisch nach Staging; die Produktion wird deployt, wenn jemand es entscheidet. Eine Staging-Umgebung dreißig Commits vor der Produktion erzählt Ihnen von Software, die Ihre Kunden nicht haben, und der Fehler, den Sie auf Staging nicht reproduzieren können, ist dort vielleicht schlicht schon behoben.

Die Daten driften. Die Produktion sammelt fünfzehn Jahre Entscheidungen an - Konten ohne E-Mail-Adresse, eine Bestellung aus der Zeit vor einer Spalte, ein Name mit einem Apostroph darin. Staging hat das, was die Seeds dort abgelegt haben. Die meisten Defekte, die Kunden erreichen, leben in Datenformen, an deren Anlage niemand gedacht hat.

Die Konfiguration driftet. Ein Schlüssel, der auf dem einen Host gesetzt ist und auf dem anderen nicht, ein Feature-Flag, das an einer Stelle eingeschaltet ist, ein Drittanbieterdienst, der auf eine Sandbox zeigt, die sich anders verhält als das Original. Das ist die Klasse von Problemen, für die Staging existiert, und die Klasse, die es am häufigsten selbst verursacht.

Der Maßstab driftet. Ein Webprozess gegen zwölf, eine Datenbank mit tausend Zeilen gegen zehn Millionen. Eine Abfrage, die auf Staging sofort antwortet, kann der Grund sein, aus dem die Produktion umfällt.

Die Lücke ehrlich halten

Sie können die Lücke nicht schließen, das Ziel ist also zu wissen, wo sie ist.

• Deployen Sie auf beide gleich. Ein Befehl, ein Skript, kein manueller Schritt, den es nur an einer Stelle gibt. Wenn die Produktion einen Schritt hat, den Staging nicht hat, wurde dieser Schritt nie getestet.
• Deployen Sie beide gemeinsam, wenn eine Änderung beide betrifft. Alles mit einem Client - eine Browser-Erweiterung, eine mobile App, eine Partner-Integration - das mit der einen Umgebung spricht und mit der anderen nicht, ist für die Person, die testet, in keiner von beiden live.
• Verwenden Sie produktionsförmige Daten, keine Produktionsdaten. Anonymisiert oder generiert, mit den unbequemen Formen bewusst darin: das leere Konto, die riesige Liste, der Apostroph. Echte Kundendaten in eine weniger geschützte Umgebung zu kopieren ist ein Datenschutzvorfall, der auf ein Datum wartet.
• Halten Sie sie gestoppt, wenn sie nicht gebraucht wird, und rechnen Sie damit, dass sie ein Ziel ist: Staging-Umgebungen sind dafür bekannt, schlechter gepatcht und offener zu sein als die Systeme, die sie spiegeln.
• Sagen Sie, was was ist. Ein Banner, eine Farbe, irgendetwas. Irgendwann macht jemand eine Vorführung auf der Produktion oder einen zerstörerischen Test auf dem falschen Host, und das zu verhindern kostet eine Zeile CSS.

Wenn Staging das eine sagt und die Produktion das andere

Das ist kein Versagen von Staging, es ist die Information, für die Staging da ist, und es ist der Moment herauszufinden, welche der vier Driften oben es erklärt.

Die erste Frage ist, welchen Build jede von beiden ausführt. Die zweite ist, ob dasselbe mit denselben Daten passiert. Beides gehört in einen Bericht, und beides fehlt regelmäßig in “auf Staging funktioniert es”.

Eine Aufnahme aus jeder Umgebung macht aus einem Streit einen Vergleich: dieselben Schritte, zwei Sätze Konsolenausgabe und Netzwerkprotokolle, und meistens ein offensichtlicher Unterschied. Der Leitfaden für Fehlerberichte hat den Rest von dem, was hineingehört, und die Umgebung zu benennen ist die Zeile, die Leute vergessen.

Die kurze Fassung

Staging ist eine Probe, keine Kopie. Sein Wert ist proportional dazu, wie ehrlich Sie die Arten nachhalten, auf die es sich von der Produktion unterscheidet - Code, Daten, Konfiguration und Maßstab - und ein Unterschied, von dem Sie wissen, ist eine Einschränkung, während einer, den Sie vergessen haben, ein falsch Negatives mit einem grünen Haken darauf ist.