အက်ပ်အတွက် staging environment တည်ဆောက်နည်း

Staging environment တည်ဆောက်ရန် သင့်အက်ပ်၏ ဒုတိယမိတ္တူကို ကိုယ်ပိုင် private URL သို့ deploy လုပ်ပါ၊ ကိုယ်ပိုင် database နှင့် test API key များ ပေးပါ၊ နှင့် production ၏ setup နှင့် နီးစပ်အောင် ကိုက်ညီစေပါ။ ထို့နောက် အရေးကြီးသော ပြောင်းလဲမှု အားလုံးကို staging သို့ အရင်ထုတ်ပါ၊ အရေးကြီး flow များကို စမ်းကြည့်ပြီး staging မှန်ကန်ပုံရမှသာ production သို့ ထုတ်ဝေပါ။

အယူအဆအသစ်ဖြစ်ပါက staging environment ဆိုတာ ဘာလဲ က သဘောတရားကို ရှင်းပြထားပါတယ်။ ဤလမ်းညွှန်ချက်သည် DevOps အဖွဲ့ မလည်ပတ်ဘဲ AI ကိရိယာများဖြင့် တည်ဆောက်သူများအတွက် လက်တွေ့ setup ဖြစ်ပါတယ်။

Dev၊ staging နှင့် production

အသေးစား အက်ပ်အများစုသည် နေရာသုံးခု လိုအပ်ပါတယ်၊ ပထမတစ်ခုသည် သင့် builder ၏ preview သာ ဖြစ်ရင်ပင်:

Staging ၏ ရည်ရွယ်ချက်မှာ production နှင့် တူညီစွာ အပြုအမူရှိရန် ဖြစ်ပါတယ် — code တူ၊ stack တူ၊ setting အမျိုးအစား တူ — သို့သော် ထိုနေရာတွင် အမှားဖြစ်လျှင် တစ်ယောက်မှ မထိခိုက်ပါ။

အဆင့် ၁: staging က ဘာနှင့် ကိုက်ညီရမလဲ ဆုံးဖြတ်ပါ

Production တွင် ပြဿနာများ မပေါ်မီ staging တွင် ပေါ်ရမှသာ staging သည် အသုံးဝင်ပါတယ်။ ကိုက်ညီရန်:

• Code အတူတူ၊ အတူတူ ထုတ်ဝေထားခြင်း။
• Stack နှင့် version အတူတူ — framework၊ runtime၊ database အမျိုးအစား။
• Configuration အမျိုးအစား အတူတူ — environment variable အမည်များ တူပြီး test တန်ဖိုးများဖြင့်။
• Service အတူတူ — production တွင် web app နှင့် API ရှိလျှင် staging တွင်လည်း နှစ်ခုလုံး ရှိရမည်။

အရွယ်အစား (ပိုသေးငယ်သော machine လည်းရ) နှင့် data တို့တွင် ကွဲပြားနိုင်ပါတယ်။

အဆင့် ၂: မိတ္တူ ဖန်တီးပါ

ရိုးရှင်းဆုံးနည်းလမ်းမှာ staging.yourapp.com သို့မဟုတ် yourapp-staging.example.com ကဲ့သို့ URL မတူသော နေရာတွင် project တူတူကို deployment ဒုတိယ တစ်ခု ထားခြင်း ဖြစ်ပါတယ်။

သင်ဘယ်လိုလုပ်မလဲဆိုတာ host ပေါ်မူတည်ပါတယ်:

• Built-in preview သို့မဟုတ် staging deployment ပါသော host များ က Git branch တစ်ခုအတွက် အလိုအလျောက် ဖန်တီးပေးနိုင်ပါတယ်။
• မပါသော host များ: code တူမှ ဒုတိယ app သို့မဟုတ် project တစ်ခု ဖန်တီးပြီး သီးခြား deploy လုပ်ပါ။
• Git ရှိ code: staging သို့ deploy လုပ်သော staging သို့မဟုတ် main branch ကို ထားပြီး production ကို release မှ deploy လုပ်ပါ။ AI ဖြင့် တည်ဆောက်ထားသော အက်ပ်တွင် Git သုံးနည်း ကို ကြည့်ပါ။

အဆင့် ၃: staging အတွက် ကိုယ်ပိုင် database ပေးပါ

သင့်ကို ကာကွယ်ပေးသော အဆင့်ဖြစ်ပါတယ်။ Staging နှင့် production က database တစ်ခုတည်း မျှဝေထားရင် record ဖျက်သော test သည် အမှန်တကယ် record များကို ဖျက်ပါလိမ့်မယ်။

• Staging အတွက် database သီးခြား ဖန်တီးပါ။
• Seed data ဖြင့် ဖြည့်ပါ — AI က သင့်အတွက် ထုတ်ပေးနိုင်သော အမှန်တကယ်နှင့် ဆင်တူသည့် အတုအရ record များ။
• Production data ၏ မိတ္တူ လိုအပ်ရင် အရင်ဆုံး အမည်၊ email နှင့် personal ဖြစ်သော အရာအားလုံးကို ဖယ်ရှားခြင်း သို့မဟုတ် ရောထွေးခြင်း ပြုလုပ်ပါ။

ဗလာ database ကို ဖြည့်သော seed script တစ်ခု ရေးပါ၊ အမှန်နှင့် ဆင်တူသော test data: customer ၂၀ ယောက်၊ အခြေအနေ မတူသော order ၅၀၊ admin အသုံးပြုသူ ၂ ယောက်။ အတုအယောင် အမည်ရှင်းရှင်းနှင့် example.com email လိပ်စာများကို သုံးပါ။

Setup ကို မယုံမီ မိတ္တူတစ်ခုစီက ဘယ် database သို့ ချိတ်ဆက်သလဲ အတည်ပြုပါ။ တိုက်ရိုက် မေးပါ:

ဒီအက်ပ်က ဘယ် database သို့ ချိတ်ဆက်သလဲ၊ ထို setting က ဘယ်မှ လာသလဲ? Password မဟုတ်ဘဲ variable အမည်ကို ပြပါ။

အဆင့် ၄: test key များနှင့် သီးခြား setting များ သုံးပါ

အပြင်ဘက် ဝန်ဆောင်မှုနှင့် ဆက်သွယ်သည့် အရာအားလုံးသည် staging တွင် test credential များ သုံးရမည်:

• Payment test mode တွင် (ဥပမာ Stripe test key များ)၊ အမှန်ကတ်မှ ငွေမကောက်ခံရန်။
• Email sandbox သို့ သို့မဟုတ် သင့်ကိုယ်ပိုင် လိပ်စာသို့သာ ပို့ပါ၊ customer များက test message မရရန်။
• AI နှင့် အခြား paid API များကို သီးခြား key နှင့် နိမ့်သော ကုန်ကျစရိတ် ကန့်သတ်ချက်ဖြင့်။
• Webhook များကို production မဟုတ်ဘဲ staging URL သို့ ညွှန်ပါ။

နှစ်ခုစလုံးတွင် variable အမည်များ ကို တူညီစွာ ထားပြီး တန်ဖိုးများကိုသာ ပြောင်းပါ။ ဒီနည်းဖြင့် code သည် ဘယ်နေရာတွင် run နေသလဲ သိရန် မလိုအပ်ပါ။ ဤအကြောင်း ပိုသိလိုလျှင် API key များကို ဘေးကင်းအောင် ထိန်းသိမ်းနည်း ကို ကြည့်ပါ။

အဆင့် ၅: staging ကို private ထားပါ

Staging သည် အများပြည်သူ မဖြစ်သင့်ပါ:

• Login၊ password သို့မဟုတ် team email များ၏ allow-list နောက်ကွယ်တွင် ထားပါ။
• noindex meta tag သို့မဟုတ် X-Robots-Tag header ဖြင့် search engine များက index မလုပ်အောင် ရပ်ပါ။
• အများပြည်သူ site မှ ၎င်းသို့ link မချိတ်ပါနဲ့။
• ကွဲပြားအောင် ပြုလုပ်ပါ — အရောင်ရှိ "STAGING" banner က မှားသော tab တွင် စမ်းသပ်ခြင်းကို တားဆီးပေးပါတယ်။

APP_ENV environment variable သည် "staging" ဖြစ်သည့်အခါ စာမျက်နှာတိုင်း၏ ထိပ်တွင် တောက်ပသော အဝါရောင် banner တစ်ခုကို "STAGING — test data only" ဟု ပြပါ။ ထိုအခြေအနေတွင် noindex meta tag လည်း ထည့်ပါ။

အဆင့် ၆: ထုတ်ဝေမှု လုပ်ထုံးလုပ်နည်း ထားပါ

Staging သည် အချိန်တိုင်း သုံးမှသာ ကူညီပါတယ်။ ရိုးရှင်းသော လုပ်ထုံးလုပ်နည်း:

1. Development တွင် ပြောင်းလဲမှု ပြုလုပ်ပြီး preview တွင် စစ်ဆေးပါ။
2. Staging သို့ ထုတ်ပါ။
3. အဓိက flow များကို လုပ်ကြည့်ပါ: sign up၊ login၊ အဓိက feature၊ payment၊ ပြောင်းလဲမှု ထိခိုက်သည့် အရာအားလုံး။
4. တစ်ခုခု ပျက်ရင် ပြင်ပြီး staging သို့ ထပ်ထုတ်ပါ။
5. Version တူတူကို production သို့ ထုတ်ပါ။
6. Production ကို မြန်မြန်စစ်ပါ — flow တူတူကို အကျဉ်းချုပ်ပါ။

အဓိက flow များကို စာတိုတစ်ခု test script အဖြစ် ရေးမှတ်ပါ။ ပါဝင်သင့်သည်များအတွက် launch မတိုင်မီ အက်ပ်ကို စမ်းသပ်နည်း ကို ကြည့်ပါ။

အဆင့် ၇: database ပြောင်းလဲမှုများကို ဂရုတစိုက် ကိုင်တွယ်ပါ

Database ဖွဲ့စည်းပုံ ပြောင်းလဲမှု — column ထည့်ခြင်း၊ table အမည် ပြောင်းခြင်း — တွင် staging သည် တန်ဖိုးရှိပါတယ်။

• ဖွဲ့စည်းပုံ ပြောင်းလဲမှု အားလုံးကို staging တွင် အရင် run ပါ။
• Feature အသစ်များ အလုပ်လုပ်သည်သာမက ရှိပြီးသား data များ ကျန်ရှိနေကြောင်း စစ်ဆေးပါ။
• တူညီသော ပြောင်းလဲမှုကို production တွင် မ run မီ production ၏ backup ကို ယူပါ။ အက်ပ် database ကို backup လုပ်နည်း ကို ကြည့်ပါ။
• Rename သို့မဟုတ် delete မဟုတ်ဘဲ ထည့်သော ပြောင်းလဲမှုများကို ဦးစားပေးပါ၊ ထို့ကြောင့် rollback လုပ်ရင် ဟောင်းဗားရှင်းက ဆက်အလုပ်လုပ်ပါမည်။

ဥပမာ prompt များ

ဤ database ပြောင်းလဲမှုကို production တွင် run ခဲ့ရင် ရှိပြီးသား data ကို ဘာဖြစ်မလဲ ရှင်းပြပါ။ တစ်ခုခု ဖျက်ခံရ သို့မဟုတ် အမည်ပြောင်းခံရလား?

Environment-specific setting အားလုံး — API URL များ၊ key များ၊ email sender၊ site ၏ ကိုယ်ပိုင် URL — ကို staging နှင့် production တွင် အမည်တူ environment variable များမှ ရလာအောင် ပြုလုပ်ပါ။ စာရင်းပြုစုပါ။

ဤအက်ပ် လုပ်ဆောင်ချက်အပေါ် အခြေခံ၍ ထုတ်ဝေမှုတိုင်းမတိုင်မီ staging တွင် စမ်းသပ်သင့်သော flow များ၏ တိုတိုစစ်ဆေးစာရင်း ရေးပေးပါ။

အများဆုံး ဖြစ်တတ်သော အမှားများ

• Database မျှဝေခြင်း။ အထိခိုက်ဆုံး အမှား။ Staging သည် အမြဲ ကိုယ်ပိုင် ရရမည်။
• Staging တွင် live key များ။ အမှန်တကယ် ငွေကောက်ခံခြင်း၊ အမှန်တကယ် customer များထံ အမှန် email များ။
• Staging သည် production မှ ကွဲထွက်ခြင်း။ မတူသော version သို့မဟုတ် setting များက staging က ပြဿနာများကို မဖမ်းမိတော့ပါ။
• အများပြည်သူ၊ index လုပ်ထားသော staging site — သင့်အမှန် site နှင့်အတူ search ရလဒ်တွင် ပေါ်လာခြင်း။
• "သေးငယ်သော" ပြောင်းလဲမှုများအတွက် staging ကို ကျော်ခြင်း။ သေးငယ်သော ပြောင်းလဲမှုများကလည်း အရာများ ပျက်စေပါတယ်။
• မှားသော tab တွင် စမ်းသပ်ခြင်း။ မြင်ရသော banner က ဖြေရှင်းပေးပါတယ်။

စစ်ဆေးစာရင်း

• Staging သည် production နှင့် code၊ stack နှင့် service တူညီစွာ run သည်။
• Staging တွင် test သို့မဟုတ် ရှင်းလင်းထားသော data ပါသော ကိုယ်ပိုင် database ရှိသည်။
• Payment၊ email နှင့် paid API များသည် staging တွင် test key သုံးသည်။
• Environment များတွင် variable အမည်များ တူညီသည်; တန်ဖိုးများသာ ကွဲပြားသည်။
• Staging သည် login သို့မဟုတ် password နောက်ကွယ်တွင်ရှိပြီး index မလုပ်ထား။
• Staging တွင် ရှိနေသည်ကို banner က ပြသသည်။
• ထုတ်ဝေမှုတိုင်း staging သို့ အရင်သွားပြီး စစ်ဆေးရမည့် flow စာရင်း ရေးထားသည်။
• Database ပြောင်းလဲမှုများကို staging တွင် အရင် run ပြီး release မတိုင်မီ production backup ရှိသည်။

Mythex ပေါ်ရှိ staging

Mythex ၏ Publish သည် အက်ပ်တစ်ခုစီအတွက် live URL တစ်ခုသာ ပေးပါတယ်; သီးခြား staging toggle မရှိပါ။ လက်တွေ့တွင် ရွေးချယ်စရာ နှစ်ခု ရှိပါတယ်:

• Preview ကို ထုတ်ဝေမီ စစ်ဆေးမှုအဖြစ် သုံးပါ။ Project တိုင်း private cloud workspace တွင် live Preview ဖြင့် run ပါတယ်။ /test က agent ကို အသုံးပြုသူကဲ့သို့ နှိပ်စေပြီး Share link က client သို့မဟုတ် ပူးပေါင်းသူက ထုတ်ဝေခြင်း မပြုဘဲ preview ကို သုံးသပ်ခွင့် ပေးပါတယ်။ Preview နှင့် Code ကို ကြည့်ပါ။ ကိုယ်တိုင် project အများအပြားအတွက် ဒါ လုံလောက်ပါတယ်။
• Staging အဖြစ် project ဒုတိယ။ Pro တွင် project ကို export လုပ်ပြီး project အသစ်တစ်ခုသို့ import လုပ်ပါ၊ ထို project ကို ကိုယ်ပိုင် database နှင့် test-key secret များ ပေးပြီး ကိုယ်ပိုင် slug ဖြင့် publish လုပ်ပါ။ Production project ကို မထုတ်မီ ၎င်းသို့ ထုတ်ပါ။

နည်းလမ်းနှစ်ခုလုံးတွင် ဖျက်ဆီးနိုင်သော စမ်းသပ်မှု မလုပ်မီ preview နှင့် published app က ဘယ် database ကို သုံးသလဲ agent ကို မေးပါ၊ မကောင်းသော ပြောင်းလဲမှုကို rollback ပြန်လုပ်ရန် checkpoint များကို သုံးပါ။ အက်ပ်ကို ပိုကျယ်ပြန့်စွာ live ဖြစ်အောင် လုပ်ရန် AI prototype ကို production သို့ ယူဆောင်နည်း ကို ကြည့်ပါ။

မေးခွန်းများ