Ի՞նչ է staging միջավայրը։ Փորձարկեք, նախքան թողարկելը

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

Ինչու է staging-ը կարևոր AI-ով կառուցելիս

AI-ն փոփոխությունները դարձնում է արագ։ Կարող եք ավելացնել գործառույթ, վերաշարադրել էջ կամ փոխել տվյալների կառուցվածքը րոպեների ընթացքում։ Այդ արագությունը հիանալի է այնքան ժամանակ, քանի դեռ մի փոփոխություն, որը ճիշտ էր թվում, անաղմուկ կերպով չի կոտրել վճարումը, կամ «փոքր մաքրումը» չի ջնջել հաճախորդի տվյալների սյունակը։

Տեղ, որտեղ փոփոխությունները ստուգում եք նախքան կենդանի դառնալը, օգնում է ձեզ․

• Բռնել խզումները նախքան հաճախորդները։ Փորձեք գրանցման, վճարման և հիմնական գործընթացները յուրաքանչյուր էական փոփոխությունից հետո։
• Փորձարկել իրական պայմաններում։ Staging-ը պետք է վարվի production-ի պես՝ նույն կառուցվածքով և նման կարգավորումներով, որպեսզի խնդիրները հայտնվեն այնտեղ, ոչ թե ավելի ուշ։
• Պաշտպանել իրական տվյալները։ Տվյալների բազայի փոփոխությունները, ներմուծումները և զանգվածային խմբագրումները կարելի է նախ փորձել թեստային տվյալների վրա։
• Ցույց տալ աշխատանքը ընթացքի մեջ։ Հաճախորդը կամ գործընկերը կարող է դիտել փոփոխությունը՝ առանց այն հրապարակային դարձնելու։

Ամենօրյա անալոգիա

Մտածեք թատրոնի գեներալ փորձի մասին։

• Development-ը փորձերի սենյակն է. դերասանները սովորում են տողերը, կանգնում, սկսում նորից, փորձում։
• Staging-ը գեներալ փորձն է. լրիվ կոստյում, իրական բեմ, իրական լույսեր՝ ամեն ինչ այնպես, ինչպես կլինի բացման գիշերը, բացի այն, որ հանդիսատես չկա։
• Production-ը բացման գիշերն է. սխալները տեղի են ունենում բոլորի առջև։

Այն խնդիրների մեծ մասը, որոնցից ցանկանում եք խուսափել բացման գիշերը, երևում են գեներալ փորձի ժամանակ՝ կոստյումի փոփոխություն, որը չափազանց երկար է տևում, կամ լույսի ճիշտ չէ նշանը։ Հենց դա է staging-ի աշխատանքը։

Երեք սովորական միջավայր

Յուրաքանչյուր միջավայր հիմնականում տարբերվում է իր կարգավորումներով․ թե որ տվյալների բազային է միանում, թե որ բանալիներն է օգտագործում, թե որ URL-ում է գտնվում։ Ահա թե ինչու լավ հավելվածները այդ կարգավորումները կարդում են միջավայրի փոփոխականներից և գաղտնիքներից, այլ ոչ թե ամրագրում կոդում։ Նույն կոդը այդ դեպքում կարող է աշխատել յուրաքանչյուր միջավայրում՝ տարբեր կարգավորումներով։

Օրինակ՝ սրահի ամրագրման հավելվածի չեղարկման կանոնների փոփոխում

Դուք վարում եք սրահի ամրագրման հավելված՝ վճարող հաճախորդներով։ Ուզում եք փոխել կանոնը, որպեսզի հաճախորդները կարողանան չեղարկել 24 ժամ առաջ, ոչ թե 48, և վերադարձը լինի ավտոմատ։

1. Կառուցեք development-ում։ Խնդրում եք ձեր AI builder-ին փոփոխությունը։ Այն թարմացնում է չեղարկման տրամաբանությունը և վերադարձի կանչը դեպի ձեր վճարման մատակարարը։

2. Թողարկեք staging-ում։ Staging-ը աշխատում է նույն կոդով, միացված staging տվյալների բազային՝ թեստային ամրագրումներով և ձեր վճարման մատակարարի թեստային ռեժիմի բանալիներով։

3. Փորձարկեք իրական հոսքերը։ Դուք և գործընկերը՝

• ամրագրում եք թեստային ժամ վաղվա համար և չեղարկում 30 ժամ առաջ՝ այն պետք է վերադարձվի․
• փորձում եք չեղարկել 10 ժամ առաջ՝ այն պետք է մերժվի հստակ հաղորդագրությամբ․
• ստուգում եք, որ վերադարձը հայտնվում է վճարման մատակարարի թեստային վահանակում․
• ստուգում եք, որ հաստատման նամակում գրված է 24 ժամ, ոչ թե 48։

4. Գտեք սխալը։ Staging-ում նկատում եք, որ կանոնը օգտագործում է սերվերի ժամային գոտին, ոչ թե սրահինը, ուստի սահմանաժամը մեկ ժամով սխալ է։ Ուղղում եք և կրկին փորձարկում։

5. Թողարկեք production-ում։ Միայն այժմ փոփոխությունը հասնում է իրական հաճախորդներին՝ ժամային գոտու սխալն արդեն բռնված։

Առանց staging-ի, քայլ 4-ը տեղի կունենար իրական հաճախորդի վերադարձի հետ։

Հիմնական տերմիններ

Սովորական թյուրըմբռնումներ

• «Staging-ը կարող է կիսել production տվյալների բազան»։ Սա ամենավտանգավոր դյուրանցումն է։ Թեստը, որը ջնջում կամ խմբագրում է գրառումներ, կհասնի իրական հաճախորդներին։ Staging-ին տվեք իր սեփական տվյալների բազան։
• «Եթե աշխատում է staging-ում, չի կարող կոտրվել production-ում»։ Staging-ը նվազեցնում է ռիսկը, բայց չի վերացնում այն։ Իրական թրաֆիկը, իրական տվյալները և արտաքին ծառայությունները դեռ կարող են անսպասելի լինել։ Պահեք հետ վերադառնալու հնարավորություն։
• «Staging-ը պետք է թանկ լինի»։ Այն կարող է փոքր լինել։ Պետք է նույն կառուցվածքը, ինչ production-ը, ոչ թե նույն չափը։
• «Օգտագործեք կենդանի վճարման բանալիներ staging-ում՝ ավելի իրական լինելու համար»։ Օգտագործեք մատակարարի թեստային ռեժիմը։ Իրական չի նշանակում իրական փող։
• «Staging-ը միայն մեծ թիմերի համար է»։ Գաղափարը՝ նախ անվտանգ տեղում փորձարկել, օգտակար է նույնիսկ մեկ մարդու համար։ Ծեսի մակարդակը կարող է համապատասխանել ներգրավված ռիսկերին։
• «Staging-ը պետք է հրապարակային լինի, որ մարդիկ կարողանան փորձել»։ Պահեք այն մասնավոր կամ պաշտպանված, և արգելեք որոնիչներին ինդեքսավորել այն, որ ոչ ոք այն չշփոթի իրական հավելվածի հետ։

Ինչ խնդրել AI builder-ից

• «Դարձրու յուրաքանչյուր միջավայրին հատուկ կարգավորում՝ տվյալների բազան, API բանալիները, կայքի URL-ը, միջավայրի փոփոխականներից։»
• «Ավելացրու seed սկրիպտ, որը լցնում է ոչ արտադրական տվյալների բազան իրատեսական թեստային տվյալներով։»
• «Օգտագործիր մատակարարի թեստային ռեժիմը, մինչև ասեմ, որ գնում ենք գործարկման։»
• «Մինչև այս փոփոխությունը կենդանի դառնա, ցույց տուր, թե ինչ հոսքեր պետք է փորձարկեմ և ինչ պետք է լինի յուրաքանչյուրում։»
• «Այս փոփոխությունը կազդի՞ արդյոք գոյություն ունեցող տվյալների վրա։ Ցույց տուր միգրացիան նախ։»
• «Համոզվիր, որ կայքի ոչ արտադրական պատճենները որոնիչների կողմից չեն ինդեքսավորվում։»

Քայլ առ քայլ կարգավորման համար տե՛ս ինչպես կարգավորել staging միջավայրը։ Երբ թողարկումները դառնան հաճախակի, կոդից staging և production ճանապարհը ավտոմատացնելը այն է, ինչի համար է CI/CD-ն։

Թողարկումից առաջ փորձարկումը Mythex-ում

Mythex-ում չկա առանձին «staging կամ production» անջատիչ․ հրապարակումը ձեզ տալիս է մեկ կենդանի հրապարակային URL, և փաստաթղթերը դա հստակ ասում են (բազմածառայական հավելվածներ)։ Այն, ինչ տալիս է, կառուցելու և կենդանի դառնալու միջև հստակ գիծ է․

• Preview-ը աշխատեցնում է ձեր հավելվածը մասնավոր ամպային sandbox-ում, մինչ կառուցում եք։ Փոփոխությունները նախ հայտնվում են այնտեղ, ոչ թե ձեր կենդանի հավելվածում։
• Share-ը ստեղծում է նախադիտման հղումներ, որպեսզի հաճախորդը կամ գործընկերը կարողանան դիտել ընթացքի մեջ գտնվող աշխատանքը՝ առանց Mythex հաշվի և առանց դուք հրապարակելու։ Հղումը ցույց է տալիս sandbox-ն այնպես, ինչպես այն հիմա է, ներառյալ կառուցման ընթացքում կատարված փոփոխությունները, և դուք կարող եք այն ցանկացած պահի ջնջել։
• Publish-ը պատկերահանում է նախագիծը և տեղակայում այն։ Մինչև նորից հրապարակեք, կենդանի հավելվածը մնում է այնպիսին, ինչպիսին էր։
• Checkpoint-ները պահվում են գործակալի յուրաքանչյուր հաջող հերթի հետո, որպեսզի կարողանաք վերադարձնել նախագծի ֆայլերը, եթե փոփոխությունը սխալ ստացվի։

Մտածեք Preview-ի մասին որպես ձեր գեներալ փորձի մասին․ վճարման մատակարարները պահեք թեստային ռեժիմում մինչև գործարկումը և յուրաքանչյուր հրապարակումից առաջ անցեք ձեր հիմնական գործընթացներով։ Երբ ներգրավված են իրական հաճախորդներ, գործակալից ստուգեք, թե որ տվյալների բազան և բանալիներ է օգտագործում ձեր Preview-ն, նախքան որևէ բան փորձարկելը, որը գրում կամ ջնջում է տվյալներ։ Եթե ձեզ անհրաժեշտ է լրիվ առանձին staging կարգավորում սեփական տվյալների բազայով, խնդրեք գործակալին բացատրել ձեր նախագծի տարբերակները, կամ՝ Pro-ում՝ արտահանեք նախագիծը կամ համաժամեցրեք այն GitHub-ի հետ և աշխատեցրեք այն ձեր վերահսկած ենթակառուցվածքում։

Հարցեր