Jak skonfigurować środowisko staging dla aplikacji

Aby skonfigurować środowisko staging, wdróż drugą kopię aplikacji pod jej własnym prywatnym adresem URL, daj jej własną bazę danych i klucze API testowe oraz ustaw ją tak blisko produkcji, jak to możliwe. Następnie każdą istotną zmianę wypuszczaj najpierw na staging, przejdź przez najważniejsze procesy i publikuj na produkcję dopiero wtedy, gdy staging wygląda dobrze.

Jeśli dopiero poznajesz ten koncept, czym jest środowisko staging wyjaśnia pojęcie. Ten przewodnik to praktyczna konfiguracja, pisana dla osób budujących przy pomocy narzędzi AI, a nie dla zespołów DevOps.

Development, staging i produkcja

Większość małych aplikacji potrzebuje trzech miejsc, nawet jeśli pierwsze to tylko podgląd w narzędziu do budowania:

Sens stagingu polega na tym, że zachowuje się jak produkcja — ten sam kod, ten sam stack, podobne ustawienia — ale błąd tam nikomu nie szkodzi.

Krok 1: Ustal, co staging musi odwzorowywać

Staging jest użyteczny tylko wtedy, gdy problemy wychodzą na jaw tam, zanim pojawią się na produkcji. Odwzoruj:

• Ten sam kod, wydawany w ten sam sposób.
• Ten sam stack i te same wersje — framework, runtime, typ bazy danych.
• Ten sam rodzaj konfiguracji — te same nazwy zmiennych środowiskowych, z wartościami testowymi.
• Te same usługi — jeśli produkcja ma aplikację webową i API, staging też ma oba.

Może się różnić rozmiarem (mniejsza maszyna jest w porządku) i danymi.

Krok 2: Utwórz kopię

Najprostsze podejście: drugie wdrożenie tego samego projektu pod innym adresem, na przykład staging.twojaapp.com albo twojaapp-staging.example.com.

Jak to zrobić, zależy od hosta:

• Hosty z wbudowanymi wdrożeniami podglądowymi lub stagingowymi mogą utworzyć je automatycznie dla gałęzi Git.
• Hosty bez tego: utwórz drugą aplikację lub projekt z tego samego kodu i wdróż go osobno.
• Kod w Git: utrzymuj gałąź staging lub main, która wdraża na staging, a wdrożenie na produkcję rób z wydania. Zobacz jak używać Git z aplikacją zbudowaną przez AI.

Krok 3: Daj stagingowi własną bazę danych

To ten krok Cię chroni. Jeśli staging i produkcja współdzielą bazę, test, który usuwa rekordy, usuwa prawdziwe rekordy.

• Utwórz osobną bazę danych dla stagingu.
• Wypełnij ją danymi seed — realistycznymi, fałszywymi rekordami, które AI może wygenerować za Ciebie.
• Jeśli potrzebujesz kopii danych produkcyjnych, najpierw usuń lub zaciemnij imiona, e-maile i wszystko, co osobiste.

Napisz skrypt seed, który wypełni pustą bazę realistycznymi danymi testowymi: 20 klientów, 50 zamówień w różnych stanach i dwóch użytkowników administracyjnych. Używaj oczywiście fałszywych imion i adresów e-mail na domenie example.com.

Zanim zaufasz konfiguracji, sprawdź, z jaką bazą łączy się każda kopia. Zapytaj wprost:

Z którą bazą danych łączy się ta aplikacja i skąd pochodzi to ustawienie? Pokaż mi nazwę zmiennej, a nie hasło.

Krok 4: Używaj kluczy testowych i osobnych ustawień

Wszystko, co komunikuje się z zewnętrzną usługą, powinno w stagingu używać danych testowych:

• Płatności w trybie testowym (na przykład klucze testowe Stripe), żeby nikomu nie obciążać prawdziwej karty.
• E-maile wysyłane do sandboksa albo tylko na Twój własny adres, aby klienci nigdy nie dostali wiadomości testowej.
• AI i inne płatne API z osobnym kluczem i niskim limitem wydatków.
• Webhooks wskazujące na adres stagingu, nie produkcji.

Nazwy zmiennych trzymaj takie same w obu środowiskach i zmieniaj tylko wartości. Dzięki temu kod nie musi wiedzieć, gdzie działa. Więcej na ten temat znajdziesz w jak chronić klucze API.

Krok 5: Trzymaj staging prywatnie

Staging nie powinien być publiczny:

• Zabezpiecz go logowaniem, hasłem albo listą dozwolonych adresów e-mail zespołu.
• Nie pozwól wyszukiwarkom go indeksować, używając tagu noindex lub nagłówka X-Robots-Tag.
• Nie linkuj do niego z publicznej strony.
• Wyglądaj inaczej — kolorowy baner „STAGING” zapobiega testowaniu w złej karcie.

Dodaj jasnożółty baner na górze każdej strony z napisem „STAGING — tylko dane testowe”, gdy zmienna APP_ENV ma wartość „staging”. W takim przypadku dodaj też tag noindex.

Krok 6: Ustal rutynę wydań

Staging pomaga tylko wtedy, gdy używasz go za każdym razem. Prosta rutyna:

1. Wprowadź zmianę w developmencie i sprawdź ją w podglądzie.
2. Wydaj ją na staging.
3. Przejdź przez kluczowe procesy: rejestracja, logowanie, główna funkcja, płatności, wszystko, czego zmiana dotknęła.
4. Jeśli coś się zepsuło, napraw to i wydaj ponownie na staging.
5. Opublikuj tę samą wersję na produkcji.
6. Szybko sprawdź produkcję — te same procesy, krótko.

Zapisz kluczowe procesy jako krótki skrypt testowy. Zobacz jak przetestować aplikację przed startem, co powinno się w nim znaleźć.

Krok 7: Ostrożnie zmieniaj bazę danych

Zmiany w strukturze bazy — dodanie kolumny, zmiana nazwy tabeli — to miejsce, w którym staging zarabia na swoje.

• Każdą zmianę strukturalną uruchamiaj najpierw na stagingu.
• Sprawdź, czy istniejące dane przetrwały, a nie tylko to, czy nowe funkcje działają.
• Zrób kopię zapasową produkcji, zanim uruchomisz tę samą zmianę tam. Zobacz jak wykonać kopię zapasową bazy danych aplikacji.
• Preferuj zmiany, które dodają, a nie zmieniają nazwy lub usuwają, aby stara wersja nadal działała w razie cofnięcia.

Przykładowe prompty

Wyjaśnij, co by się stało z istniejącymi danymi, gdybyśmy uruchomili tę zmianę bazy na produkcji. Czy coś zostanie usunięte lub przemianowane?

Spraw, by wszystkie ustawienia zależne od środowiska — adresy URL API, klucze, nadawca e-maili, własny adres URL strony — pochodziły ze zmiennych środowiskowych o tych samych nazwach na stagingu i produkcji. Wypisz je.

Napisz krótką listę kontrolną procesów, które powinienem przetestować na stagingu przed każdym wydaniem, na podstawie tego, co robi ta aplikacja.

Częste błędy

• Wspólna baza danych. Najbardziej szkodliwy błąd. Staging zawsze dostaje własną.
• Klucze produkcyjne na stagingu. Prawdziwe obciążenia, prawdziwe e-maile do prawdziwych klientów.
• Staging rozjeżdża się z produkcją. Różne wersje lub ustawienia sprawiają, że staging przestaje wychwytywać problemy.
• Publiczna, indeksowana strona staging, która pojawia się w wynikach wyszukiwania obok prawdziwej.
• Pomijanie stagingu przy „drobnych” zmianach. Drobne zmiany też się psują.
• Testowanie w złej karcie. Widoczny baner to rozwiązuje.

Lista kontrolna

• Staging działa na tym samym kodzie, stacku i usługach co produkcja.
• Staging ma własną bazę danych z danymi testowymi lub zaciemnionymi.
• Płatności, e-mail i płatne API używają kluczy testowych na stagingu.
• Nazwy zmiennych są takie same w środowiskach; różnią się tylko wartości.
• Staging jest za logowaniem lub hasłem i nie jest indeksowany.
• Baner pokazuje się, gdy jesteś na stagingu.
• Każde wydanie trafia najpierw na staging, z pisemną listą procesów do sprawdzenia.
• Zmiany bazy uruchamiane najpierw na stagingu, z kopią zapasową produkcji przed wydaniem.

Staging w Mythex

Funkcja Publish w Mythex daje jeden żywy adres URL na aplikację; nie ma osobnego przełącznika stagingu. W praktyce masz dwie opcje:

• Podgląd jako kontrola przed wydaniem. Każdy projekt działa w prywatnym chmurowym środowisku roboczym z podglądem na żywo. /test pozwala agentowi przeklikać podgląd jak użytkownik, a link Share pozwala klientowi lub członkowi zespołu sprawdzić podgląd bez publikowania. Zobacz Preview i Code. Dla wielu samodzielnych projektów to wystarcza.
• Drugi projekt jako staging. W planie Pro wyeksportuj projekt i zaimportuj go do nowego projektu, nadaj mu własną bazę danych i sekrety z kluczami testowymi, a opublikuj go pod własnym slugiem. Wydawaj na niego przed publikacją projektu produkcyjnego.

W obu przypadkach zapytaj agenta, z której bazy danych korzystają podgląd i opublikowana aplikacja, zanim przetestujesz cokolwiek destrukcyjnego, i używaj checkpointów, by cofnąć złą zmianę. Szerzej o wprowadzaniu aplikacji na produkcję przeczytasz w jak przenieść prototyp AI na produkcję.

Pytania