Continuous Integration
Continuous Integration ကို CI လို့ အတိုကောက် ခေါ်ကြပါတယ်။ CI/ CD ဆိုပြီး တွဲပြီး ကြားဖူးကြမှာပါ CD ကတော့ continuous deployment/ delivery ကိုဆိုလိုတာဖြစ်ပါတယ်။ ဒီ post မှာတော့ CI က CD မပါပဲလည်း သူချည်းသက်သက် အလုပ်ဖြစ်နိုင်ကြောင်းနဲ့ CI ရဲ့ flow ကို ပြောသွားပါမယ်။
အဓိက CI ရဲ့ first step ကတော့ code ပေါင်းတာဖြစ်ပါတယ်။ Developer တွေ ၂ ယောက်ထပ်ပိုပြီး repository တစ်ခုကို တစ်ရက်မှာ အကြိမ်ရေများစွာ code တွေ commit နေပြီး manual testing မနိုင်တော့ဘူးဆိုရင် CI ကို စသုံးဖို့ လိုအပ်လာပါတယ်။
CI ကို သုံးဖို့အတွက် tools တွေ အမျိုးမျိုးရှိပါတယ် company တစ်ခုနဲ့တစ်ခုလည်း သုံးတာတွေချင်းမတူနိုင်ဘူး ဒါပေမယ့် သူတို့ရဲ့ flow ကတော့ ကိုယ် configure လုပ်ထားတဲ့အပေါ်ပဲ မူတည်နေမှာပါ။ Popular အဖြစ်ဆုံး CI tool ကတော့ Jenkins ဖြစ်ပြီး နောက်ပိုင်း GitHub Action ကိုလည်း သုံးလာကြပါတယ် နောက်ထပ်အများကြီး ရှိပါသေးတယ် ဒီမှာတော့ list မရေးပြတော့ပါဘူး။
ယေဘုယျအားဖြင့် CI pipeline မှာ Build -> Test -> Result ဆိုပြီးရှိတယ်။ ဘယ်လိုပဲ configuration တွေကွဲပါစေ ဒီ step တွေကတော့တူတူပါပဲ။ အဲ့လို step by step automate လုပ်သွားရအောင် CI tool မှာ configuration လုပ်ရတယ် များသောအားဖြင့် YAML file နဲ့လုပ်ပါတယ်။
အရင်ဆုံး build process အတွက် configuration file ထဲမှာ code ကို repository ထဲ commit တင်တာနဲ့ build မလား pull request ကို merge မှ build မလား ရေးပေးလို့ရတယ်။ Build ပြီးရင် testing တွေ သူ့ဘာသူ automate ပြီး run မယ်၊ တစ်ခုခု fail ရင် developer ဆီ notification ပို့ပေးမယ်။ Email နဲ့လည်းပို့သလို Slack chat ကနေလည်း ပို့အောင် လုပ်နိုင်ပါတယ်။
သူ့ရဲ့ pipeline flow ကို အသေးစိတ် ကြည့်ကြည့်ရအောင်
📌 CI Pipeline Flow
- First step အနေနဲ့ CI tool က repository ပေါ်မှာ code update ရှိမရှိ check ပါလိမ့်မယ်။ အဲ့ဒါက အပေါ်ကပြောတဲ့ commit တင်တိုင်းလား branch ကို merge မှလား configure ထားတဲ့ build script အပေါ်မူတည်ပါတယ်။
- Code update တွေ့တာနဲ့ compile လုပ်ပြီး build စလုပ်ပါတယ်။ ဒီ step မှာ project build fail ရင် developer ကို notify လုပ်နိုင်ပါတယ်။
Get Soe Tint Aung’s stories in your inbox
Join Medium for free to get updates from this writer.
- Build ပြီးတာနဲ့ testing စလုပ်ပါပြီ။ Testing တွေကတော့ Unit Test, Integration/ Functional Test, Regression Test အကုန်ပါဝင်နိုင်တယ် အားလုံး တစ်ခုပြီးမှ တစ်ခုဆက် run ကြပါတယ်။ (Testing တွေအကြောင်း အသေးစိတ် နောက်မှ ထပ်ရေးပါဦးမယ်)
- Testing phase မှာ code quality စစ်တဲ့ step လည်း ပါနိုင်ပါတယ်။ ဒီ step ကတော့ SonarQube or ESLint တစ်ခုခုသုံးပြီး ကိုယ်ရေးတဲ့ code ရဲ့ quality ကို auto စစ်ပေးပါလိမ့်မယ်
- Testing တွေအားလုံး pass ပြီးတဲ့အခါ ကိုယ်က docker သုံးထားရင် docker image build လုပ်ပေးပြီး အဲ့ဒီ image ကို image registry ပေါ် တင်ပေးပါလိမ့်မယ်။ Docker မသုံးရင်လည်း deploy လုပ်ဖို့အတွက် artifact ကို ready အနေအထား တစ်နေရာရာမှာ store လုပ်ဖို့ configure လုပ်ထားနိုင်ပါတယ်။ ကိုယ့် project က Continuous Delivery ပါသုံးနေရင်တော့ CD ရဲ့ flow က ဒီ testing အပြီးမှာ စပါလိမ့်မယ် (CD အကြောင်း သက်သက်ထပ်ရေးပါမယ်)
- နောက်ဆုံးကတော့ test results တွေ notification ပို့တဲ့ step ပါပဲ။ ဒီ notification ကို test case တစ်ခု fail တိုင်း ပို့အောင် setup လုပ်နိုင်သလို test တွေ အားလုံး pass ပြီးမှ ပို့အောင်လည်း configure လုပ်နိုင်ပါတယ်။
အပေါ်ကပြောခဲ့တဲ့ developer code ကို commit တင်တဲ့ အချိန်ကလွဲလို့ test results ရတဲ့အထိ step အားလုံးက automatically run သွားတာဖြစ်ပါတယ်။
အဲ့တော့ tester တွေ မလိုတော့ဘူးလား?
Tester တွေ QA Engineer တွေက လိုပါသေးတယ်။ သူတို့ရဲ့ responsibility က manual test လုပ်တာတွေကနေ ဒီ CI pipeline မှာ run မယ့် testing တွေအတွက် test case ရေးရတာမျိုး ဖြစ်သွားပါတယ်။ Unit test ကတော့ developer တွေရေးကြတာများပြီး Functional, E2E test တွေကတော့ QA တွေက scenario အမျိုးမျိုးနဲ့ အကုန် cover ဖြစ်အောင်ရေးရပါတယ်။
CI သုံးလိုက်တာနဲ့ human mistakes ကြောင့် လွတ်သွားတဲ့ scenario တို့ မစစ်လိုက်ရတာတို့ မရှိသလောက်ဖြစ်သွားတယ်၊ new code ကို merge လိုက်တိုင်း project တစ်ခုလုံး auto စစ်ပေးနေတဲ့ system ရှိသွားတာကြောင့် တစ်ခုခု အလုပ်မလုပ်တော့တာမျိုး စိတ်မပူရတော့ဘူး။ လူကိုယ်တိုင် ဒီ function တစ်ခုကို ထပ်တလဲလဲ စစ်နေရတဲ့ boring task ကြီးပျောက်သွားပါတယ်။
ကိုယ့်ရဲ့ side project လေးမှာ CI ကိုစမ်းချင်ရင် GitHub action နဲ့ အရင်စမ်းနိုင်ပါတယ် အများဆုံး လုပ်ရမှာကတော့ test case ရေးတာတွေ ပဲဖြစ်လိမ့်မယ်။ Development ကနည်းပြီး test case တွေရေးဖို့ အချိန်ပိုပေးရပါမယ်။
Post ကို အရမ်းရှည်ပြီး မရှုပ်သွားအောင် CD ကို နောက်မှ သက်သက်ခွဲပြီး ပြောပါမယ်။
🧑🏻💻 Written by <YeMin-Dev />
#cicd
