Ինչպես կազմակերպել staging միջավայր ձեր հավելվածի համար

Staging միջավայր կազմակերպելու համար տեղակայեք ձեր հավելվածի երկրորդ օրինակը սեփական մասնավոր URL-ով, տվեք նրան սեփական տվյալների բազա և թեստային API բանալիներ, և հնարավորինս մոտ պահեք արտադրականի կարգավորումները։ Այնուհետև յուրաքանչյուր կարևոր փոփոխություն նախ թողարկեք staging-ում, անցեք կարևոր հոսքերը և արտադրություն ուղարկեք միայն այն ժամանակ, երբ staging-ը ճիշտ է երևում։

Եթե այս գաղափարը նոր է ձեզ համար, ինչ է staging միջավայրը բացատրում է հասկացությունը։ Այս ուղեցույցը գործնական կազմակերպումն է՝ գրված նրանց համար, ովքեր AI գործիքներով են կառուցում, ոչ թե DevOps թիմ ունեն։

Մշակում, staging և արտադրություն

Ակնկալվում է, որ փոքր հավելվածին պետք են երեք տեղ, նույնիսկ եթե առաջինը պարզապես ձեր կառուցողի նախադիտումն է.

Staging-ի իմաստն այն է, որ այն վարվում է արտադրականի պես. նույն կոդը, նույն կառուցվածքը, նույն տիպի կարգավորումները, բայց այնտեղ սխալը ոչ ոքի չի վնասում։

Քայլ 1. Որոշեք, թե ինչին պետք է համապատասխանի staging-ը

Staging-ը օգտակար է միայն այն դեպքում, եթե խնդիրները հայտնաբերվում են նախքան արտադրությունում հայտնվելը։ Համապատասխանեցրեք.

• Նույն կոդը, թողարկված նույն կերպ։
• Նույն կառուցվածքը և տարբերակները՝ ֆրեյմվորք, միջավայր, տվյալների բազայի տեսակ։
• Նույն տիպի կարգավորումները՝ նույն միջավայրի փոփոխականների անուններ, թեստային արժեքներով։
• Նույն ծառայությունները. եթե արտադրությունն ունի վեբ հավելված և API, staging-ն էլ ունի երկուսը։

Չափը կարող է տարբերվել (փոքր մեքենան նորմալ է), և տվյալները՝ նույնպես։

Քայլ 2. Ստեղծեք պատճենը

Ամենապարզ մոտեցումը. նույն նախագծի երկրորդ տեղակայումը՝ այլ URL-ով, օրինակ՝ staging.yourapp.com կամ yourapp-staging.example.com.

Ինչպես դա անել, կախված է ձեր հոսթից.

• Հոսթեր, որոնք ունեն ներկառուցված նախադիտման կամ staging տեղակայումներ, կարող են ավտոմատ ստեղծել մեկը Git ճյուղի համար։
• Հոսթեր առանց դրա. ստեղծեք երկրորդ հավելված կամ նախագիծ նույն կոդից և տեղակայեք առանձին։
• Կոդը Git-ում. պահեք staging կամ main ճյուղ, որը տեղակայվում է staging-ում, և արտադրությունը տեղակայեք թողարկումից։ Տե՛ս ինչպես օգտագործել Git-ը AI-ով կառուցված հավելվածի հետ։

Քայլ 3. Տվեք staging-ին սեփական տվյալների բազա

Սա այն քայլն է, որը ձեզ պաշտպանում է։ Եթե staging-ը և արտադրությունը կիսում են տվյալների բազան, թեստը, որը ջնջում է գրառումներ, ջնջում է իրական գրառումները։

• Ստեղծեք առանձին տվյալների բազա staging-ի համար։
• Լցրեք այն սերմնավոր տվյալներով — իրատեսական կեղծ գրառումներով, որոնք AI-ն կարող է ձեզ համար գեներացնել։
• Եթե արտադրական տվյալների պատճեն եք պետք, նախ հեռացրեք կամ խառնեք անուններն, էլ. հասցեները և ամեն անձնական բան։

Գրիր սերմի սկրիպտ, որը լցնում է դատարկ տվյալների բազան իրատեսական թեստային տվյալներով՝ 20 հաճախորդ, 50 պատվեր տարբեր վիճակներում և երկու ադմին օգտատեր։ Օգտագործիր ակնհայտ կեղծ անուններ և example.com էլ. հասցեներ։

Մինչ վստահելը կարգավորումը, հաստատեք, թե յուրաքանչյուր պատճեն ո՞ր տվյալների բազային է միանում։ Հարցրեք ուղղակի.

Ո՞ր տվյալների բազային է միանում այս հավելվածը, և այդ կարգավորումը որտեղից է գալիս։ Ցույց տուր փոփոխականի անունը, ոչ գաղտնաբառը։

Քայլ 4. Օգտագործեք թեստային բանալիներ և առանձին կարգավորումներ

Յուրաքանչյուր բան, որը խոսում է արտաքին ծառայության հետ, staging-ում պետք է օգտագործի թեստային հավատարմագրեր.

• Վճարումներ թեստային ռեժիմում (օրինակ՝ Stripe-ի թեստային բանալիներ), որպեսզի ոչ մի իրական քարտ չգանձվի։
• Էլ. նամակ, որը ուղարկվում է սենդբոքսին կամ միայն ձեր սեփական հասցեին, որպեսզի հաճախորդները երբեք թեստային նամակ չստանան։
• AI և այլ վճարովի API-ներ առանձին բանալիով և ցածր ծախսերի սահմանաչափով։
• Վեբհուկեր՝ ուղղված staging URL-ին, ոչ թե արտադրությանը։

Պահեք միջավայրի փոփոխականների անունները նույնը երկու միջավայրերում, և փոխեք միայն արժեքները։ Այդպես կոդը պետք չէ իմանա, թե որտեղ է աշխատում։ Այս մասին ավելին՝ ինչպես պահել API բանալիները անվտանգ։

Քայլ 5. Պահեք staging-ը մասնավոր

Staging-ը չպետք է հանրային լինի.

• Դրեք այն մուտքի, գաղտնաբառի կամ թիմի էլ. հասցեների թույլտվության ցուցակի հետևում։
• Կանխեք, որ որոնիչները չինդեքսավորեն այն noindex մետա պիտակով կամ X-Robots-Tag վերնագրով։
• Մի հղեք դրան ձեր հանրային կայքից։
• Դարձրեք այն տարբերվող. գունավոր «STAGING» հայտարարությունը վերևում կանխում է սխալ ներդիրում փորձարկելը։

Ավելացրու վառ դեղին հայտարարություն յուրաքանչյուր էջի վերևում, որտեղ գրված է «STAGING — միայն թեստային տվյալներ», երբ APP_ENV միջավայրի փոփոխականը «staging» է։ Նաև այդ դեպքում ավելացրու noindex մետա պիտակ։

Քայլ 6. Կազմեք թողարկման ռութին

Staging-ը օգնում է միայն այն դեպքում, եթե այն միշտ օգտագործում եք։ Պարզ ռութին.

1. Կատարեք փոփոխությունը մշակման մեջ և ստուգեք նախադիտման մեջ։
2. Թողարկեք staging-ում։
3. Անցեք հիմնական հոսքերը. գրանցում, մուտք, հիմնական գործառույթը, վճարումները, ամեն ինչ, ինչին փոփոխությունը դիպել է։
4. Եթե ինչ-որ բան կոտրվում է, շտկեք և նորից թողարկեք staging-ում։
5. Նույն տարբերակը թողարկեք արտադրություն։
6. Արագ ստուգեք արտադրությունը. նույն հոսքերը, կարճ։

Գրի՛ր հիմնական հոսքերը որպես կարճ թեստային սցենար։ Տե՛ս ինչպես փորձարկել ձեր հավելվածը գործարկումից առաջ, թե ինչ ներառել։

Քայլ 7. Զգուշորեն վարվեք տվյալների բազայի փոփոխությունների հետ

Տվյալների բազայի կառուցվածքի փոփոխությունները՝ սյունակ ավելացնելը, աղյուսակը վերանվանելը, հենց այն են, որտեղ staging-ը արժանի է իր տեղը։

• Յուրաքանչյուր կառուցվածքային փոփոխություն նախ կատարեք staging-ում։
• Ստուգեք, որ գոյություն ունեցող տվյալները պահպանվել են, ոչ միայն այն, որ նոր գործառույթները աշխատում են։
• Նախքան նույն փոփոխությունը արտադրությունում կատարելը, արտադրության պահուստային պատճեն վերցրեք։ Տե՛ս ինչպես պահուստավորել ձեր հավելվածի տվյալների բազան։
• Նախընտրեք այն փոփոխությունները, որոնք ավելացնում են, ոչ թե վերանվանում կամ ջնջում, որպեսզի հին տարբերակը դեռ աշխատի, եթե հետ վերադառնաք։

Օրինակ հուշումներ

Բացատրիր, թե ինչ կպատահի գոյություն ունեցող տվյալներին, եթե այս տվյալների բազայի փոփոխությունը կատարենք արտադրության վրա։ Ջնջվում կամ վերանվանվում է որևէ բան։

Բոլոր միջավայրին հատուկ կարգավորումները՝ API URL-ները, բանալիները, էլ. նամակի ուղարկողը, կայքի սեփական URL-ը, դարձրու միջավայրի փոփոխականներից՝ նույն անուններով staging-ում և արտադրությունում։ Թվարկիր դրանք։

Գրիր կարճ ստուգաթերթ այն հոսքերի մասին, որոնք պետք է ստուգեմ staging-ում յուրաքանչյուր թողարկումից առաջ՝ հիմնված այն բանի վրա, թե ինչ է անում այս հավելվածը։

Սովորական սխալներ

• Ընդհանուր տվյալների բազա. Ամենավնասակար սխալը։ Staging-ը միշտ պետք է ունենա իր սեփականը։
• Իրական բանալիներ staging-ում. Իրական գանձումներ, իրական նամակներ իրական հաճախորդներին։
• Staging-ը շեղվում է արտադրությունից. Տարբեր տարբերակներ կամ կարգավորումներ նշանակում են, որ staging-ը այլևս չի բռնում խնդիրները։
• Հանրային, ինդեքսավորված staging կայք, որը հայտնվում է որոնման արդյունքներում՝ կողքին ձեր իրական կայքի։
• Staging բաց թողնել «փոքր» փոփոխությունների համար. Փոքր փոփոխությունները նույնպես կոտրում են։
• Թեստավորել սխալ ներդիրում. Տեսանելի հայտարարությունը դա շտկում է։

Ստուգաթերթ

• Staging-ը աշխատում է նույն կոդով, կառուցվածքով և ծառայություններով, ինչ արտադրությունը։
• Staging-ն ունի իր սեփական տվյալների բազան՝ թեստային կամ մաքրված տվյալներով։
• Վճարումները, էլ. նամակը և վճարովի API-ները staging-ում օգտագործում են թեստային բանալիներ։
• Միջավայրի փոփոխականների անունները համընկնում են. փոխվում են միայն արժեքները։
• Staging-ը մուտքի կամ գաղտնաբառի հետևում է և ինդեքսավորված չէ։
• Երբ staging-ում եք, հայտարարություն է երևում։
• Յուրաքանչյուր թողարկում նախ գնում է staging, գրված ստուգվող հոսքերի ցուցակով։
• Տվյալների բազայի փոփոխությունները նախ կատարվում են staging-ում, արտադրության պահուստով թողարկումից առաջ։

Staging Mythex-ում

Mythex-ի Publish-ը տալիս է մեկ կենդանի URL յուրաքանչյուր հավելվածի համար. առանձին staging անջատիչ չկա։ Գործնականում երկու տարբերակ ունեք.

• Նախադիտումը որպես նախաթողարկման ստուգում. Յուրաքանչյուր նախագիծ աշխատում է մասնավոր cloud աշխատավայրում՝ կենդանի Preview-ով։ /test-ը ստիպում է գործակալին սեղմել դրա վրայով՝ որպես օգտատեր, իսկ Share հղումը թույլ է տալիս գործընկերոջը կամ հաճախորդին վերանայել նախադիտումը առանց հրապարակելու։ Տե՛ս Preview և Code։ Շատ անձնական նախագծերի համար սա բավական է։
• Երկրորդ նախագիծը որպես staging. Pro պլանում արտահանեք նախագիծը և ներմուծեք նոր նախագծի մեջ, տվեք այդ նախագծին սեփական տվյալների բազա և թեստային բանալիների գաղտնիքներ, և հրապարակեք այն սեփական slug-ով։ Թողարկեք դրան, նախքան արտադրական նախագիծը հրապարակելը։

Ամեն դեպքում, նախքան որևէ կործանարար բան փորձարկելը հարցրեք գործակալին, թե ո՞ր տվյալների բազային են միանում նախադիտումը և հրապարակված հավելվածը, և օգտագործեք ստուգակետեր (checkpoints)՝ վատ փոփոխությունը հետ վերադարձնելու համար։ Հավելվածը ընդհանրապես արտադրություն տանելու մասին տե՛ս ինչպես AI նախատիպը տանել արտադրություն։

Հարցեր