Com configurar un entorn de staging per a la teva app

Per configurar un entorn de staging, desplega una segona còpia de la teva app a la seva pròpia URL privada, dona-li la seva pròpia base de dades i claus d'API de prova, i fes que coincideixi el màxim possible amb la configuració de producció. Després, publica tots els canvis importants primer al staging, repassa els fluxos importants i només publica a producció quan el staging es vegi bé.

Si és la primera vegada que sents aquesta idea, què és un entorn de staging n'explica el concepte. Aquesta guia és la configuració pràctica, pensada per a persones que construeixen amb eines d'IA i no gestionen un equip de DevOps.

Desenvolupament, staging i producció

La majoria d'apps petites necessiten tres entorns, encara que el primer sigui només la previsualització del teu constructor:

La idea del staging és que es comporti com la producció (mateix codi, mateixa pila, mateix tipus de configuració), però que un error allà no perjudiqui ningú.

Pas 1: decideix què ha de coincidir amb el staging

El staging només és útil si els problemes apareixen allà abans que a producció. Ha de coincidir en:

• El mateix codi, publicat de la mateixa manera.
• La mateixa pila i versions: framework, entorn d'execució, tipus de base de dades.
• El mateix tipus de configuració: els mateixos noms de variables d'entorn, amb valors de prova.
• Els mateixos serveis: si producció té una app web i una API, el staging en té totes dues.

Pot diferir en mida (una màquina més petita està bé) i en les dades.

Pas 2: crea la còpia

La manera més senzilla: un segon desplegament del mateix projecte, en una URL diferent com staging.elteuapp.com o elteuapp-staging.example.com.

Com ho facis depèn del teu allotjament:

• Els allotjaments amb desplegaments de previsualització o staging integrats en poden crear un automàticament per a una branca de Git.
• Els allotjaments sense aquesta funció: crea una segona app o projecte a partir del mateix codi, i desplega-la per separat.
• Codi a Git: mantén una branca staging o main que es desplegui al staging, i desplega a producció des d'una versió publicada. Consulta com fer servir Git amb una app creada amb IA.

Pas 3: dona al staging la seva pròpia base de dades

Aquest és el pas que et protegeix. Si el staging i la producció comparteixen base de dades, un test que esborri registres esborra registres reals.

• Crea una base de dades separada per al staging.
• Omple-la amb dades de seed: registres falsos però realistes que l'IA pot generar per a tu.
• Si necessites una còpia de les dades de producció, elimina o barreja abans els noms, els correus i qualsevol dada personal.

Escriu un script de seed que ompli una base de dades buida amb dades de prova realistes: 20 clients, 50 comandes en diferents estats i dos usuaris administradors. Fes servir noms obviament falsos i adreces de correu de example.com.

Abans de confiar en la configuració, confirma a quina base de dades es connecta cada còpia. Pregunta-ho directament:

A quina base de dades es connecta aquesta app, i d'on surt aquesta configuració? Mostra'm el nom de la variable, no la contrasenya.

Pas 4: fes servir claus de prova i configuració separada

Tot allò que es comunica amb un servei extern hauria d'usar credencials de prova al staging:

• Pagaments en mode de prova (per exemple, claus de prova de Stripe), perquè no es cobri cap targeta real.
• Correu enviat a un sandbox o només a la teva pròpia adreça, perquè els clients mai no rebin un missatge de prova.
• IA i altres APIs de pagament amb una clau separada i un límit de despesa baix.
• Webhooks apuntant a la URL de staging, no a la de producció.

Mantén els noms de les variables iguals en tots dos entorns i canvia només els valors. Així el codi no necessita saber on s'executa. Per a més informació, consulta com mantenir segures les claus d'API.

Pas 5: mantén el staging privat

El staging no hauria de ser públic:

• Posa'l darrere d'un inici de sessió, una contrasenya o una llista de correus de l'equip permesos.
• Evita que els motors de cerca l'indexin amb una metaetiqueta noindex o una capçalera X-Robots-Tag.
• No l'enllacis des del teu lloc públic.
• Fes que es vegi diferent: una franja de color amb "STAGING" evita provar a la pestanya equivocada.

Afegeix una franja groga cridanera a la part superior de cada pàgina amb el text "STAGING: només dades de prova" quan la variable d'entorn APP_ENV sigui "staging". En aquest cas, afegeix també una metaetiqueta noindex.

Pas 6: estableix una rutina de publicació

El staging només ajuda si l'uses sempre. Una rutina senzilla:

1. Fes el canvi en desenvolupament i comprova'l a la previsualització.
2. Publica'l al staging.
3. Repassa els fluxos clau: registre, inici de sessió, la funcionalitat principal, pagaments, qualsevol cosa que el canvi hagi tocat.
4. Si alguna cosa falla, arregla-ho i torna a publicar al staging.
5. Publica la mateixa versió a producció.
6. Comprova ràpidament producció: els mateixos fluxos, breument.

Anota els fluxos clau en un petit script de prova. Consulta com provar la teva app abans del llançament per saber què incloure.

Pas 7: gestiona amb cura els canvis a la base de dades

Els canvis a l'estructura de la base de dades (afegir una columna, canviar el nom d'una taula) són on el staging es guanya el seu lloc.

• Executa primer tots els canvis d'estructura al staging.
• Comprova que les dades existents han sobreviscut, no només que les funcionalitats noves funcionen.
• Fes una còpia de seguretat de producció abans d'executar el mateix canvi allà. Consulta com fer una còpia de seguretat de la base de dades de la teva app.
• Prefereix canvis que afegeixin en lloc de canviar el nom o esborrar, així la versió antiga continua funcionant si cal tornar enrere.

Exemples de prompts

Explica què passaria amb les dades existents si executéssim aquest canvi de base de dades a producció. S'esborra o es canvia el nom d'alguna cosa?

Fes que totes les configuracions específiques de cada entorn (URL d'API, claus, remitent de correu, la URL del propi lloc) vinguin de variables d'entorn amb els mateixos noms al staging i a producció. Enumera-les.

Escriu una llista de verificació breu dels fluxos que he de provar al staging abans de cada publicació, segons el que fa aquesta app.

Errors habituals

• Base de dades compartida. L'error més perjudicial. El staging sempre ha de tenir la seva.
• Claus reals al staging. Cobraments reals, correus reals a clients reals.
• El staging es desvia de producció. Versions o configuracions diferents fan que el staging deixi de detectar problemes.
• Un staging públic i indexat que apareix als resultats de cerca al costat del teu lloc real.
• Saltar-se el staging pels canvis "petits". Els canvis petits també trenquen coses.
• Provar a la pestanya equivocada. Una franja visible ho soluciona.

Llista de verificació

• El staging executa el mateix codi, pila i serveis que producció.
• El staging té una base de dades pròpia amb dades de prova o depurades.
• Pagaments, correu i APIs de pagament fan servir claus de prova al staging.
• Els noms de les variables coincideixen entre entorns; només canvien els valors.
• El staging està darrere d'un inici de sessió o contrasenya i no s'indexa.
• Una franja es mostra quan estàs al staging.
• Cada publicació passa primer pel staging, amb una llista escrita dels fluxos a comprovar.
• Els canvis de base de dades s'executen primer al staging, amb una còpia de seguretat de producció abans de publicar.

Staging a Mythex

La funció Publicar de Mythex et dona una URL en directe per app; no hi ha un interruptor de staging separat. A la pràctica tens dues opcions:

• La previsualització com a comprovació prèvia a la publicació. Cada projecte s'executa en un espai de treball privat al núvol amb una previsualització en directe. /test fa que l'agent la recorri com si fos un usuari, i un enllaç Compartir permet que un client o un company revisi la previsualització sense publicar-la. Consulta Previsualització i codi. Per a molts projectes en solitari, això n'hi ha prou.
• Un segon projecte com a staging. Al Pro, exporta el projecte i importa'l en un projecte nou, dona a aquest projecte la seva pròpia base de dades i secrets amb claus de prova, i publica'l amb el seu propi slug. Publica-hi abans de publicar el projecte de producció.

En qualsevol cas, pregunta a l'agent quina base de dades fan servir la previsualització i l'app publicada abans de provar res que sigui destructiu, i fes servir punts de control per tornar enrere davant d'un canvi dolent. Per a la posada en producció d'una app en general, consulta com portar un prototip d'IA a producció.

Preguntes