Day 1 - Software Development ကို ပိုပြီးမြန်စေမယ့် CI/CD

Software တစ်ခုရေးပြီးပြီဆိုရင် "ငါ့စက်ထဲမှာတော့ အလုပ်လုပ်တယ်" ဆိုရုံနဲ့ မပြီးသေးပါဘူး။ User တွေသုံးမယ့် Server ပေါ်ရောက်အောင် တင်ပေးရပါတယ်။

အရင်တုန်းကတော့ Code အသစ်တွေ ရေးပြီးတိုင်း -

• Error ပါလား လိုက်စစ် (Manual Testing)
• ပြီးရင် Zip ဖိုင်ချုံ့၊ ဒါမှမဟုတ် Build ဆွဲ
• ပြီးမှ Server ထဲ FTP နဲ့ဖြစ်ဖြစ်၊ SSH နဲ့ဖြစ်ဖြစ် လှမ်းချိတ်ပြီး manually သွားတင်ရတယ်

အဲဒီလို လုပ်ရတာ တစ်ခါနှစ်ခါဆို အဆင်ပြေပေမယ့် Team ထဲမှာ လူတွေများလာရင်၊ ဒါမှမဟုတ် Code ကို ခဏခဏ update လုပ်ရရင် လက်ဝင်လွန်းလို့ အမှားအယွင်းတွေ ဖြစ်လာတတ်ပါတယ်။

အဲဒီပြဿနာကို ဖြေရှင်းဖို့ "အလုပ်တွေကို လူကိုယ်တိုင်မလုပ်တော့ဘဲ Automation လုပ်ခိုင်းမယ်" ဆိုတဲ့ Concept ပေါ်လာတာ။ အဲဒါကိုပဲ CI/CD လို့ ခေါ်ပါတယ်။

CI နဲ့ CD ကို တစ်ခုချင်း ခွဲကြည့်ရအောင်

1. CI (Continuous Integration) — အမှားပါလား Automation နဲ့ အရင်စစ်ခိုင်းမယ်

CI ဆိုတာ လွယ်လွယ်ပြောရရင် Developer တစ်ယောက် code ရေးပြီး GitHub/GitLab repository ထဲကို push လုပ်တိုင်း automation process တွေ run သွားပြီး အလိုအလျောက် စမ်းသပ်စစ်ဆေးပေးတဲ့ အပိုင်းပါ။

Code အသစ်တစ်ခု ရေးလိုက်တယ်၊ ပြီးရင် git push လုပ်လိုက်တာနဲ့ နောက်ကွယ်မှာ အလုပ်သမား စက်ရုပ်ကြီးတစ်ကောင်က ချက်ချင်း နိုးလာပြီး ဒီလိုတွေ လိုက်လုပ်ပေးတော့တာ။

• Code Quality စစ်တယ်: စာလုံးပေါင်းမှားတာ၊ Format မကျတာတွေ ပါလား လိုက်ကြည့်ပေးတယ်။

• Unit Test တွေ Run တယ်: Code ထဲက function တွေ အလုပ်လုပ်ရဲ့လားပေါ့။ (ဥပမာ- Python သုံးရင် pytest၊ JS သုံးရင် jest တို့နဲ့ စစ်တာ)

• Build & Artifact Generate လုပ်တယ်: Test တွေ အကုန် Pass ဖြစ်ပြီဆိုရင် Server ပေါ်တင်လို့ရမယ့် အဆင်သင့်ဖိုင် (Artifact) တွေအဖြစ် ပြောင်းပေးတယ်။ ဥပမာ- Docker Image ထုတ်တာ၊ ဒါမှမဟုတ် .jar, .zip ဖိုင်တွေ လုပ်တာပေါ့။ ပြီးရင် အဲဒီဖိုင်တွေကို Docker Hub သို့မဟုတ် AWS ECR လိုမျိုး Safe ဖြစ်တဲ့နေရာမှာ သွားသိမ်းပေးထားတယ်။

💡 ဒါကြောင့် CI ရဲ့ အဓိက အသက်က: Bug တွေကို အစောကြီးကတည်းက ကြိုသိရလို့ Production Server ပေါ်အထိ Error တွေ ပါမသွားအောင် တားပေးတာပဲ ဖြစ်ပါတယ်။

2. CD — Server ပေါ်ကို အလိုအလျောက် Deploy လုပ်ပေးမယ်

CI အဆင့်ပြီးလို့ Code က စိတ်ချရပြီဆိုရင် Server ပေါ်တင်မယ့် CD အဆင့် ရောက်လာပါပြီ။ CD မှာ Company ပေါ်မူတည်ပြီး ချဉ်းကပ်ပုံ နှစ်မျိုး ရှိပါတယ်။

1. Continuous Delivery (စိတ်ချရမှ Manual နှိပ်မယ်) - Code တွေကတော့ စစ်ပြီးသား၊ Build ပြီးသား။ Server ပေါ်တင်ဖို့ အဆင်သင့်ပဲ။ ဒါပေမဲ့ "လူကြီးမင်း Deploy လုပ်ဖို့ အဆင်သင့်ဖြစ်ပြီလား" ဆိုပြီး ခလုတ်လေးတစ်ခု လာပြနေမယ်။ Team Lead ဒါမှမဟုတ် မိမိက စိတ်ချပြီဆိုမှ "Deploy Production" ဆိုတဲ့ ခလုတ်ကို နှိပ်လိုက်တာနဲ့ Server ပေါ် ရောက်သွားတာမျိုး။ (လုပ်ငန်းခွင် အများစုက စိတ်ချရအောင် ဒီ model ကို သုံးကြပါတယ်)

2. Continuous Deployment (လူမလိုဘူး အကုန် Auto ပဲ) - ဒါကတော့ ပိုမိုက်တယ်။ git push လိုက်လို့ CI ထဲမှာ Test တွေအောင်သွားတာနဲ့ ဘယ်သူ့ကိုမှ ခွင့်ပြုချက်တောင်းမနေတော့ဘဲ Server ပေါ်ကို တိုက်ရိုက် Auto Deploy လုပ်ပစ်လိုက်တာ။ (SaaS Product တွေနဲ့ မြန်မြန်ဆန်ဆန် Feature အသစ်ထုတ်ချင်တဲ့ Startup တွေမှာ သုံးလေ့ရှိတယ်)

CI/CD Pipeline ဆိုတာ ဘာလဲ?

Pipeline ဆိုတာ အပေါ်က ပြောခဲ့တဲ့ အလုပ်တွေကို တစ်ဆင့်ချင်းစီ လုပ်သွားပေးတဲ့ Automation Workflow (Procedure) ကို ပြောတာပါ။

ဒီလို ပုံစံအတိုင်း အပေါ်ကနေ အောက်ကို Flow သွားတာပေါ့ -

1 [Code ကို Push လိုက်ပြီ] 
2        ↓
3 [Test တွေ အလိုအလျောက် Run] 
4        ↓
5 [App ကို Build ဆွဲ] 
6        ↓
7 [Docker Image ထုတ်ပြီး Registry ထဲသိမ်း] 
8        ↓
9 [Live Server ပေါ်သို့ Deploy လုပ်] 

Pipeline တစ်ခုမှာ ဘာတွေ ပါလဲ?

• Trigger : Pipeline ကို စတင်စေတဲ့ အကြောင်းအရင်း။ (ဥပမာ- git push လုပ်လိုက်တာ သို့မဟုတ် Pull Request ဆောက်လိုက်တာ)

• Jobs : Pipeline ထဲမှာ လုပ်ရမယ့် အပိုင်းကြီးတွေ။ (ဥပမာ- Test Job၊ Build Job၊ Deploy Job)

• Steps : Job တစ်ခုချင်းစီရဲ့ အတွင်းထဲက အဆင့်လေးတွေ။ (ဥပမာ- dependency တွေ install လုပ်မယ်၊ ပြီးမှ command ရိုက်ပြီး test run မယ်)

• Runner : ဒီ code တွေကို နောက်ကွယ်မှာ run ပေးနေတဲ့ Cloud ပေါ်က Server သို့မဟုတ် ကွန်ပျူတာကို ခေါ်တာပါ။ (GitHub Actions မှာဆို runs-on: ubuntu-latest လို့ ရေးရင် GitHub က ပေးတဲ့ Ubuntu စက်ပေါ်မှာ run သွားတာမျိုး)

အသုံးများတဲ့ CI/CD Tools များ

• GitHub Actions: အခုခေတ်မှာ လူသုံးအများဆုံးနဲ့ Beginner တွေအတွက် အလွယ်ဆုံးပဲ။ GitHub ထဲမှာတင် built-in ပါပြီးသားမို့ YAML ဖိုင်လေးတစ်ခု ရေးလိုက်ရုံနဲ့ အလုပ်လုပ်တယ်။

• GitLab CI/CD: GitLab သုံးတဲ့အဖွဲ့တွေအတွက် အကြိုက်။ အစွမ်းထက်ပြီး Container (Docker) တွေနဲ့ တွဲသုံးရတာ အရမ်းအဆင်ပြေတယ်။

• Jenkins: ကိုယ့် Server ထဲကိုယ် ထည့်သုံးရတာ (Self-hosted) ဖြစ်ပြီး ပလပ်အင် (Plugins) တွေ စုံလွန်းလို့ အကြီးစားလုပ်ငန်းတွေမှာ သုံးကြတုန်းပဲ။ Old but powerful !

• CircleCI / Azure DevOps: ဒါတွေကတော့ cloud workflow တွေနဲ့** Enterprise** ပိုင်းတွေမှာ အသုံးများပါတယ်။

အနှစ်ချုပ်ရရင်တော့ - CI က code quality နဲ့ automation testing ကို focus လုပ်ပြီး၊ CD ကတော့ စိတ်ချရတဲ့ code တွေကို Server ပေါ် အလိုအလျောက် တင်ပေးတာပါ။ ဒီ Concept ကို နားလည်သွားရင် စာဖတ်သူ ညီအကိုမောင်နှမများလည်း Modern Developer တစ်ယောက် ဖြစ်ဖို့ လမ်းစပေါ် ရောက်သွားပါပြီ! အားလုံးပဲ Happy Coding ဗျာ။

ဒီနေ့ Day 1 မှာတော့ CI/CD ရဲ့ သဘောတရားတွေကို အကြမ်းဖျင်း နားလည်သွားကြပြီလို့ မျှော်လင့်ပါတယ်။ စာဖတ်ရုံတင်ဆိုရင်တော့ ပျင်းစရာကြီး ဖြစ်နေမှာပေါ့။

ဒါကြောင့် နောက်တစ်ပတ် Day 2 မှာတော့... အခုခေတ်မှာ အသုံးအများဆုံး ဖြစ်တဲ့ GitHub Actions ကို သုံးပြီး တကယ့် လက်တွေ့ Lab တစ်ခုကို အစကနေ အဆုံးအထိ အတူတူ ဆောက်ကြည့်ကြပါမယ်။

• ကိုယ့်ရဲ့ GitHub Repository ထဲမှာ Workflow ဖိုင်ကို ဘယ်လို ဆောက်ရမလဲ?

• git push လိုက်တဲ့အခါ နောက်ကွယ်မှာ Test တွေ၊ Build တွေ အလိုအလျောက် ဘယ်လို Run သွားလဲ?

• Pipeline အောင်မြင်သွားတဲ့ အခါမှာရော ဘယ်လို မြင်ရမလဲ?

ဆိုတာတွေကို တဆင့်ချင်းစီ လက်တွေ့ လုပ်ကြည့်ကြမှာမို့လို့ နောက်တစ်ပတ်မှာ ပြန်ဆုံကြရအောင်ဗျာ။ Stay tuned guys!