Како да поставите staging околина за вашата апликација

За да поставите staging околина, распоредете втора копија на апликацијата на своја приватна URL адреса, дајте ѝ своја база и тест API клучеви и направете ја што е можно поблиску до поставките на продукцијата. Потоа објавувајте секоја значајна промена прво на staging, поминете низ важните текови и објавете во продукција само кога staging изгледа добро.

Ако сте нови во идејата, што е staging околина ја објаснува концептот. Овој водич е практичното поставување, напишано за луѓе што градат со AI алатки, а не за DevOps тим.

Dev, staging и продукција

Во повеќето мали апликации се потребни три места, дури и ако првото е само прегледот на вашиот градител:

Смислата на staging е да се однесува како продукцијата — ист код, ист стек, истиот вид поставки — но грешката таму никому не му штети.

Чекор 1: Одлучете што staging мора да совпаѓа

Staging е корисен само ако проблемите се појават таму пред да се појават во продукција. Совпаѓајте:

• Истиот код, објавен на ист начин.
• Истиот стек и верзии — рамка, runtime, тип на база.
• Ист вид конфигурација — истите имиња на променливи на околината, со тест вредности.
• Истите сервиси — ако продукцијата има веб апликација и API, staging ги има и двете.

Може да се разликува по големина (помала машина е во ред) и по податоци.

Чекор 2: Создајте ја копијата

Najедноставниот пристап: втора распоредба на истиот проект, на различна URL адреса, како staging.yourapp.com или yourapp-staging.example.com.

Како ќе го направите тоа зависи од вашиот хост:

• Хостови со вградени preview или staging распоредби можат автоматски да создадат една за гранка од Git.
• Хостови без тоа: создадете втора апликација или проект од истиот код и распоредете ја одделно.
• Код во Git: чувајте гранка staging или main што се распоредува на staging, а во продукција распоредувајте од издание. Видете како да користите Git со апликација изградена со AI.

Чекор 3: Дајте му на staging своја база

Ова е чекорот што ве штити. Ако staging и продукцијата делат иста база, тест што брише записи брише вистински записи.

• Создајте посебна база за staging.
• Наполнете ја со seed податоци — реалистични лажни записи што AI може да ви ги генерира.
• Ако ви треба копија од продукциските податоци, отстранете или измешајте имиња, е-пошти и сè лично однапред.

Напиши seed скрипта што ја полни празната база со реалистични тест податоци: 20 клиенти, 50 нарачки во различни состојби и два администраторски корисници. Користи очигледно лажни имиња и адреси на example.com.

Пред да му верувате на поставувањето, потврдете со која база се поврзува секоја копија. Прашајте директно:

Со која база се поврзува оваа апликација и од каде доаѓа таа поставка? Покажи ми го името на променливата, не лозинката.

Чекор 4: Користете тест клучеви и посебни поставки

Секое нешто што комуницира со надворешна услуга треба да користи тест акредитиви на staging:

• Плаќањата во тест-режим (на пример тест клучеви на Stripe), за да не се наплати вистинска картичка.
• Е-пошта испратена до sandbox или само до ваша адреса, за клиентите никогаш да не добијат тест порака.
• AI и други платени API-и со посебен клуч и ниска граница на потрошувачка.
• Webhook-ови насочени кон staging URL, не кон продукција.

Чувајте ги истите имиња на променливи во двете околини и менувајте само вредностите. Така кодот не мора да знае каде се извршува. За повеќе, видете како да ги чувате API клучевите безбедни.

Чекор 5: Чувајте го staging приватен

Staging не треба да е јавен:

• Ставете го зад најава, лозинка или листа на дозволени тимски адреси.
• Спречете пребарувачите да го индексираат со noindex meta ознака или X-Robots-Tag заглавие.
• Не линкувајте до него од вашиот јавен сајт.
• Направете го да изгледа поинаку — обоена лента „STAGING“ спречува тестирање во погрешен таб.

Додај жолта лента на врвот од секоја страница со текст „STAGING — само тест податоци“ кога променливата APP_ENV на околината е „staging“. Во тој случај додај и noindex meta ознака.

Чекор 6: Создајте рутина за објавување

Staging помага само ако го користите секогаш. Едноставна рутина:

1. Направете ја промената во development и проверете ја во прегледот.
2. Објавете ја на staging.
3. Поминете низ главните текови: регистрација, најава, главната функција, плаќања, што било што промената го допира.
4. Ако нешто се расипе, поправете и повторно објавете на staging.
5. Објавете ја истата верзија во продукција.
6. Брзо проверете ја продукцијата — истите текови, накратко.

Запишете ги главните текови како кратка тест скрипта. Видете како да ја тестирате апликацијата пред лансирање за тоа што да се вклучи.

Чекор 7: Внимавајте на промените во базата

Промените во структурата на базата — додавање колона, преименување табела — се местото каде staging се исплаќа.

• Прво изведете ја секоја структурна промена на staging.
• Проверете дека постоечките податоци преживеале, не само дека новите функции работат.
• Направете резервна копија од продукцијата пред да ја извршите истата промена таму. Видете како да направите резервна копија од базата на апликацијата.
• Претпочитајте промени што додаваат наместо да преименуваат или бришат, за стариот вид да работи ако се вратите назад.

Примери на промпти

Објасни што би се случило со постоечките податоци ако ја извршиме оваа промена на базата на продукција. Се брише или преименува нешто?

Направи сите поставки специфични за околината — URL адреси на API, клучеви, испраќач на е-пошта, URL на самиот сајт — да доаѓаат од променливи на околината со исти имиња во staging и продукција. Наведи ги.

Напиши кратка листа за проверка на текови што треба да ги тестирам на staging пред секое издание, врз основа на тоа што ја прави оваа апликација.

Чести грешки

• Споделена база. Најштетната грешка. Staging секогаш добива своја.
• Живи клучеви на staging. Вистински наплати, вистински е-пошти до вистински клиенти.
• Staging се разминува со продукцијата. Различни верзии или поставки значат дека staging престанува да фаќа проблеми.
• Јавен, индексиран staging сајт што се појавува во резултатите од пребарување до вашиот вистински.
• Прескокнување на staging за „мали“ промени. Мали промени исто така расипуваат работи.
• Тестирање во погрешен таб. Видлива лента го решава тоа.

Список за проверка

• Staging го извршува истиот код, стек и услуги како продукцијата.
• Staging има своја база со тест или очистени податоци.
• Плаќањата, е-поштата и платените API-и користат тест клучеви на staging.
• Имињата на променливите се совпаѓаат во двете околини; се разликуваат само вредностите.
• Staging е зад најава или лозинка и не е индексиран.
• Се прикажува лента кога сте на staging.
• Секое издание оди прво на staging, со напишана листа на текови за проверка.
• Промените во базата прво се изведуваат на staging, со резервна копија од продукцијата пред објавувањето.

Staging на Mythex

Мythex Publish дава по една жива URL адреса за секоја апликација; нема посебен staging прекинувач. Во пракса имате две опции:

• Преглед како предобјавна проверка. Секој проект работи во приватна облачна работна околина со жив Preview. /test ја натера агентот да ја кликне околината како корисник, а линк Share му овозможува на клиент или на член од тимот да го прегледа Preview без да го објави. Видете Preview и код. Ова е доволно за многу самостојни проекти.
• Втор проект како staging. На Pro, извезете го проектот и увезете го во нов проект, дајте му своја база и тајни со тест клучеви и објавете го на свој slug. Објавете на него пред да го објавите продукцискиот проект.

Во секој случај, прашајте го агентот со која база се поврзуваат Preview и објавената апликација пред да тестирате нешто деструктивно, и користете checkpoint-и за да се вратите назад ако промената е лоша. За поширокото објавување апликација во живот, видете како да го однесете AI прототип во продукција.

Прашања