Қолданбаңызға staging ортасын қалай орнату керек

Staging ортасын орнату үшін қолданбаңыздың екінші көшірмесін өзінің жеке URL-іне орналастырыңыз, оған жеке дерекқор мен тест API кілттерін беріңіз және оны production баптауына мүмкіндігінше дәл келтіріңіз. Содан кейін әр маңызды өзгерісті алдымен staging-ке шығарыңыз, маңызды ағындардан өтіңіз, және staging дұрыс көрінгенде ғана production-ға жариялаңыз.

Бұл идеяға жаңа болсаңыз, staging ортасы дегеніміз не ұғымды түсіндіреді. Бұл нұсқаулық — DevOps командасын басқармай, AI құралдарымен жасайтын адамдарға арналған практикалық орнату.

Dev, staging және production

Көп шағын қолданбаға үш орын керек, тіпті біріншісі тек құрастырушыңыздың алдын ала қарауы болса да:

Staging-тің мақсаты — production сияқты әрекет етуі: сол код, сол стек, сол түрдегі баптаулар, бірақ онда жіберілген қате ешкімге зиян тигізбейді.

1-қадам: Staging нені сәйкестендіруі керек екенін шешіңіз

Staging тек production-да көрінбес бұрын проблемалар онда көрінсе ғана пайдалы. Сәйкестендіріңіз:

• Бірдей кодты, бірдей жолмен шығарылған.
• Бірдей стек және нұсқалар — фреймворк, runtime, дерекқор түрі.
• Бірдей түрдегі конфигурацияны — бірдей орта айнымалы атаулары, тест мәндерімен.
• Бірдей қызметтерді — production-да веб-қолданба мен API болса, staging-те де екеуі болады.

Өлшемі бойынша (кішірек машина жарайды) және деректері бойынша ерекшеленуі мүмкін.

2-қадам: Көшірмені жасаңыз

Ең қарапайым тәсіл: сол жобаның екінші орналастыруы, басқа URL-де, мысалы staging.yourapp.com немесе yourapp-staging.example.com.

Мұны қалай жасау хостиңізге байланысты:

• Кірістірілген preview немесе staging орналастыруы бар хосттар Git тармағы үшін автоматты түрде жасай алады.
• Мұндай мүмкіндігі жоқ хосттар: бір кодтан екінші қолданба немесе жоба жасап, оны бөлек орналастырыңыз.
• Git-тегі код: staging-ке орналастыратын staging немесе main тармағын ұстаңыз, ал production-ға релизден орналастырыңыз. Қараңыз: AI арқылы жасалған қолданбамен Git-ті қалай қолдану керек.

3-қадам: Staging-ке өз дерекқорын беріңіз

Бұл сізді қорғайтын қадам. Staging мен production дерекқорды ортақ пайдаланса, жазбаларды жоятын тест нақты жазбаларды жояды.

• Staging үшін бөлек дерекқор жасаңыз.
• Оны seed деректерімен толтырыңыз — AI сізге жасап бере алатын шынайы көрінетін жалған жазбалар.
• Production деректерінің көшірмесі керек болса, алдымен аттарды, электрондық пошталарды және жеке нәрсенің бәрін алып тастаңыз немесе араластырыңыз.

Бос дерекқорды шынайы тест деректерімен толтыратын seed скриптін жазыңыз: 20 клиент, әр түрлі күйдегі 50 тапсырыс және екі әкімші пайдаланушы. Анық жалған аттар мен example.com электрондық пошталарын қолданыңыз.

Баптауға сенбес бұрын әр көшірменің қай дерекқорға қосылатынын растаңыз. Тікелей сұраңыз:

Бұл қолданба қай дерекқорға қосылады және бұл баптау қайдан келеді? Маған құпия сөзді емес, айнымалы атауын көрсетіңіз.

4-қадам: Тест кілттерін және бөлек баптауларды қолданыңыз

Сыртқы қызметпен сөйлесетін бәрі staging-те тест тіркелгі деректерін қолдануы керек:

• Төлемдер тест режимінде (мысалы, Stripe тест кілттері), сондықтан ешқандай нақты карта төленбейді.
• Электрондық пошта санды орында немесе тек өз мекенжайыңызға жіберіледі, сондықтан клиенттер ешқашан тест хатын алмайды.
• AI және басқа ақылы API-лер бөлек кілтпен және төмен шығын шегімен.
• Вебхуктар production-ға емес, staging URL-іне бағытталған.

Екі ортада да айнымалы атауларын бірдей ұстаңыз, тек мәндерін өзгертіңіз. Осылайша код қай жерде жұмыс істеп жатқанын білудің қажеті жоқ. Бұл туралы көбірек білу үшін API кілттерін қауіпсіз ұстау қараңыз.

5-қадам: Staging-ті жеке ұстаңыз

Staging ашық болмауы керек:

• Оны логин, құпия сөз немесе команда электрондық поштасының рұқсат тізімінің артына қойыңыз.
• Іздеу жүйелерінің оны noindex meta тегі немесе X-Robots-Tag тақырыбы арқылы индекстемеуін қамтамасыз етіңіз.
• Жария сайтыңыздан оған сілтеме жасамаңыз.
• Оны басқаша көрсетіңіз — ашық түсті "STAGING" жолағы дұрыс емес қойындыда тестілеуді болдырмайды.

APP_ENV айнымалысы "staging" болғанда әр бет жоғарысында "STAGING — тек тест деректері" деген ашық сары жолақ көрсетілсін. Сондай-ақ осы жағдайда noindex meta тегін қосыңыз.

6-қадам: Релиз әдетін жасаңыз

Staging тек оны әр кез қолданғанда ғана көмектеседі. Қарапайым әдет:

1. Өзгерісті әзірлеуде жасап, алдын ала қарауда тексеріңіз.
2. Оны staging-ке шығарыңыз.
3. Негізгі ағындарыңыздан өтіңіз: тіркелу, кіру, негізгі мүмкіндік, төлемдер, өзгеріс әсер еткен бәрі.
4. Бірдеңе бұзылса, түзетіңіз және staging-ке қайта шығарыңыз.
5. Дәл сол нұсқаны production-ға жариялаңыз.
6. Production-ды тез тексеріңіз — сол ағындар, қысқаша.

Негізгі ағындарды қысқа тест скрипті ретінде жазып алыңыз. Нені қосу керектігі үшін іске қосар алдында қолданбаны қалай тестілеу керек қараңыз.

7-қадам: Дерекқор өзгерістерін мұқият өңдеңіз

Дерекқор құрылымының өзгерістері — баған қосу, кестені қайта атау — staging-тің пайдасы көрінетін жер.

• Әр құрылымдық өзгерісті алдымен staging-те іске қосыңыз.
• Жаңа мүмкіндіктердің жұмыс істеуін ғана емес, бар деректердің сақталғанын тексеріңіз.
• Осы өзгерісті production-да іске қоспас бұрын production резервтік көшірмесін жасаңыз. Қараңыз: қолданба дерекқорының резервтік көшірмесін қалай жасау керек.
• Атын өзгертетін немесе жоятын өзгерістердің орнына қосатын өзгерістерді таңдаңыз, сонда кері қайтарған кезде ескі нұсқа әлі жұмыс істейді.

Мысал сұрау сөздер

Егер осы дерекқор өзгерісін production-да іске қоссақ, бар деректерге не болар еді? Бірдеңе жойыла ма немесе атауы өзгере ме?

Барлық ортаға тән баптауларды — API URL-дері, кілттер, электрондық пошта жіберушісі, сайттың өз URL-і — staging және production-да бірдей атаулы орта айнымалыларынан келетіндей етіңіз. Оларды тізіп беріңіз.

Осы қолданба не істейтініне негізделген, әр релиз алдында staging-те тексеру керек ағындардың қысқа чек-листін жазыңыз.

Жиі кездесетін қателер

• Ортақ дерекқор. Ең зиянды қате. Staging әрқашан өз дерекқорын алады.
• Staging-те жанды кілттер. Нақты төлемдер, нақты клиенттерге жіберілген тест хаттары.
• Staging production-нан алшақтайды. Басқа нұсқалар немесе баптаулар staging проблемаларды аулауды тоқтатады.
• Жария, индекстелген staging сайты, ол іздеу нәтижелерінде нақты сайтыңыздың қасында шығады.
• "Шағын" өзгерістер үшін staging-ті өткізіп жіберу. Шағын өзгерістер де бәрін бұзады.
• Дұрыс емес қойындыда тестілеу. Көрінетін жолақ мұны түзетеді.

Чек-лист

• Staging production сияқты код, стек және қызметтерді іске қосады.
• Staging-тің өз дерекқоры бар, тест немесе тазартылған деректермен.
• Төлемдер, электрондық пошта және ақылы API-лер staging-те тест кілттерін қолданады.
• Айнымалы атаулары ортадан ортаға сәйкес; тек мәндері әр түрлі.
• Staging логин немесе құпия сөз артында және индекстелмейді.
• Staging-те болғанда жолақ көрсетіледі.
• Әр релиз алдымен staging-ке барады, тексеретін ағындар жазылған тізімімен.
• Дерекқор өзгерістері алдымен staging-те іске қосылады, релиз алдында production резервтік көшірмесімен.

Mythex-тегі staging

Mythex-тің Publish қолданбаға бір жанды URL береді; бөлек staging ауыстырғышы жоқ. Іс жүзінде екі нұсқа бар:

• Алдын ала қарауды релиз алдындағы тексеру ретінде пайдалану. Әр жоба жеке бұлттық жұмыс кеңістігінде жанды Preview-мен жұмыс істейді. /test агентке оны пайдаланушы сияқты басып шығуды тапсырады, ал Share сілтемесі клиент немесе командалас адамға жариялаусыз preview-ді қарауға мүмкіндік береді. Қараңыз: Preview және Code. Көп жеке жобаға бұл жеткілікті.
• Staging ретінде екінші жоба. Pro жоспарында жобаны экспорттап, жаңа жобаға импорттаңыз, сол жобаға өз дерекқоры мен тест кілттері бар құпиялар беріңіз және оны өз slug-ымен жариялаңыз. Production жобасын жарияламас бұрын оған шығарыңыз.

Қалай болғанда да, деректерді жоятын тестілеудің алдында агенттен preview мен жарияланған қолданба қай дерекқорды пайдаланатынын сұраңыз, ал дұрыс емес өзгерісті кері қайтару үшін checkpoint-терді қолданыңыз. Қолданбаны кеңінен жанды ету үшін AI прототипін production-ға қалай шығару керек қараңыз.

Сұрақтар