Jak nastavit staging prostředí pro vaši aplikaci

Chcete-li nastavit staging prostředí, nasaďte druhou kopii aplikace na vlastní soukromou URL, dejte jí vlastní databázi a testovací API klíče a nastavte ji co nejblíže produkci. Každou významnou změnu pak nejdřív nasadíte na staging, projdete důležité postupy a na produkci publikujete až ve chvíli, kdy staging vypadá správně.

Pokud je pro vás tento pojem nový, vysvětluje ho článek co je staging prostředí. Tento průvodce je praktické nastavení psané pro lidi, kteří staví s nástroji AI, a ne pro tým DevOps.

Vývoj, staging a produkce

Většina malých aplikací potřebuje tři místa, i když první z nich je jen náhled v nástroji, ve kterém stavíte:

Smysl stagingu je, aby se choval jako produkce — stejný kód, stejný stack, stejný typ nastavení — ale chyba v něm nikomu neublíží.

Krok 1: Rozhodněte, co musí staging odpovídat

Staging je užitečný jen tehdy, když se problémy projeví tam dřív, než v produkci. Měl by odpovídat v těchto oblastech:

• Stejný kód, nasazovaný stejným způsobem.
• Stejný stack a verze — framework, runtime, typ databáze.
• Stejný typ konfigurace — stejné názvy proměnných prostředí, s testovacími hodnotami.
• Stejné služby — pokud má produkce webovou aplikaci i API, má je mít i staging.

Může se lišit velikostí (menší stroj je v pořádku) a daty.

Krok 2: Vytvořte kopii

Nejjednodušší přístup: druhé nasazení stejného projektu na jiné URL, například staging.yourapp.com nebo yourapp-staging.example.com.

Jak to uděláte, závisí na vašem hostingu:

• Hostingy s vestavěnými náhledovými nebo stagingovými nasazeními mohou jedno vytvořit automaticky pro větev v Gitu.
• Hostingy bez toho: vytvořte druhou aplikaci nebo projekt ze stejného kódu a nasaďte ji zvlášť.
• Kód v Gitu: udržujte větev staging nebo main, která se nasazuje na staging, a produkci nasazujte z vydání. Viz jak používat Git s aplikací postavenou pomocí AI.

Krok 3: Dejte stagingu vlastní databázi

Tento krok vás chrání nejvíc. Pokud staging a produkce sdílejí databázi, test, který maže záznamy, smaže skutečné záznamy.

• Vytvořte pro staging samostatnou databázi.
• Naplňte ji seed daty — realistickými falešnými záznamy, které vám může vygenerovat AI.
• Potřebujete-li kopii produkčních dat, nejdřív odstraňte nebo zamíchejte jména, e-maily a cokoli osobního.

Napiš seed skript, který naplní prázdnou databázi realistickými testovacími daty: 20 zákazníků, 50 objednávek v různých stavech a dva administrátorské uživatele. Používej zjevně falešná jména a e-mailové adresy na example.com.

Než nastavení začnete věřit, ověřte, ke které databázi se každá kopie připojuje. Zeptejte se přímo:

K jaké databázi se tato aplikace připojuje a odkud pochází toto nastavení? Ukaž mi název proměnné, ne heslo.

Krok 4: Používejte testovací klíče a oddělená nastavení

Všechno, co komunikuje s externí službou, by na stagingu mělo používat testovací přihlašovací údaje:

• Platby v testovacím režimu (například testovací klíče Stripe), aby se neúčtovala žádná skutečná karta.
• E-maily odesílané do sandboxu nebo jen na vaši vlastní adresu, aby zákazníci nikdy nedostali testovací zprávu.
• AI a další placená API s odděleným klíčem a nízkým limitem výdajů.
• Webhooky nasměrované na staging URL, ne na produkci.

Názvy proměnných udržujte v obou prostředích stejné a měňte jen hodnoty. Kód pak nemusí vědět, kde běží. Více k tomu viz jak chránit API klíče.

Krok 5: Držte staging v soukromí

Staging by neměl být veřejný:

• Zakryjte ho přihlášením, heslem nebo seznamem povolených e-mailů týmu.
• Zabraňte indexování vyhledávači značkou noindex v meta tagu nebo hlavičkou X-Robots-Tag.
• Neodkazujte na něj z veřejného webu.
• Ať vypadá jinak — barevný banner „STAGING“ zabrání testování ve špatné záložce.

Přidej výrazný žlutý banner nahoře na každé stránce s textem „STAGING — pouze testovací data“, když je proměnná prostředí APP_ENV nastavena na „staging“. V tom případě také přidej meta tag noindex.

Krok 6: Zaveďte rutinu vydávání

Staging pomáhá jen tehdy, když ho používáte pokaždé. Jednoduchá rutina:

1. Proveďte změnu ve vývoji a ověřte ji v náhledu.
2. Vydejte ji na staging.
3. Projděte klíčové postupy: registrace, přihlášení, hlavní funkce, platby, cokoli, čeho se změna dotkla.
4. Pokud se něco rozbije, opravte to a znovu vydejte na staging.
5. Stejnou verzi publikujte na produkci.
6. Rychle zkontrolujte produkci — stejné postupy, stručně.

Klíčové postupy si zapište jako krátký testovací scénář. Co zahrnout, viz jak otestovat aplikaci před spuštěním.

Krok 7: Měňte databázi opatrně

Změny struktury databáze — přidání sloupce, přejmenování tabulky — jsou místo, kde se staging vyplatí nejvíc.

• Každou strukturální změnu nejdřív spusťte na stagingu.
• Ověřte, že existující data přežila, ne jen že fungují nové funkce.
• Před spuštěním stejné změny na produkci si udělejte zálohu produkce. Viz jak zálohovat databázi aplikace.
• Dávejte přednost změnám, které přidávají, před těmi, které přejmenovávají nebo mažou, aby stará verze fungovala i po návratu zpět.

Příklady promptů

Vysvětli, co by se stalo s existujícími daty, kdybychom tuto změnu databáze spustili na produkci. Něco se maže nebo přejmenovává?

Ať všechna nastavení specifická pro prostředí — URL API, klíče, odesílatel e-mailů, vlastní URL webu — berou z proměnných prostředí se stejnými názvy na stagingu i na produkci. Vypiš je.

Napiš krátký kontrolní seznam postupů, které mám otestovat na stagingu před každým vydáním, podle toho, co tato aplikace dělá.

Časté chyby

• Sdílená databáze. Nejničivější chyba. Staging vždy dostane vlastní.
• Ostré klíče na stagingu. Skutečné platby, skutečné e-maily skutečným zákazníkům.
• Staging se rozchází s produkcí. Různé verze nebo nastavení znamenají, že staging přestane odhalovat problémy.
• Veřejný, indexovaný staging web, který se objeví ve výsledcích hledání vedle vašeho skutečného webu.
• Přeskakování stagingu u „malých“ změn. I malé změny něco rozbijí.
• Testování ve špatné záložce. Viditelný banner to vyřeší.

Kontrolní seznam

• Staging běží na stejném kódu, stacku a službách jako produkce.
• Staging má vlastní databázi s testovacími nebo očištěnými daty.
• Platby, e-maily a placená API na stagingu používají testovací klíče.
• Názvy proměnných se shodují napříč prostředími; liší se jen hodnoty.
• Staging je za přihlášením nebo heslem a není indexován.
• Když jste na stagingu, zobrazí se banner.
• Každé vydání jde nejdřív na staging, se sepsaným seznamem postupů ke kontrole.
• Změny databáze se nejdřív spouštějí na stagingu se zálohou produkce před vydáním.

Staging na Mythexu

Funkce Publish v Mythexu dává každé aplikaci jednu živou URL; žádný samostatný přepínač pro staging tu není. V praxi máte dvě možnosti:

• Náhled jako kontrola před vydáním. Každý projekt běží v soukromém cloudovém pracovním prostoru s živým Náhledem. /test nechá agenta proklikat ho jako uživatele a odkaz Sdílet umožní klientovi nebo členovi týmu zkontrolovat náhled bez publikování. Viz Náhled a kód. Pro mnoho samostatných projektů to stačí.
• Druhý projekt jako staging. Na tarifu Pro exportujte projekt a importujte ho do nového projektu, dejte mu vlastní databázi a testovací tajné údaje a publikujte ho na vlastním slugu. Před publikováním produkčního projektu na něj vydávejte.

V obou případech se agenta před jakoukoli destruktivní akcí zeptejte, kterou databázi používá náhled a publikovaná aplikace, a k vrácení špatné změny použijte checkpointy. Pro obecnější spuštění aplikace živě viz jak dostat AI prototyp do produkce.

Otázky