အင်္ဂါရပ်များ

စမ်းသပ်ဆော့ဖ်ဝဲလ် (Staging)၊ ပွက်ရှ်-တူ-လစ် (push-to-live) နှင့် git ချိတ်ဆက်ဖြန့်ချိမှုများ

တစ်ချက်နှိပ်ရုံဖြင့် စတေဂျင်း မိတ္တူတစ်ခုကို တည်ဆောက်ပြီး သင့်ပြောင်းလဲမှုများကို လုံခြုံစွာ စမ်းသပ်ပါ၊ ထို့နောက် အဆင်သင့်ဖြစ်သောအခါ တိုက်ရိုက်ဆာဗာသို့ ပို့ဆောင်ပါ။ git ဝန်ဆောင်မှုပေးသူတစ်ဦးကို ချိတ်ဆက်ထားပါက တွန်းပို့မှုတိုင်းသည် မိမိဘာသာ တည်ဆောက်ပြီး ဖြန့်ကျက်ပေးပါမည်။ တစ်စုံတစ်ရာ မှားယွင်းသွားပါက ယခင်ထုတ်ဝေမှုသို့ စက္ကန့်ပိုင်းအတွင်း ပြန်ပြောင်းပါ။

  • ၁-ချက်နှိပ်စမ်းသပ်ပြင်ဆင်မှု ဝန်းကျင်နှင့် ပင်မဝဘ်ဆိုက်သို့ လွှင့်တင်မှု
  • 99.99%လုပ်ငန်းလည်ပတ်ချိန် အာမခံချက်
  • ထောက်င့်ပံ့ထားသော Git ပံ့ပိုးပေးသူများ

စမ်းသပ်မှုများကို စတေဂျင်းတွင် ပြုလုပ်ပါ၊ ယုံကြည်မှုအပြည့်ဖြင့် ဖြန့်ချိပါ

ဝက်ဘ်ဆိုက်တိုင်းတွင် အမှန်တကယ်အတည်ပြုနိုင်သော အပြည့်အစုံပါရှိသည့် စမ်းသပ်မှုပတ်ဝန်းကျင် (staging environment) တစ်ခု ရရှိမည်ဖြစ်ပြီး မှန်းဆနေစရာ မလိုတော့ပါ။ ပရိုဒက်ရှင်ကို ကူးယူပါ၊ စာသားအပေါ် လုပ်ဆောင်ပါ၊ ထို့နောက် သက်သေပြပြီးသောအခါ သင့်ပြောင်းလဲမှုများကို ပြန်လည်ပေါင်းထည့်ပါ။

တစ်ချက်နှိပ် စတေ့ဂျင်းတင်ခြင်း

ထုတ်လုပ်ရေးပတ်ဝန်းကျင်နှင့် တူညီသော စတက်ခ်နှင့် ဘလူးပရင့်ပေါ်တွင် သင့်ဖိုင်များနှင့် ဒေတာဘေ့စ်များ မူလအတိုင်းပါရှိသော တိုက်ရိုက်ဆိုက်၏ စမ်းသပ်မိတ္တူ (staging copy) တစ်ခုကို ဖန်တီးပါ၊ သို့မှသာ သင်စမ်းသပ်သမျှသည် သင်တင်ပို့မည့်အရာ ဖြစ်လာမည်ဖြစ်သည်။

တိုက်ရိုက်လွှင့်တင်ရန်

သင့်ပြောင်းလဲမှုများ အဆင်သင့်ဖြစ်သောအခါ စတေ့ဂျင်းမှ ပရိုဒက်ရှင်သို့ တစ်ချက်နှိပ်ရုံဖြင့် တွန်းပို့ပါ။ ဖိုင်များကို ကိုယ်တိုင်ကူးယူရန် မလိုပါ၊ အားနည်းသော ဒေတာဘေ့စ် တင်ပို့မှုများလည်း မလိုပါ။

ယခင်ထုတ်ဝေမှုသို့ ပြန်ပြောင်းရန်

ဖြန့်ချိမှုတိုင်းသည် ဗားရှင်းသတ်မှတ်ထားသော ထွက်ရှိမှုတစ်ခုဖြစ်သည်။ အပြောင်းအလဲတစ်ခု အလုပ်မလုပ်တော့ပါက ပြန်လည်ရယူရေးလက်မှတ်မပါဘဲ ယခင်ကောင်းမွန်သည်ဟုသိထားသည့် ထွက်ရှိမှုဆီသို့ တိုက်ရိုက်ပြန်သွားပါ။

စက်ဝိုင်းတိုင်းအတွက် တူညီသော အလုပ်စဉ်

Managed WordPress, WooCommerce, PHP၊ တည်ငြိမ်သော HTML သို့မဟုတ် Node — စတိတ်ဂျင်းနှင့် တိုက်ရိုက်ထုတ်လွှင့်ခြင်း (push-to-live) တို့သည် သင်၏ဆိုက်များအားလုံးတွင် အတူတူပင် လုပ်ဆောင်ပါသည်။

Git အခြေခံသော ဆက်တိုက်ဖြန့်ချိခြင်း

Git ပံ့ပိုးပေးသူတစ်ဦးကို တစ်ကြိမ်ချိတ်ဆက်လိုက်ရုံဖြင့် သင့်၏ သိုလှောင်ခန်း (repository) သည် အဓိက အချက်အလက်အရင်းအမြစ် ဖြစ်လာမည်ဖြစ်သည်။ ကုဒ်များကို တွန်းပို့ (push) လိုက်ပါက ပလက်ဖောင်းက သင့်အတွက် တည်ဆောက်ပြီး ဖြန့်ဝေပေးပါမည်။

GitHub၊ GitLab သို့မဟုတ် Bitbucket ကို OAuth မှတစ်ဆင့် ချိတ်ဆက်လိုက်ပါက သင်၏ deploy keys များကို ပုံမှန် configuration ထဲတွင် မဟုတ်ဘဲ ကုဒ်ဝှက်ထားသော credential store တွင် သိမ်းဆည်းပေးမည် ဖြစ်သည်။ site ပေါ်သို့ မတင်မီ သင်၏ stack အတွက် build အဆင့်များကို လုပ်ဆောင်ပေးသည့် (Composer၊ npm နှင့် အခြားသော) တာရှည်ခံ build-and-deploy pipeline တစ်ခုကို တွန်းအားပေးသည့် webhook တစ်ခုသည် push ပြုလုပ်တိုင်း အလုပ်လုပ်မည် ဖြစ်သည်။

သင့်အဖွဲ့အစည်း လက်ရှိအလုပ်လုပ်နေသည့်ပုံစံအတိုင်း အခွဲများကို ပတ်ဝန်းကျင်များနှင့် ချိတ်ဆက်ပါ - main ကို production သို့၊ staging ကို staging သို့၊ သို့မဟုတ် သင်နှစ်သက်ရာ အခြားပုံစံအတိုင်း ချိတ်ဆက်ပါ။ အခွဲတစ်ခုသို့ ပေါင်းထည့်လိုက်ရုံဖြင့် ကိုက်ညီသောပတ်ဝန်းကျင်သည် သူ့အလိုလို အပ်ဒိတ်ဖြစ်သွားမည်ဖြစ်ရာ အပြောင်းအလဲတစ်ခုကို တင်မြှင့်ရန်အတွက် git push တစ်ခုလုပ်ရုံသာ လိုအပ်ပါသည်။

  • OAuth မှတစ်ဆင့် GitHub၊ GitLab သို့မဟုတ် Bitbucket ကို ချိတ်ဆက်ပါ၊ ဖြန့်ကြက်မှု ကီးများကို အထောက်အထား သိမ်းဆည်းရာနေရာတွင် ထိန်းသိမ်းထားသည်။
  • Push ပြုလုပ်ချိန်ရှိ Webhook သည် ခိုင်မာစိတ်ချရသော တည်ဆောက်ပြီး-ဖြန့်ကျက်သည့် ပိုက်လိုင်းကို စတင်ပေးပါသည်
  • စက်ဝိုင်းအလိုက် တည်ဆောက်မှုအဆင့်များ (Composer၊ npm နှင့် အခြားအရာများ) ကို အလိုအလျောက် လုပ်ဆောင်ပေးသည်
  • Branch-to-environment mapping — ဥပမာ main မှ production သို့၊ staging မှ staging သို့
  • လိုအပ်လာသည့်အခါ မည်သည့် ယခင်ထုတ်ဝေမှုသို့မဆို ပြန်ပြောင်းနိုင်သည်
  • ဖြန့်ချိမှုများသည် တာရှည်ခံပြီး ပြန်လည်လုပ်ဆောင်နိုင်သော ဝပ်ဖ်လိုများအဖြစ် လုပ်ဆောင်သောကြောင့် တည်ဆောက်မှုအလယ်တွင် ချို့ယွင်းချက်တစ်ခု ဖြစ်ပေါ်လာပါက တစ်ဝက်တစ်ပျက်သာ ဖြန့်ချိထားသည့် ဆိုက်ကို ဘယ်သောအခါမှ မဖြစ်ပေါ်စေပါ။

သင် တည်ဆောက်ပုံအတိုင်း တည်ဆောက်ရန် ဖန်တီးထားသည်

စဉ်ဆက်မပြတ် ဖြန့်ကျက်ခြင်းဆိုသည်မှာ ထိန်းချုပ်မှုကို လက်လွှတ်လိုက်ခြင်း မဖြစ်သင့်ပါ။ မည်သည့် ဘရန့်ချ် (branch) က မည်သည့် ပတ်ဝန်းကျင် (environment) နှင့် ချိတ်ဆက်မည်၊ အပြောင်းအလဲတစ်ခုကို မည်သည့်အခါတွင် အဆင့်မြှင့်တင်မည်၊ နှင့် မည်သည့်အခါတွင် မူလအခြေအနေသို့ ပြန်သွားမည်ဆိုသည်တို့ကို သင်ကိုယ်တိုင် ဆုံးဖြတ်နိုင်ပါသည်။ ပိုက်လိုင်း (pipeline) သည် ကုဒ်ကို ရယူခြင်း (pulling code)၊ ဘစ်ခ် တည်ဆောက်ခြင်း (running builds)၊ အပြည့်အစုံ ဖြန့်ချိခြင်း (releasing atomically) စသည့် စက်ပိုင်းဆိုင်ရာ လုပ်ငန်းများကို လုပ်ဆောင်ပေးသောကြောင့် ဖြန့်ကျက်မှုတစ်ခုသည် ပုံမှန်၊ ထပ်တလဲလဲ လုပ်ဆောင်နိုင်ပြီး ပြန်ပြောင်းလဲနိုင်သော လုပ်ငန်းစဉ်တစ်ခု ဖြစ်လာမည် ဖြစ်ပါသည်။

ကျွန်ုပ်တို့၏ AI Pack ကို အသုံးပြုပါက လက်ထောက်သည် ကုဒ်ပြောင်းလဲမှုများကို ပြုလုပ်နိုင်ပြီး ၎င်းတို့ကို တူညီသောပိုက်လိုင်းမှတစ်ဆင့် သင်၏ဆိုက်များသို့ တွန်းပို့နိုင်သောကြောင့် AI ရေးသားသည့် အပြောင်းအလဲတစ်ခုသည် သင်ကိုယ်တိုင်ရေးသားသည့်အရာကဲ့သို့ တိကျစွာတူညီသော တည်ဆောက်မှု၊ ဖြန့်ဝေမှုနှင့် နောက်ပြန်လှည့်သည့်လမ်းကြောင်းအတိုင်း ဖြတ်သန်းသွားမည်ဖြစ်ပါသည်။

မကြာခဏ မေးလေ့ရှိသော မေးခွန်းများ

တစ်ချက်နှိပ်ကာ စတိတ်ဂျင်းပြုလုပ်ခြင်းက ဘယ်လိုအလုပ်လုပ်ပါသလဲ။

Staging သည် သင့်၏ လက်ရှိ တိုက်ရိုက်ဆိုက် (live site) – ဖိုင်များနှင့် ဒေတာဘေ့စ် – အား ပရိုဒက်ရှင် (production) နှင့် တူညီသော စတက် (stack) နှင့် ဘလူးပရင့် (blueprint) ပေါ်တွင် မိတ္တူအပြည့်အစုံ ဖန်တီးပေးပါသည်။ သင်သည် ထိုမိတ္တူပေါ်တွင် အပြောင်းအလဲများကို စမ်းသပ်နိုင်ပြီး၊ ထို့နောက် push-to-live ကို အသုံးပြု၍ လုပ်ဆောင်ချက်တစ်ခုတည်းဖြင့် ပရိုဒက်ရှင်သို့ တင်ဆောင်နိုင်ပါသည်။

မည်သည့် git ပံ့ပိုးပေးသူများကို ကျွန်ုပ် ချိတ်ဆက်နိုင်သနည်း။

GitHub, GitLab နှင့် Bitbucket တို့ဖြစ်သည်။ သင်သည် OAuth မှတစ်ဆင့် ချိတ်ဆက်ပြီး သင့်၏ deploy keys များကို plain config ဖိုင်များတွင်မဟုတ်ဘဲ ကုဒ်ဝှက်ထားသော credential store တွင် သိမ်းဆည်းထားသည်။

ကျွန်ုပ် ကုဒ်ကို ပို့လိုက်သောအခါ ဘာဖြစ်မည်နည်း။

ဝဘ်ဟွတ်ခ် (webhook) သည် push ပြုလုပ်ချိန်တွင် စတင်အလုပ်လုပ်ပြီး ရေရှည်ခိုင်မာသော ဆောက်လုပ်-ဖြန့်ကြက်မှု ပိုက်လိုင်း (build-and-deploy pipeline) ကို စတင်ပေးသည်။ ၎င်းသည် သင်၏ စတက်ခ် (stack) ဖြစ်သော Composer၊ npm နှင့် အခြားအရာများအတွက် ဆောက်လုပ်မှုအဆင့်များကို လုပ်ဆောင်ပေးပြီး ထိုဘရန့်ချ် (branch) နှင့် ချိတ်ဆက်ထားသော ပတ်ဝန်းကျင် (environment) ထံ ရလဒ်ကို ထုတ်လုပ်ဖြန့်ချိပေးသည်။

မွဲးမွဲး သီးသန့် ဘရန့် (branch) များကို ပတ်ဝန်းကျင် (environment) အမျိုးမျိုးသို့ ချိတ်ဆက်နိုင်ပါသလား။

ဟုတ်ပါတယ်။ Branch-to-environment mapping ကြောင့် သင်သည် ဥပမာအားဖြင့် main ကို production သို့လည်းကောင်း၊ staging ကို staging သို့လည်းကောင်း ညွှန်ပြပေးနိုင်ပါတယ်။ branch တစ်ခုသို့ merge လုပ်လိုက်သည်နှင့် သက်ဆိုင်ရာ environment သည် အလိုအလျောက် deploy ဖြစ်သွားပါလိမ့်မည်။

ဖြန့်ချိမှုတစ်ခုက ဆိုက်ကို ပျက်စီးစေရင် ဘယ်လိုလုပ်မလဲ။

Deploy လုပ်ဆောင်မှုတိုင်းသည် ဗားရှင်းသတ်မှတ်ထားသော ထုတ်လုပ်မှုတစ်ခုဖြစ်သောကြောင့် သင်သည် ပြန်လည်ရယူရေးတောင်းဆိုလွှာ (restore ticket) မလိုဘေး ယခင်ထုတ်လုပ်မှုသို့ မူလအတိုင်း ပြန်ပြောင်းနိုင်သည်။ Deploy လုပ်ဆောင်မှုများသည် ခိုင်မာပြီး ပြန်လည်ကြိုးစားနိုင်သော လုပ်ငန်းစဉ်များအဖြစ် လည်ပတ်သောကြောင့် Build ပြုလုပ်နေစဉ် လမ်းဝက်တွင် ပျက်ကွက်သွားခဲ့လျှင်ပင် ဝက်ဘ်ဆိုက်ကို တစ်ဝက်တစ်ပျက် တင်ကျန်ခဲ့သည့်အခြေအနေမျိုး မည်သည့်အခါမျှ ဖြစ်ပေါ်စေမည်မဟုတ်ပါ။

ဇာတ်လမ်းမရှုပ်ဘဲ အပြောင်းအလဲများကို တင်ပို့ပါ

စတိတ်ရှ်လုပ်ပါ၊ လိုက်ဗ်တင်ရန် တွန်းပို့ပါ (push-to-live) နှင့် git မှ ဒေပလွိုင်း (deploy) လုပ်ပါ။ ကတ်မလိုသော ၁၄ ရက် စမ်းသပ်ကာလ၊ ရက် ၃၀ ငွေပြန်အမ်းပေးသည့် အာမခံချက်၊ အခမဲ့ ဒေတာကူးပြောင်းမှုများနှင့် ရောင်းချသူကို မှီခိုနေရခြင်း မရှိပါ။

အခမဲ့ စတင်ပါ