Hvornår I har brug for et staging-miljø — og hvornår preview rækker

Et staging I ikke kan forklare, koster uger I kalder 'kvalitetssikring'. Folk merger, fordi det 'lå på staging', og opdager i produktion at webhooken pegede på det gamle URL, at Stripe-nøglen var test, eller at indholdet var tre måneder gammelt. I tror I har en gate. I har et ritual. Ritualet er dyrt, fordi det giver jer tilladelse til ikke at kigge.

Teams arver staging fra en anden slags software. I en bank, et ERP, et monolith med ét deploy-vindue om måneden, er et langt miljø før produktion en overlevelse. På et Next.js-site med preview på hver pull request er det ofte teater: I betaler for at holde et tredje site i live, som ingen redaktør åbner, og som udviklerne ikke stoler på. Preview løste det visuelle. Staging skal løse noget preview ikke kan.

Det er også et tillids- og data-spørgsmål. Hvis staging har produktionsdata, har I et andet produktionsmiljø, I ikke vogter. Hvis staging er tomt, fejler I først de queries, der kun dør med rigtige rækker. Hvis ingen ejer at opdatere det, divergerer det — og så er den grønne 'det virkede på staging' en løgn, I skriver i en ticket.

Vi skriver det, fordi 'vi skal have staging' er blevet et køb, I tager før I har en sætning om hvad preview ikke kan. Et ærligt setup er kedeligt: preview på hver gren, produktion som sandhed, og et tredje miljø kun når I kan pege på integrationen, dataformen eller redaktøren, der ikke kan leve i en PR-URL. Uden den sætning har I et ekstra hostname. I har ikke staging.

Et staging-miljø er et langt, delt sted, der skal svare som produktion på de måder, I faktisk er bange for. Samme slags database-shape. Samme slags auth. De samme webhooks, pegende på det her URL. Den samme betalings-sandbox. Et indhold, redaktører kan trykke igennem uden at røre live. Det behøver ikke at være en bit-kopi. Det skal være en kopi af de sandheder, der kan knække jer.

Det er ikke en preview. En preview dør med pull requesten. Den har branchens kode, ofte branchens migrationer, og typisk ikke jeres rigtige Stripe-webhook eller jeres ERP. Den er til at se og klikke, før I merger. Den er det rigtige værktøj til 'ser det her rigtigt ud' og 'bygger det'. Den er det forkerte værktøj til 'kan Nets finde tilbage' og 'kan redaktøren øve sig uden at publicere live'.

Det er heller ikke produktion med `noindex` og et andet hostname. At spejle live med rigtige kunder og rigtige hemmeligheder, og så kalde det staging, er hvordan I får et læk og et andet prod, I glemmer at patche. Staging må gerne ligne. Det må ikke være det samme værdifulde. Anonymiseret udsnit, sandbox-nøgler, et dataset I tør miste.

Og det er ikke docker-compose på én bærbar. Lokalt er til at udvikle. Staging er til at dele en sandhed med nogen, der ikke har jeres laptop: en anden udvikler, en redaktør, en betalingsleverandør, et migrationsvindue. Hvis kun én kan starte det, er det ikke et miljø. Det er et håb.

Den første fejl er at staging er forældet. Sidste rigtige deploy var i foråret. Schemaet ligner ikke prod. Feature-flags peger anderledes. I 'tester' et andet produkt. Det eneste staging så fanger, er at I kan logge ind på et site, I ikke lancerer. Opdater det i en rytme, eller drop det. Et museum er ikke en gate.

Den anden fejl er at staging har produktionsnøgler. Databasen er et dump fra i går. S3 er det rigtige bucket. Mailen sender til rigtige kunder, hvis nogen trykker. Det er ikke grundighed. Det er et andet prod uden den vagt, I har på det rigtige. Sandbox og anonymisering er kedelige. De er grunden til, at staging må eksistere.

Den tredje fejl er et tomt staging. Ingen rækker, ingen webhook, ingen redaktør-konto, ingen 'rigtig' integration — bare samme Next.js-build pegende på en tom Postgres. Så fanger I de fejl, et tomt site kan vise, og misser dem, der kun dør med data. Hvis jobbet er dataformen, så giv det data. Hvis jobbet er layout, så brug preview.

Den fjerde fejl er at bruge staging som dump. Alt, der ikke er reviewet, ligger der. Ingen preview. Ingen pull request. 'Det ligger på staging' betyder 'nogen pushede til en gren, vi deler'. Så har I slukket for review og tændt for et hotel. Preview-deploys er det, der holder review i live. Staging er det, der holder den delte sandhed. Bland dem, og I får ingen af delene.

Et marketing-site på Next.js med preview på hver pull request har typisk to sandheder: branchen I kigger på, og produktion. Redaktører, hvis I har dem, udgiver i prod eller via et CMS med eget preview. Et tredje miljø her er ofte et sted, I glemmer at sætte environment-variabler, og så 'virker det på staging' betyder 'det virkede uden de hemmeligheder, prod har'. Lad være. Brug preview. Hold prod kedelig.

Et WordPress-site er en anden slags. Indholdet er databasen. En preview af et tema-repo er ikke det samme som 'redaktøren kan trykke en forside af uden at ramme live'. Her kan et staging — en kopi af CMS'et med sandbox-nøgler og et noindex — være det rigtige, hvis I faktisk øver indhold og plugin-updates der. Det er stadig ikke en undskyldning for at kopiere rigtige brugere eller at lade staging være det sted, I opdager at pluginet sendte mailen.

En app med Stripe, webhooks eller et ERP har ofte det job, preview ikke kan: leverandøren kan kun pege ét sted, og I skal kunne gennemføre et køb eller en synk uden at røre live. Så er staging rigtigt. Så er sandbox-nøgler pligten. Så er 'vi pushede til staging og glemte at opdatere webhooken' den fejl, I skal designe jer ud af — ét dokumenteret URL, én ejer, én tjekliste før I kalder det testet.

En migrering — WordPress til Next.js, et schema-skift, et cutover — er den uge, staging tjener sit ophold. Tørkør på noget der ligner. Peg DNS midlertidigt hvis I skal. Skriv hvad der skal være sandt før I skifter. Preview af det nye site er stadig nyttigt. Det erstatter ikke at have kørt den kedelige kopi én gang, før kunderne gør det.