CI/CD pipeline ဆိုတာ တကယ်တမ်း ဘာတွေလဲ

ဟိုးအရင်တုန်းက software development project တွေကို စက်ရုံတွေရဲ့ assembly line လိုပဲ မြင်ခဲ့ကြတယ်။ ရေးမယ့် software အတွက် requirement ကောက်၊ blueprint ထုတ်၊ ပြီးရင် အဲဒီ blueprint အတိုင်း code ရေး၊ ကျေနပ်တဲ့အထိ test တွေစစ်၊ စိတ်ချရပြီဆို production server တွေပေါ် ပို့လိုက်ပြီပေါ့။ တဆင့်ချင်းစီကို အကြာကြီး လုပ်ကြရတာမို့ ရှေ့တဆင့်မှာ တခုခုမှားနေတယ်ဆိုတာ နောက်ပိုင်းအဆင့်တွေမှ သိရလို့က အချိန်တွေ ပလုံပေရော့ပဲ။ ရေတံခွန်လိုမျိုး ပြန်ဆန်ကူးလို့ တကယ်မလွယ်တဲ့ ပုံစံဖြစ်လို့ ဒါကို waterfall လို့ ခေါ်ခဲ့ကြတယ်။

waterfall model မှာ code ရေးရတဲ့ development phase က software တွေမှိုလိုမပေါက်ခင်က အချိန်နဲ့ လူအင်အား အများဆုံး သုံးရတဲ့နေရာပဲ။ developer တွေက module နဲ့ feature တွေကို သင့်တော်သလို ခွဲပြီး အစုလိုက် တာဝန်ယူ ရေးကြတယ်။ လနဲ့ချီကြာတယ်။ ရေးပြီး အချိန်တန်လို့ Git လိုမျိုး Central VCS မှာအကုန် merge တဲ့အခါမှ ပြဿနာပေါင်း သောင်းခြောက်ထောင်စတော့တယ်။

code က သက်ဆိုင်ရာအုပ်စုအလိုက် တခါတလေ member တွေ အချင်းချင်း ကြားမှာတောင် collaboration လုပ်တာ မရှိပဲ ရေးထားတဲ့ code တွေဖြစ်လို့ merge conflict တွေမှ စီနေတာပဲ။ code အကြောင်းရေ သောင်းချီတဲ့ကြားက အဲဒါတွေကို resolve လုပ်ရတာနဲ့တင် fulltime job တခုဖြစ်သွားလိမ့်မယ်။ ပိုဆိုးတာက integration test တွေ fail တဲ့အခါ ဘယ်နားကဟာကို ဘယ်လိုရှာပြင်ရမလဲလို့တောင် မသိနိုင်ဘူး။ မသိဆို ရေးခဲ့တဲ့ code တွေက ၃ လ၊ ၄ လ၊ ၈ လကြာသွားပြီလေ။ ဘုရားနဲ့ကိုယ်ပဲ သိခဲ့တဲ့ code တွေက အခုကျ ဘုရားပဲ သိတော့တယ်။

အဲဒီပြဿနာကို ကိုင်တွယ်တဲ့နည်းက ရိုးရိုးလေးနဲ့ တကယ် တာသွားတယ်။ code တွေကို လနဲ့ချီအောင်ထားပြီးမှ VCS (GitHub, GitLab စသဖြင့်) ကို merge မယ့်အစား နေ့တိုင်း merge ကြမယ်။ တရက်ကို ၂ ခါလုပ်နိုင်ရင် ပိုတောင်ဂွတ်။ ဒါဆို code အကြောင်း 1000 လောက်စာ merge conflict မျိုးတွေရှင်းစရာလည်း မလိုတော့ဘူး။ အလွန်ဆုံးရှိလှ 50 ပေါ့။ Bug တွေပါကုန်မှာလည်း ပူစရာ မလိုဘူး။ Git push ဆိုတာနဲ့ test suite တွေအကုန် run ဖို့လုပ်ထားလိုက်မယ်။ Error တွေ့လို့က အိမ်သာခဏ လုပ်လို့မရဘူး။ အရင်ပြင်ပဲ။

ဆိုတော့ ဒီအတွက် technology ဖက်ကရော ဘာတွေလုပ်ပေးရဖို့ရှိလဲ။

ဘာလို့ဆို GitHub repository တွေကို တနေကုန် ထိုင်ကြည့်ပြီး commit အသစ်တွေ့ရင် pull လိုက်၊ test လေးတွေ run လိုက်၊ error ပါရင် developer တွေကို သွားရစ်လိုက်လုပ်ဖို့အတွက်နဲ့တော့ position တခုသီးသန့် မထားနိုင်ဘူးလေ။ ပိုက်ဆံ မပေါဘူး။ အဲဒါထက် ဒီလို repetitive task တွေကို လူထက်စာရင် ကွန်ပျူတာက အများကြီး ပိုကောင်းအောင် လုပ်နိုင်တာကိုး။

ဒီတော့ ကျွန်တော်တို့ CI software တွေရေးထားလိုက်ကြတယ်။ CI ဆိုတာ continuous integration ကိုခေါ်တယ်။ ဆိုလိုတာက integrate/code push ခဏခဏ ဆက်တိုက် လုပ်တယ်ပေါ့လေ။ Jenkins, Travis, CircleCI, GitHub Actions နဲ့နောက် CI software တွေ အများကြီး ရှိသေးတယ်။ ဒါပေမယ့် ဘယ် CI software ပဲဖြစ်ဖြစ် အနည်းဆုံးတော့ CI/CD pipeline စ run နိုင်ဖို့ ခလုတ်လိုမျိုး webhook ဒါမှမဟုတ် internal mechanism တခုခုရှိကိုရှိဖို့လိုမယ်။ နောက် pipeline ထဲဘာ task တွေ run မလဲဆိုတာ သတ်မှတ်ဖို့ setting ချိန်လို့ရရမယ်။ ဒါပဲ။

ဒီလို CI software တွေကို သီးသန့် virtual machine တွေမှာ တင် run ထားလိုက်ရင် GitHub repository ထဲမှာ commit အသစ်တခု တက်လာတိုင်း code ကို pull မယ်၊ unittesting တွေလုပ်မယ်၊ error ပါရင် issue ဖွင့်မယ် စသဖြင့် လုပ်စရာရှိတာတွေ အကုန်လုံးကို အချိန်ပြည့် လူစောင့်မရှိပဲ လုပ်ပေးနေမယ့် CI server တွေရလာမယ်။

ဒီနေ့ခေတ် CI/CD pipeline တွေက အဲဒီအချိန်တုန်းကနဲ့စာရင် အများကြီးပို complex လည်းဖြစ်လာပြီ။ code build တာ၊ container image ဆောက်တာ၊ ရလာတဲ့ image တွေ၊ Java Jar, Ruby Gem နဲ့ Python Wheel တွေကို သက်ဆိုင်တဲ့ registry တွေဆီ ပို့ပြီးသိမ်းတာတွေက pipeline တွေရဲ့ norm တခုဖြစ်လာတာ တွေ့ရမယ်။ ဒီလောက်ဆို CI/CD pipeline တွေ ဘယ်က ဖြစ်လာတယ်၊ ဘာတွေလုပ်​ကြတယ်။ ဘာလို့ CI/CD လုပ်ကြတယ်ဆိုတာ သဘောပေါက်သွားမယ် ထင်ပါတယ်။