Git-based Deployment နှင့် CI/CD

နားလည်ထားရမယ့် အချက်

Pattern တွေထဲက တစ်ခုက git repository တစ်ခုကို hosting platform တစ်ခုနဲ့ တိုက်ရိုက် ချိတ်ဆက်ထားတာပါ — code push လုပ်တာ ဒါမှမဟုတ် pull request merge လုပ်တာက manual upload step ဘာမှမလိုပဲ automatic deployment ကို trigger လုပ်ပါတယ်။

Step တစ်ခုချင်းစီက နောက်တစ်ခုကို gate လုပ်ပါတယ် — step တစ်ခု fail ဖြစ်ရင် broken code ကို production ဆီ ရောက်စေမယ့်အစား deployment ကို ရပ်တန့်ပေးပါတယ်။

Preview deployment ကတော့ ဆက်စပ်တဲ့ pattern တစ်ခုပါ — pull request တစ်ခု ဖွင့်လိုက်တာနဲ့ merge မလုပ်ခင် reviewer တွေ running change အစစ်ကို click ကနေ ကြည့်ရှုနိုင်တဲ့ temporary, share လုပ်လို့ရတဲ့ URL တစ်ခု automatic ရရှိပါတယ်။

ဒီ lesson က orientation level မှာသာ ထားထားပါတယ် — pipeline YAML၊ caching၊ matrix build၊ secret၊ approval gate တွေကို CI/CD with GitHub Actions tutorial မှာ အသေးစိတ်ဆွေးနွေးထားပြီး git workflow ကိုယ်တိုင်ကို Git & GitHub tutorial မှာ ပါဝင်ပါတယ်။

GIT PUSH TO CI TO DEPLOY TO PRODUCTION
--------------------------------------
git push --> [lint] --> [test] --> [build] --> deploy --> prod

PULL REQUEST BRANCH:
git push (PR) --> CI checks --> preview URL --> merge --> prod

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Git-based deployment setup လုပ်တာက ပုံမှန်အားဖြင့် hosting platform ကို repository တစ်ခုနဲ့ တစ်ကြိမ်တည်း ချိတ်ဆက်ပြီး production ဆီ branch ဘယ်ဟာ map လုပ်မလဲ (ပုံမှန် main) ရွေးကာ default build setting တွေက ကျန်တာ ကိုင်တွယ်စေခြင်းပါ။

ပြီးနောက် နေ့စဉ် workflow က code push လုပ်ရုံပဲ ဖြစ်လာပါတယ် — manual step သီးခြားမလိုပဲ deployment က နောက်ကွယ်မှာ automatic ဖြစ်သွားပါတယ်။

Fail ဖြစ်တဲ့ check တစ်ခုကို route around လုပ်စရာမဟုတ်ပဲ merge မလုပ်ခင် ပြင်ရမယ့်အရာအဖြစ် သဘောထားပါ — check တွေနောက်ကွယ်မှာ deployment gate လုပ်ထားတဲ့ point တစ်ခုလုံးက production မရောက်ခင် ပြဿနာကို ဖမ်းမိဖို့ပါ။

Main ဆီ တိုက်ရိုက် push မလုပ်ပဲ pull request ဖွင့်တာက ကိုယ်တိုင် sanity-check လုပ်ဖို့ preview URL ပေးပြီး user အစစ်မရောက်ခင် teammate တွေအတွက်လည်း အခွင့်အရေးတူ ပေးပါတယ်။

• Git ကို hosting platform နဲ့ ချိတ်ဆက်ထားတာက push ဒါမှမဟုတ် merge တစ်ခုကို automatic build-and-deploy pipeline တစ်ခု ဖြစ်စေပါတယ်။
• CI က push တိုင်းမှာ lint/test/build ကနေ ပြဿနာကို ဖမ်းမိပြီး check တွေ pass ပြီးရင် CD က result ကို ship ပေးပါတယ်။
• Preview deployment တွေက pull request တစ်ခုကို ကိုယ်ပိုင် live URL ပေးလို့ change တစ်ခုက raw code အနေနဲ့သာမက running အနေနဲ့ပါ review ဖြစ်ပါတယ်။

အတူတူ စမ်းရေးကြည့်မယ်

function runPipeline(steps) {
  for (const step of steps) {
    console.log(`Running: ${step.name}...`);
    if (!step.passes) {
      console.log(`Failed at: ${step.name}. Deployment stopped.`);
      return false;
    }
  }
  console.log("All steps passed. Deploying to production.");
  return true;
}

const goodPipeline = [
  { name: "lint", passes: true },
  { name: "test", passes: true },
  { name: "build", passes: true },
];

const badPipeline = [
  { name: "lint", passes: true },
  { name: "test", passes: false },
  { name: "build", passes: true },
];

console.log("--- Passing run ---");
runPipeline(goodPipeline);

console.log("--- Failing run ---");
runPipeline(badPipeline);

--- Passing run ---
Running: lint...
Running: test...
Running: build...
All steps passed. Deploying to production.
--- Failing run ---
Running: lint...
Running: test...
Failed at: test. Deployment stopped.
(Failing run မှာ 'build' step ကို ဘယ်တော့မှ run မကြည့်ပါဘူး — 'test' step fail ဖြစ်တာနဲ့ pipeline က ချက်ချင်း ရပ်တန့်သွားလို့ပါ)

Continuous integration — MDN Web Docs Glossary — Cloud & Deployment