Jenkins မဟုတ်ဘဲ အလေ့အကျင့်တစ်ခုအဖြစ် စဉ်ဆက်မပြတ် ပေါင်းစည်းခြင်း။ Andrey Alexandrov

CI ကိရိယာများနှင့် CI သည် အဘယ်ကြောင့် လုံးဝခြားနားသည်ကို ဆွေးနွေးကြည့်ရအောင်။

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

Continuous Integration အကြောင်း အစီရင်ခံစာ ရေးဖို့ စိတ်ကူးဟာ လွန်ခဲ့တဲ့ တစ်နှစ်က အင်တာဗျူးတွေ လုပ်ပြီး အလုပ်ရှာနေချိန်မှာ ပေါ်လာတယ်။ ကုမ္ပဏီ 10-15 နဲ့ စကားပြောခဲ့တယ်၊ သူတို့ထဲက တစ်ဦးတည်းက CI ဆိုတာ ဘာလဲဆိုတာ ရှင်းရှင်းလင်းလင်းဖြေနိုင်ခဲ့ပြီး သူတို့မှာ မရှိဘူးဆိုတာ သူတို့နားလည်ပုံကို ရှင်းပြတယ်။ ကျန်တဲ့သူတွေကတော့ Jenkins အကြောင်း နားမလည်နိုင်လောက်အောင် မိုက်မဲစွာပြောနေကြတာပဲ :) ကောင်းပြီ၊ ငါတို့မှာ Jenkins ရှိတယ်၊ အဲဒါက CI ပဲ တည်ဆောက်တယ်။ အစီရင်ခံစာအတွင်း၊ Continuous Integration အမှန်တကယ်က ဘာလဲ၊ Jenkins နှင့် အလားတူကိရိယာများသည် ဤအရာနှင့် အလွန်အားနည်းသော ဆက်ဆံရေးရှိသည်ကို ရှင်းပြရန် ကြိုးစားပါမည်။

ဒီတော့ CI ဆိုတဲ့ စကားလုံးကို ကြားတဲ့အခါ ဘာကို သတိရမိလဲ။ လူအများစုသည် Jenkins၊ Gitlab CI၊ Travis စသည်တို့ကို ထင်မြင်ကြလိမ့်မည်။

ကျွန်တော်တို့က Google ဆိုရင်တောင် ဒီကိရိယာတွေကို ပေးပါလိမ့်မယ်။

အကယ်၍ သင်သည် မေးခြင်းနှင့်ပတ်သက်၍ ရင်းနှီးပါက၊ ကိရိယာများကို စာရင်းပြုစုပြီးနောက် ချက်ခြင်းတွင် CI သည် commit တစ်ခုအတွက် Pull Request တစ်ခုတွင် သင်စမ်းသပ်မှုများ တည်ဆောက်ပြီး လုပ်ဆောင်သည့်အခါတွင် CI ဖြစ်သည်ဟု ၎င်းတို့က သင့်အား ပြောပြလိမ့်မည်။

စဉ်ဆက်မပြတ် ပေါင်းစည်းခြင်းသည် ဌာနခွဲရှိ စမ်းသပ်မှုများနှင့် စည်းဝေးပွဲများအကြောင်းမဟုတ်ဘဲ ကိရိယာများအကြောင်း မဟုတ်ပါ။ Continuous Integration သည် ကုဒ်အသစ်၏ မကြာခဏပေါင်းစည်းခြင်း၏ အလေ့အကျင့်ဖြစ်ပြီး ၎င်းကိုအသုံးပြုရန်အတွက် Jenkins၊ GitLab စသည်တို့ကို စည်းရိုးခတ်ရန် လုံးဝမလိုအပ်ပါ။

ပြီးပြည့်စုံသော CI ၏ပုံပန်းသဏ္ဍာန်ကို ကျွန်ုပ်တို့မတွက်ဆမီ၊ ၎င်းနှင့်ပတ်သက်ပြီး ဖြေရှင်းရန်ကြိုးစားနေသူများ၏ နာကျင်မှုကို ဦးစွာခံစားကြည့်ကြပါစို့။

အဖွဲ့လိုက် လက်တွဲလုပ်ရတဲ့ နာကျင်မှုကို သူတို့ ဖြေရှင်းပေးတယ်။

အဖွဲ့များဖွဲ့စည်းရာတွင် developer များကြုံတွေ့ရသည့်အခက်အခဲများကို ဥပမာများကို ကြည့်ကြပါစို့။ ဤတွင် ကျွန်ုပ်တို့တွင် ပရောဂျက်တစ်ခု၊ git ရှိ မာစတာဌာနခွဲတစ်ခုနှင့် developer နှစ်ဦးရှိသည်။

သူတို့သည် ကြာမြင့်စွာကတည်းက လူတိုင်းကျင့်နေကျအတိုင်း အလုပ်သွားကြသည်။ ကျွန်ုပ်တို့သည် အရာများ၏ ကြီးကျယ်ခမ်းနားသော အစီအစဥ်တွင် တာဝန်တစ်ခုယူကာ အင်္ဂါရပ်တစ်ခု ဖန်တီးကာ ကုဒ်ကို ရေးသားခဲ့သည်။

တစ်ခုက အင်္ဂါရပ်ကို ပိုမြန်စေပြီး ၎င်းကို မာစတာသို့ ပေါင်းထည့်လိုက်သည်။

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

သင်၏အင်္ဂါရပ်ကို သာမန်မာစတာနှင့် ပေါင်းစပ်ရန် ပို၍ခက်ခဲလေလေ၊ ၎င်းကို ကျွန်ုပ်တို့ အသုံးပြုလေလေဖြစ်သည်။ ပြီးတော့ ဒါကို ရိုးရိုးရှင်းရှင်း ဥပမာလေးနဲ့ ပြခဲ့တယ်။ ဤသည်မှာ developer 2 ဦးသာရှိသည့် ဥပမာတစ်ခုဖြစ်သည်။ ကုမ္ပဏီတစ်ခုတွင် လူ 10 သို့မဟုတ် 15 သို့မဟုတ် 100 သည် repository တစ်ခုသို့စာရေးပါက မြင်ယောင်ကြည့်ပါ။ ဒီပဋိပက္ခတွေအားလုံးကို ဖြေရှင်းဖို့ မင်းရူးသွားလိမ့်မယ်။

အနည်းငယ်ကွဲပြားတဲ့ ကိစ္စတစ်ခုရှိပါတယ်။ ကျွန်ုပ်တို့တွင် မာစတာတစ်ဦးရှိပြီး အချို့သော developer များ တစ်ခုခုလုပ်နေသည်။

အကိုင်းအခက်တစ်ခုကို ဖန်တီးခဲ့ကြတယ်။

တစ်ယောက်သေတယ်၊ ​​အရာအားလုံးအဆင်ပြေတယ်၊ ​​သူတာဝန်ကိုအောင်မြင်ခဲ့တယ်။

တစ်ချိန်တည်းတွင် ဒုတိယ developer သည် သူ၏တာဝန်ကို ပေးအပ်ခဲ့သည်။ ပြန်လည်သုံးသပ်ရန် ပေးပို့ခဲ့သည်ဟု ဆိုကြပါစို့။ ကုမ္ပဏီများစွာတွင် ပြန်လည်သုံးသပ်ခြင်းဟုခေါ်သော အလေ့အကျင့်တစ်ခုရှိသည်။ တစ်ဖက်တွင်၊ ဤအလေ့အကျင့်သည် ကောင်းမွန်ပြီး အသုံးဝင်သည်၊ အခြားတစ်ဖက်တွင်၊ ၎င်းသည် ကျွန်ုပ်တို့အား နည်းအမျိုးမျိုးဖြင့် နှေးကွေးစေသည်။ ကျွန်ုပ်တို့သည် ယင်းကို နားမလည်သော်လည်း ဤအရာသည် ဆိုးရွားသော ပြန်လည်သုံးသပ်မှုဇာတ်လမ်းကို ဦးတည်သွားစေနိုင်သည့် ဥပမာကောင်းတစ်ခုဖြစ်သည်။ ပြန်လည်သုံးသပ်ရန်အတွက် ဆွဲထုတ်ရန် တောင်းဆိုချက်ကို သင်တင်ပြပြီးဖြစ်သည်။ ဆော့ဖ်ဝဲရေးသားသူအတွက် နောက်ထပ်လုပ်စရာ ဘာမှမရှိတော့ပါ။ သူဘာစလုပ်တာလဲ။ သူက တခြားအလုပ်တွေကို စလုပ်တယ်။

ဤအတောအတွင်း၊ ဒုတိယ developer သည် အခြားအရာတစ်ခုကို ပြုလုပ်ခဲ့သည်။

ပထမတစ်ခုက တတိယတာဝန်ကို ပြီးမြောက်ခဲ့တယ်။

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

ဇာတ်လမ်းနှင့် ပဋိပက္ခများအပြင် ဇာတ်လမ်းနှင့် ဆက်သွယ်မှုလည်း ရှိပါသည်။ သင့်စာတွဲကို ပြန်လည်သုံးသပ်နေချိန်၊ တစ်ခုခုကို စောင့်ဆိုင်းနေချိန်၊ သင်သည် အင်္ဂါရပ်တစ်ခုကို အချိန်အတော်ကြာ လုပ်ဆောင်နေချိန်တွင်၊ သင့်ဝန်ဆောင်မှု၏ ကုဒ်အခြေခံတွင် အခြားအရာများ ပြောင်းလဲနေသည်ကို ခြေရာခံနေခြင်းကို ရပ်တန့်သွားမည်ဖြစ်သည်။ သင်ယခုဖြေရှင်းရန်ကြိုးစားနေသည့်အရာကို မနေ့ကဖြေရှင်းပြီးဖြစ်ကောင်းဖြစ်နိုင်သည်၊ နည်းလမ်းအချို့ကိုယူ၍ ၎င်းကိုပြန်သုံးနိုင်သည်။ သို့သော် သင်သည် ခေတ်မမီတော့သော ဌာနခွဲတစ်ခုနှင့် အမြဲအလုပ်လုပ်နေသောကြောင့် ၎င်းကို သင်မြင်မည်မဟုတ်ပါ။ ဤခေတ်မမီတော့သောဌာနခွဲသည် ပေါင်းစည်းပဋိပက္ခကို ဖြေရှင်းရန် သင့်အား အမြဲဖြစ်ပေါ်စေပါသည်။

အကယ်၍ ကျွန်ုပ်တို့သည် အဖွဲ့လိုက်လုပ်ဆောင်ပါက repository တွင်လူတစ်ဦးမှမပါဝင်ဘဲ လူ 5-10 ယောက်၊ ထို့နောက်ကျွန်ုပ်တို့၏ကုဒ်ကိုမာစတာသို့မထည့်ဘဲကြာလေလေ၊ နောက်ဆုံးတွင်ကျွန်ုပ်တို့လိုအပ်သောကြောင့်ကျွန်ုပ်တို့ပိုမိုခံစားရလေသည် တစ်ခုခုပြီးရင် ပေါင်းလိုက်ပါ။ ကျွန်ုပ်တို့တွင် ပဋိပက္ခများ ပိုများလေ၊ ကျွန်ုပ်တို့နှင့် တွဲလုပ်ရသော ဗားရှင်းဟောင်းလေ၊ ကျွန်ုပ်တို့တွင် ပြဿနာများ ပိုများလေဖြစ်သည်။

တစ်ခုခုလုပ်ရင် နာကျင်တယ်။ ငါတို့က တစ်ယောက်နဲ့တစ်ယောက် လမ်းကြောင်းပေါ်မှာ အမြဲရှိနေတယ်။

ဒီပြဿနာကို လွန်ခဲ့တဲ့ အနှစ် ၂၀ ကျော်က သတိထားမိခဲ့ပါတယ်။ Extreme Programming တွင် Continuous Integration ၏ ပထမဆုံးဖော်ပြချက်ကို ကျွန်ုပ်တွေ့ရှိခဲ့သည်။

Extreme Programming သည် ပထမဆုံး လျင်မြန်သော မူဘောင်ဖြစ်သည်။ စာမျက်နှာသည် 96 ခုနှစ်တွင်ပေါ်လာသည်။ ကျွန်ုပ်တို့၏ဖောက်သည်များထံမှ အပြောင်းအလဲများ သို့မဟုတ် လိုအပ်ချက်များကို လျင်မြန်စွာတုံ့ပြန်နိုင်ရန် စိတ်ကူးမှာ ပရိုဂရမ်းမင်းကျင့်စဉ်များ၊ အစီအစဉ်ဆွဲခြင်းနှင့် အခြားအရာများကို အသုံးပြုရန်ဖြစ်ပြီး ဖွံ့ဖြိုးတိုးတက်မှုကို တတ်နိုင်သမျှ လိုက်လျောညီထွေဖြစ်အောင် လုပ်ဆောင်ရန်ဖြစ်သည်။ လွန်ခဲ့သည့် 24 နှစ်ကစ၍ တစ်ခုခုကို အချိန်အတော်ကြာအောင် တစ်ဖက်တွင်လုပ်ပါက၊ ပဋိပက္ခများရှိနေသောကြောင့် ယင်းနှင့်ပတ်သက်ပြီး အချိန်ပိုသုံးစွဲလာကြသည်။

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

ဒါကြောင့်မို့လို့ Extreme Programming ရဲ့ ကိုးကားချက်တွေကို အခုပဲ ပေးနေပါတယ်။ ပြီးတော့ စကားလုံးနှစ်လုံးလုံးကို သီးခြားခွဲခြမ်းစိတ်ဖြာမယ်။

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

ပေါင်းစည်းခြင်းသည် ကျွန်ုပ်တို့၏ဌာနခွဲကိုယူ၍ မာစတာနှင့် ပေါင်းစည်းသောအခါ၊ ကျွန်ုပ်တို့သည် ၎င်းကို ပေါင်းစည်းခြင်းဖြစ်သည်။ ကျွန်ုပ်တို့သည် transbase developer တစ်ဦးဖြစ်သောအခါတွင် အဆုံးစွန်သော ရွေးချယ်ခွင့်တစ်ခု ရှိပါသည်။ အပိုအကိုင်းအခက်များမပါဘဲ မာစတာထံ ချက်ချင်းစာရေးနိုင်စေရန် ကြိုးပမ်းပါသည်။

ယေဘူယျအားဖြင့်၊ ပေါင်းစည်းခြင်းဆိုသည်မှာ သင်၏ကုဒ်ကိုယူ၍ မာစတာထဲသို့ ဆွဲယူခြင်းပင်ဖြစ်သည်။

ဤနေရာတွင် "အဆက်မပြတ်" ဟူသော စကားလုံး၏ အဓိပ္ပါယ်မှာ အဘယ်အရာကို အဆက်ပြတ်ခြင်းဟုခေါ်သနည်း။ အလေ့အကျင့်သည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် ၎င်း၏ကုဒ်ကို တတ်နိုင်သမျှ အမြန်ပေါင်းစပ်ရန် ကြိုးပမ်းသည်ဟု ဆိုလိုသည်။ အလုပ်တစ်ခုခုကိုလုပ်ဆောင်တဲ့အခါ ဒါက သူ့ရဲ့ကုဒ်ကို တတ်နိုင်သမျှ ကျွမ်းကျင်အောင်လုပ်ဖို့ ရည်မှန်းချက်ပါပဲ။ စံပြကမ္ဘာတွင်၊ developer များသည် ၎င်းကို နာရီအနည်းငယ်တိုင်း ပြုလုပ်ကြသည်။ ဆိုလိုသည်မှာ သင်သည် ပြဿနာသေးသေးတစ်ခုကိုယူ၍ သခင်အဖြစ်သို့ ပေါင်းထည့်ခြင်းဖြစ်သည်။ အရာအားလုံးက အရမ်းကောင်းတယ်။ ဤသည်မှာ သင်ကြိုးစားနေသောအရာဖြစ်သည်။ ပြီးတော့ ဒါကို ဆက်တိုက်လုပ်ရမယ်။ တစ်ခုခုလုပ်လိုက်တာနဲ့ ချက်ချင်းပဲ သခင်ဆီ ထည့်ပေးလိုက်တယ်။

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

သို့သော် ဇာတ်လမ်းများဖြင့်- အပြောင်းအလဲများကို သေးငယ်အောင်ပြုလုပ်ကြပါစို့၊ အလုပ်များကို သေးငယ်ပါစေ၊ ပြဿနာတစ်ခုဖန်တီးပြီး ၎င်းကို သခင်ထဲသို့ တစ်နည်းနည်းဖြင့် မြှုပ်နှံရန် ချက်ချင်းကြိုးစားကြပါစို့ - Jenkins သည် ဤနေရာတွင် ကူညီမည်မဟုတ်ပါ။ အဘယ်ကြောင့်ဆိုသော် Jenkins သည် သင့်အား စမ်းသပ်မှုများကို လုပ်ဆောင်ရန်သာ ကူညီပေးသောကြောင့်ဖြစ်သည်။

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

အကြောင်းပြချက်တစ်ခုခုကြောင့် ကျွန်ုပ်တို့သည် 2020 တွင် အင်တာနက်မရှိဟု စိတ်ကူးကြည့်ကြပါစို့။ နောက်ပြီးတော့ ကျွန်တော်တို့က ပြည်တွင်းမှာပဲ လုပ်တယ်။ ကျွန်ုပ်တို့တွင် Jenkins မရှိပါ။ ဒါကအဆင်ပြေပါတယ်။ သင် ရှေ့ဆက်ပြီး ဒေသခံဌာနခွဲတစ်ခု ပြုလုပ်နိုင်သေးသည်။ အဲဒီထဲမှာ ကုဒ်တချို့ ရေးထားတယ်။ ကျွန်ုပ်တို့သည် 3-4 နာရီအတွင်းအလုပ်ပြီးမြောက်သည်။ ကျွန်ုပ်တို့သည် မာစတာသို့ပြောင်းကာ git ဆွဲကာ ကျွန်ုပ်တို့၏ဌာနခွဲကို ထိုနေရာတွင် ပေါင်းစည်းလိုက်ကြသည်။ အဆင်သင့်။ ဒါကို မကြာခဏလုပ်ရင် ဂုဏ်ယူပါတယ်၊ မင်းမှာ စဉ်ဆက်မပြတ် ပေါင်းစည်းမှုရှိတယ်။

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

ပြီးတော့ ဈေးကြီးလိမ့်မယ်။ Continuous Integration ကို အသုံးပြု၍ မနက်ဖြန်မှ ချက်ချင်းလုပ်ဆောင်နိုင်မည်မဟုတ်ပါ။ ၎င်းကိုအသုံးပြုရန် သင့်အား အချိန်အတော်ကြာယူရမည်ဖြစ်ပြီး၊ လုပ်ဆောင်စရာများကို ဖျက်ရန်အသုံးခံရန် အချိန်အတော်ကြာမည်၊ သင့်တွင် တစ်ခုရှိလျှင် ပြန်လည်သုံးသပ်ခြင်းအလေ့အကျင့်ကို ပြန်လည်လုပ်ဆောင်ရန် အချိန်အတော်ကြာမည်ဖြစ်သည်။ . ဘာကြောင့်လဲ ဆိုတော့ ကျွန်တော်တို့ရဲ့ ရည်မှန်းချက်က ဒီနေ့ အရည်ပျော်ဖို့ပါ။ အကယ်၍ သင်သည် သုံးရက်အတွင်း ပြန်လည်သုံးသပ်မှု ပြုလုပ်ပါက၊ သင်သည် ပြဿနာများ ရှိနေပြီး Continuous Integration သည် သင့်အတွက် အလုပ်မဖြစ်ပါ။

သို့သော် ဤအလေ့အကျင့်တွင် ရင်းနှီးမြုပ်နှံခြင်းသည် အဓိပ္ပာယ်ရှိစေသည်ဟု ကျွန်ုပ်တို့အား ညွှန်ပြသော သက်ဆိုင်သည့်အထောက်အထားများ ရှိပါသလား။

ကျွန်တော့်စိတ်ထဲ ပထမဆုံးရောက်လာတာကတော့ DevOps အခြေအနေပါ။ ဤသည်မှာ ယောက်ျားလေးများ ၇ နှစ်ကြာ ပြုလုပ်ခဲ့သော လေ့လာမှုတစ်ခုဖြစ်သည်။ ယခုအခါ ၎င်းတို့သည် ၎င်းကို သီးခြားအဖွဲ့အစည်းတစ်ခုအနေဖြင့် လုပ်ဆောင်သော်လည်း Google လက်အောက်တွင် ရှိနေသည်။

၎င်းတို့၏ 2018 လေ့လာမှုသည် လျင်မြန်စွာပေါင်းစည်းရန်၊ မကြာခဏပေါင်းစပ်ကာ ပိုမိုကောင်းမွန်သော IT စွမ်းဆောင်ရည်အညွှန်းကိန်းများပါရှိသော သက်တမ်းတိုအကိုင်းအခက်များကို အသုံးပြုရန် ကြိုးစားသည့် ကုမ္ပဏီများကြား ဆက်စပ်မှုကို ပြသခဲ့သည်။

ဤအညွှန်းကိန်းများသည် အဘယ်နည်း။ ၎င်းတို့သည် ၎င်းတို့၏မေးခွန်းလွှာရှိ ကုမ္ပဏီအားလုံးမှ ရယူသည့် မက်ထရစ် 4 ခုဖြစ်သည်- အသုံးချမှု အကြိမ်ရေ၊ အပြောင်းအလဲအတွက် ဦးဆောင်ချိန်၊ ဝန်ဆောင်မှု ပြန်လည်ရယူရန် အချိန်၊ ပျက်ကွက်မှုနှုန်းကို ပြောင်းလဲခြင်း။

ပထမဆုံးအနေနဲ့၊ ဒီဆက်စပ်မှုရှိတယ်၊ မကြာခဏတိုင်းတာတဲ့ကုမ္ပဏီတွေမှာ ပိုကောင်းတဲ့မက်ထရစ်တွေရှိတယ်ဆိုတာ ကျွန်တော်တို့သိပါတယ်။ ၎င်းတို့တွင် ကုမ္ပဏီများကို အမျိုးအစားများစွာ ခွဲထားပါသည်- ၎င်းတို့သည် နှေးကွေးသော ကုမ္ပဏီများ၊ အလယ်အလတ် စွမ်းဆောင်ရည်၊ စွမ်းဆောင်ရည်မြင့် နှင့် အထက်တန်းစား တစ်ခုခုကို ထုတ်လုပ်သည့် နှေးကွေးသော ကုမ္ပဏီများဖြစ်သည်။ ထိပ်တန်းများဖြစ်ကြသည့် Netflix၊ Amazon တို့သည် အလွန်လျင်မြန်ပြီး အရာအားလုံးကို လျင်မြန်စွာ၊ လှလှပပနှင့် ထိရောက်စွာလုပ်ဆောင်ကြသည်။

ဒုတိယ ဇာတ်လမ်းကတော့ လွန်ခဲ့တဲ့ တစ်လလောက်က ဖြစ်ခဲ့တာပါ။ Technology Radar တွင် Gitflow နှင့် ပတ်သက်၍ ကောင်းမွန်သော ဆောင်းပါးတစ်ပုဒ်ရှိသည်။ Gitflow သည် ၎င်း၏အကိုင်းအခက်များ တာရှည်ခံသောကြောင့် အခြားသူများနှင့် မတူပါ။ ကြာရှည်စွာ ရှင်သန်နိုင်သော အကိုင်းအခက်များ ရှိပြီး ကြာရှည်စွာ ရှင်သန်နိုင်သော အကိုင်းအခက်များ ရှိသည်။ Technology Radar တွင် ဤအလေ့အကျင့်သည် HOLD သို့ ပြောင်းသွားပါသည်။ အဘယ်ကြောင့်? အဘယ်ကြောင့်ဆိုသော် လူတို့သည် ပေါင်းစည်းခြင်း၏ နာကျင်မှုကို ရင်ဆိုင်ရသောကြောင့် ဖြစ်သည်။

သင်၏အကိုင်းအခက်သည် အချိန်အတော်ကြာအသက်ရှင်ပါက၊ ၎င်းသည် တွယ်ကပ်လာကာ ပုပ်သွားကာ ၎င်းကို ပြောင်းလဲရန်ကြိုးစားရန် အချိန်ပိုသုံးစွဲလာကြသည်။

မကြာသေးမီက Gitflow ၏စာရေးဆရာက သင့်ရည်မှန်းချက်သည် စဉ်ဆက်မပြတ်ပေါင်းစည်းမှုဖြစ်ပါက၊ သင့်ပန်းတိုင်မှာ သင်တတ်နိုင်သမျှ မကြာခဏ လှိမ့်ချင်နေပါက၊ Gitflow သည် မကောင်းသောအကြံအစည်တစ်ခုဖြစ်သည်။ သင်ဤအတွက်ကြိုးစားနိုင်သည့် backend တစ်ခုရှိပါက Gitflow သည်သင့်အတွက်မလိုအပ်ပါ၊ Gitflow သည်သင့်အားနှေးကွေးစေသောကြောင့် Gitflow သည်သင့်အတွက်ပေါင်းစည်းမှုပြဿနာများကိုဖန်တီးပေးလိမ့်မည်ဟူသောဆောင်းပါးတွင်သူသည်သီးခြားစီထည့်သည်။

၎င်းသည် Gitflow ဆိုးရွားပြီး အသုံးမပြုသင့်ဟု မဆိုလိုပါ။ တခြားအချိန်တွေအတွက်ပါ။ ဥပမာအားဖြင့်၊ သင်သည် ဝန်ဆောင်မှု သို့မဟုတ် အက်ပ်လီကေးရှင်း၏ ဗားရှင်းများစွာကို ပံ့ပိုးရန် လိုအပ်သောအခါ၊ ဆိုလိုသည်မှာ သင်သည် အချိန်ကြာမြင့်စွာ ပံ့ပိုးမှုလိုအပ်သည့်နေရာဖြစ်သည်။

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

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

ကျွန်ုပ်တို့သည် တစ်ခုခုလုပ်နေပြီဟု ထင်ရသည်၊ ကျွန်ုပ်တို့ ပေါင်းစည်းနေပြီဟု ထင်ရသော်လည်း ကျွန်ုပ်တို့သည် မကြာခဏ ပေါင်းစည်းနေကြသည်မှာ စဉ်ဆက်မပြတ် ပေါင်းစည်းမှု ရှိနေကြောင်း မည်သို့ နားလည်နိုင်မည်နည်း။

Jez Humble သည် လက်စွဲစာအုပ်၊ Accelerate၊ စဉ်ဆက်မပြတ် ပေးပို့သည့် ဝဘ်ဆိုက်နှင့် စဉ်ဆက်မပြတ် ပေးပို့သည့် စာအုပ်ကို ရေးသားသူဖြစ်သည်။ သူက ဒီစမ်းသပ်မှုကို ပေးသည်-

• အင်ဂျင်နီယာ၏ကုဒ်သည် သခင်ထံ နေ့တိုင်းရောက်နေသည်။
• ကတိကဝတ်တိုင်းအတွက် ယူနစ်စစ်ဆေးမှုများကို သင်လုပ်ဆောင်သည်။
• အဆောက်အဦ ပြုတ်ကျပြီး ၁၀ မိနစ်ခန့်အကြာတွင် ပြုပြင်ခဲ့သည်။

သင့်တွင် လုံလောက်သော အလေ့အကျင့်ရှိကြောင်း သေချာစေရန် ဤကဲ့သို့သော စမ်းသပ်မှုကို အသုံးပြုရန် အကြံပြုထားသည်။

နောက်ပိုင်းမှာ နည်းနည်းအငြင်းပွားစရာတွေ့တယ်။ အဲဒါကို 10 မိနစ်အတွင်း ပြင်လို့ရတယ် ဆိုရင်တော့ Continuous Integration ရှိတယ်၊ ငါ့အမြင်အရတော့ နည်းနည်း ထူးဆန်းနေပေမယ့် အဓိပ္ပါယ်ရှိပါတယ်။ အဘယ်ကြောင့်? အဘယ်ကြောင့်ဆိုသော် သင်သည် မကြာခဏ အေးခဲနေပါက သင်၏ပြောင်းလဲမှုများသည် သေးငယ်သည်ဟု ဆိုလိုသည်။ သေးငယ်သောပြောင်းလဲမှုတစ်ခုသည် သင်၏ master build ပျက်သွားပါက၊ ပြောင်းလဲမှုသည် သေးငယ်သောကြောင့် ဥပမာတစ်ခုကို လျင်မြန်စွာရှာဖွေနိုင်သည်။ ဤတွင် သင့်တွင် သေးငယ်သော ပေါင်းစည်းမှုတစ်ခု ရှိခဲ့သည်၊ ၎င်းတွင် လိုင်း 20-30 ပြောင်းသွားသည်။ ထို့ကြောင့်၊ အဘယ်ကြောင့်ဆိုသော် အပြောင်းအလဲများသည် သေးငယ်သောကြောင့်၊ သင့်တွင် ပြဿနာရှာရန် အလွန်သေးငယ်သော ဧရိယာရှိသောကြောင့် အဘယ်ကြောင့်ဆိုသည်ကို လျင်မြန်စွာ နားလည်နိုင်သည်။

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

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

ဒါက Continuous Integration ရဲ့ အကျဉ်းချုပ် နိဒါန်းပါ။ ဒီကျင့်စဉ်မှာ ဒါပဲရှိတယ်။ မေးခွန်းတွေအတွက် အဆင်သင့်ဖြစ်နေပါပြီ။

အကျဉ်းချုံးပြီး ထပ်ပြောမယ်

• Continuous Integration သည် Jenkins မဟုတ်ဘဲ Gitlab မဟုတ်ပါ။
• ၎င်းသည် ကိရိယာတစ်ခုမဟုတ်ပါ၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကုဒ်ကို တတ်နိုင်သမျှ မာစတာထဲသို့ မကြာခဏ ပေါင်းစည်းသည့် အလေ့အကျင့်တစ်ခုဖြစ်သည်။
• အနာဂတ်တွင် ပေါင်းစည်းခြင်းနှင့်အတူ ဖြစ်ပေါ်လာသော ကြီးမားသော နာကျင်မှုကို ရှောင်ရှားရန် ကျွန်ုပ်တို့ ဤအရာကို လုပ်ဆောင်ခြင်းဖြစ်သည်၊ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် အနာဂတ်တွင် နောက်ထပ် မခံစားရစေရန်အတွက် ယခု အနည်းငယ် နာကျင်မှုကို ခံစားနေကြရပါသည်။ ဒါပဲအချက်ပါပဲ။
• တစ်ဖက်မှာတော့ ကုဒ်ကတစ်ဆင့် ဆက်သွယ်မှုတွေရှိပေမယ့် အဲဒါကို ကျွန်တော်မြင်ရခဲပါတယ်၊ ဒါပေမယ့် ဒါကလည်း ဒီဇိုင်းထုတ်ထားတာပါပဲ။

မေးခွန်းများကို

ပြိုကွဲပျက်စီးသွားသော အလုပ်များကို ဘာလုပ်ရမည်နည်း။

ပုပ်သိုးသည်။ ပြသနာကဘာလဲ? အလုပ်တစ်ခုရှိပြီး ပြိုကွဲမသွားကြောင်း ဥပမာတစ်ခုပေးလို့ရမလား။

ဥပမာ "လုံးဝ" ဟူသော စကားလုံးမှ ပြိုကွဲပျက်စီးသွားနိုင်သော အလုပ်များ ရှိသည်၊ ဥပမာ၊ အလွန်နက်နဲသော ကျွမ်းကျင်မှု လိုအပ်ပြီး အစာကြေလွယ်သော ရလဒ်ရရှိရန် တစ်လတာအတွင်း အမှန်တကယ် ဖြေရှင်းနိုင်သည့် အလုပ်များ ရှိပါသည်။

ငါ မင်းကို မှန်မှန်ကန်ကန် နားလည်ရင်၊ ကြီးမားတဲ့ ရှုပ်ထွေးတဲ့ အလုပ်တစ်ခုရှိတယ်၊ ရလဒ်က တစ်လအတွင်းမှာပဲ မြင်နိုင်လိမ့်မယ်။

ဟုတ်တယ် အဲဒါမှန်တယ်။ ဟုတ်ကဲ့၊ ရလဒ်ကို တစ်လထက် မစောဘဲ အကဲဖြတ်နိုင်ပါလိမ့်မယ်။

ဒဏ်ငွေ။ ယေဘုယျအားဖြင့်တော့ ဒါက ပြဿနာမဟုတ်ပါဘူး။ အဘယ်ကြောင့်? ဘာကြောင့်လဲဆိုတော့ ဒီအကိုင်းအခက်တွေအကြောင်း ပြောတဲ့အခါ၊ အင်္ဂါရပ်တစ်ခုပါတဲ့ အကိုင်းအခက်အကြောင်း ပြောနေတာမဟုတ်ဘူး။ အင်္ဂါရပ်များသည် ကြီးမားပြီး ရှုပ်ထွေးနိုင်သည်။ ၎င်းတို့သည် အစိတ်အပိုင်းအများအပြားကို ထိခိုက်စေနိုင်သည်။ အကိုင်းအခက်တစ်ခုတည်းမှာ အဲဒါတွေကို လုံးဝမလုပ်နိုင်ဘူး။ ဒါကအဆင်ပြေပါတယ်။ ဒီဇာတ်လမ်းကို ဖျက်ဖို့ပဲလိုတယ်။ အင်္ဂါရပ်တစ်ခု လုံး၀အဆင်သင့်မဖြစ်ပါက၊ ၎င်းသည် ၎င်း၏ကုဒ်အချို့ကို ပေါင်းစည်းမရနိုင်ဟု မဆိုလိုပါ။ သင်သည် ရွှေ့ပြောင်းခြင်းဟု ထည့်သွင်းပြီး အင်္ဂါရပ်အတွင်း၌ အဆင့်အချို့ရှိသည်။ သင့်တွင် အဆင့်တစ်ခုရှိသည်ဆိုပါစို့ - ရွှေ့ပြောင်းခြင်းတစ်ခုလုပ်ပါ၊ နည်းလမ်းအသစ်တစ်ခုထည့်ပါ။ ပြီးတော့ ဒီအရာတွေကို နေ့တိုင်း တိုင်းတာလို့ရတယ်။

ဒဏ်ငွေ။ ဒါဆို ဘာအချက်လဲ?

အသေးအမွှားလေးတွေကို နေ့တိုင်းသတ်တာက ဘာလဲ။

ဟုတ်ပါတယ်။

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

ကျေးဇူးတင်ပါတယ်၊ ပြဿနာက ပိတ်သွားပြီ။

(Oleg Soroka) ထည့်လို့ရမလား။ မင်းပြောသမျှမှန်တယ်၊ ငါစကားတစ်ခွန်းပဲထည့်ချင်တယ်။

So.

Continuous Integration ဖြင့်၊ အင်္ဂါရပ်လုံးဝအဆင်သင့်မဖြစ်သောအခါတွင်မဟုတ်ဘဲ တည်ဆောက်မှုပျက်သွားသောအခါတွင် ကုဒ်ကို ဘုံဌာနခွဲတစ်ခုအဖြစ် ပေါင်းစည်းလိုက်သည်။ ပြီးတော့ သင်အလိုအတိုင်း တစ်နေ့ကို အကြိမ်များစွာ ကျွမ်းကျင်အောင် လုံခြုံစွာ ကတိပြုနိုင်ပါတယ်။ ဒုတိယ ရှုထောင့်က အကြောင်းတစ်ခုခုကြောင့် လစဉ်အလုပ်တွေကို အနည်းဆုံး သုံးရက်လောက် အလုပ်အဖြစ် မခွဲနိုင်ရင် သုံးနာရီလောက် နှုတ်ဆိတ်နေတယ် ဆိုရင်တော့ မင်းမှာ ကြီးမားတဲ့ ပြဿနာတစ်ခု ရှိနေပါတယ်။ ပြီးတော့ သင့်မှာ Continuous Integration မရှိဘူးဆိုတဲ့အချက်က ဒီပြဿနာတွေထဲက အနည်းဆုံးပါပဲ။ ဆိုလိုသည်မှာ သင်သည် ဗိသုကာပညာနှင့် သုညအင်ဂျင်နီယာကျင့်ထုံးများနှင့် ပြဿနာများရှိသည်။ အဘယ်ကြောင့်ဆိုသော် ဤအရာသည် သုတေသနပင်ဖြစ်လျှင်ပင်၊ မည်သို့ပင်ဆိုစေကာမူ ၎င်းကို တွေးခေါ်မှုပုံစံ သို့မဟုတ် စက်ဝန်းပုံစံဖြင့် ပုံဖော်ရမည်ဖြစ်သည်။

အောင်မြင်သောကုမ္ပဏီများအား နောက်ကျနေသောအရာများနှင့် ခွဲခြားသိမြင်နိုင်သော မက်ထရစ် 4 ခုအကြောင်း ဆွေးနွေးခဲ့ပါသည်။ ဤမက်ထရစ် ၄ ခုကို ကြည့်ရန် ကျွန်ုပ်တို့ အသက်ရှင်နေရပါမည်။ မင်းရဲ့ ပျမ်းမျှအလုပ်ပြီးဖို့ တစ်လလောက်ကြာရင် ဒီမက်ထရစ်ကို အရင်အာရုံစိုက်မယ်။ အရင် ၃ ရက်လောက် လျှော့ပေးမယ်။ အဲဒီနောက်မှာတော့ Continuous အကြောင်းကို တွေးနေမိပါတော့တယ်။

အလုပ်တစ်ခုပြီးမြောက်ဖို့ တစ်လလောက်အချိန်ယူရရင် ယေဘုယျအားဖြင့် အင်ဂျင်နီယာကျင့်ထုံးတွေမှာ ရင်းနှီးမြုပ်နှံမှုမှာ အဓိပ္ပာယ်မရှိဘူးလို့ မင်းထင်တာ မှန်မှန်ကန်ကန် နားလည်ခဲ့တာလား။

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

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

အခြေခံက ရှေ့ကိုပဲ ရွေ့နေတယ်၊ ​​ဟုတ်တယ်။

အင်ဂျင်နီယာအလေ့အကျင့် ညံ့ဖျင်းသောသူများသည် စာအုပ်ထူထူကို မဖတ်ဖူးကြပေ။ Backup နဲ့ ဘာလုပ်ရမလဲ။ အကယ်၍ သင်သည် အရန်သိမ်းဆည်းမှုမှ ပြန်လည်ရယူပါက၊ ၎င်းသည် ထိုအချိန်အတွင်း သင်စုဆောင်းထားသောဒေတာကို ဆုံးရှုံးသွားသည်ဟု ဆိုလိုသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်၏ ဗားရှင်းအသစ်ဖြင့် သုံးနာရီကြာ အလုပ်လုပ်ခဲ့ပြီး၊ အသုံးပြုသူများ ထိုနေရာတွင် မှတ်ပုံတင်ခဲ့သည်။ အစီအစဉ်သည် ဗားရှင်းအသစ်နှင့် အလုပ်မလုပ်သောကြောင့် သင်သည် အဟောင်းအရန်ကူးခြင်းကို ငြင်းဆိုသောကြောင့် သင်သည် ဤအသုံးပြုသူများကို ဆုံးရှုံးသွားပါပြီ။ မကျေမနပ် တိုင်တည်ကြ။

Continuous Integration and Continuous Delivery ကို ပံ့ပိုးပေးသော အလေ့အကျင့် အပြည့်အစုံကို ကျွမ်းကျင်စေရန်အတွက် စာရေးနည်းကို လေ့လာရုံဖြင့် မလုံလောက်ပါ။ ပထမဦးစွာ၊ ၎င်းတို့အများအပြားရှိနိုင်သည်၊ ၎င်းသည်လက်တွေ့မကျနိုင်ပါ။ ထို့အပြင် Scientific ကဲ့သို့သော အခြားသော အလေ့အကျင့်များစွာလည်း ရှိသေးသည်။ ထိုသို့သောအလေ့အကျင့်တစ်ခုရှိသည်၊ GitHub တစ်ချိန်တည်းတွင်၎င်းကိုရေပန်းစားခဲ့သည်။ ဤသည်မှာ သင့်တွင် ကုဒ်အဟောင်းနှင့် ကုဒ်အသစ် နှစ်ခုစလုံးကို တစ်ပြိုင်နက်တည်း လုပ်ဆောင်နေချိန်ဖြစ်သည်။ ၎င်းသည် သင်မပြီးဆုံးသေးသော အင်္ဂါရပ်တစ်ခုကို ပြုလုပ်သောအခါတွင်၊ သို့သော် ၎င်းသည် လုပ်ဆောင်ချက်တစ်ခုအဖြစ် သို့မဟုတ် Rest API တစ်ခုအနေဖြင့် တန်ဖိုးအချို့ကို ပြန်ပေးနိုင်သည်။ သင်သည် ကုဒ်အသစ်နှင့် ကုဒ်အဟောင်း နှစ်ခုလုံးကို လုပ်ဆောင်ပြီး ၎င်းတို့ကြား ခြားနားချက်ကို နှိုင်းယှဉ်ပါ။ ခြားနားချက်တစ်ခုရှိလျှင် သင်သည် ဤဖြစ်ရပ်ကို မှတ်တမ်းတင်ပါ။ ဤနည်းဖြင့် သင်သည် ၎င်းတို့နှစ်ခုကြားတွင် အချိန်အတိုင်းအတာတစ်ခုအထိ ကွဲလွဲမှုမရှိပါက အဟောင်း၏ထိပ်တွင် လွှင့်တင်ရန် အဆင်သင့်ဖြစ်နေပြီဖြစ်သော အင်္ဂါရပ်အသစ်တစ်ခုကို ဤနည်းဖြင့် သင်သိနိုင်သည်။

အဲဒီလို အလေ့အကျင့် ရာနဲ့ချီရှိတယ်။ transbase development နဲ့ စတင်ဖို့ အကြံပြုချင်ပါတယ်။ သူမသည် စဉ်ဆက်မပြတ်ပေါင်းစည်းမှုတွင် 100% မဟုတ်သော်လည်း အလေ့အကျင့်များသည် အတူတူပင်ဖြစ်ပြီး အခြားတစ်ခုမပါဘဲ ကောင်းကောင်းနေနိုင်မည်မဟုတ်ပေ။

အလေ့အကျင့်များကို သင်မြင်နိုင်သည့် ဥပမာတစ်ခုအနေဖြင့် transbase ဖွံ့ဖြိုးတိုးတက်မှုကို သင်ပေးခဲ့ပါသလား သို့မဟုတ် လူများကို transbase debelopment ကို စတင်အသုံးပြုရန် အကြံပြုလိုပါသလား။

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

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

အချို့သော diagram ပေါ်တွင် မြှားများနှင့် လေးထောင့်များစွာကို သင်ဆွဲရန် လိုအပ်သည်။ ယခုကျွန်ုပ်သည် အပလီကေးရှင်းအသစ်တစ်ခု၏ ဗိသုကာပုံသဏ္ဍာန်ကိုပြသပြီး ၎င်းတွင် အပလီကေးရှင်းအတွက် အစိမ်းရောင်ခလုတ်တစ်ခုပါရှိသည့် စတုရန်းတစ်ခုပြသမည်ဟု သင်ပြော၍မရပါ။ မည်သို့ပင်ဆိုစေ၊ လေးထောင့်နှင့် မြှားများ ပိုရှိလိမ့်မည်။ ကျွန်တော်မြင်တဲ့ ပုံတိုင်းမှာ တစ်ခုထက်ပိုပါတယ်။ ဂရပ်ဖစ်ကိုယ်စားပြုအဆင့်တွင်ပင် ပြိုကွဲပျက်စီးမှုသည် ဖြစ်ပွားနေပြီဖြစ်သည်။ ထို့ကြောင့် လေးထောင့်များကို အမှီအခိုကင်းစွာ ပြုလုပ်နိုင်သည်။ မဟုတ်ပါက ကျွန်ုပ်သည် ဗိသုကာပညာရှင်အတွက် မေးခွန်းကြီးတစ်ခု ရှိပါသည်။

ချတ်မှမေးခွန်းတစ်ခုရှိသည်- "ပြန်လည်သုံးသပ်ရန်မဖြစ်မနေလိုအပ်ပြီး အချိန်အတော်ကြာပါက တစ်ရက် သို့မဟုတ် ထို့ထက်ပို၍ဖြစ်နိုင်သည်"

လေ့ကျင့်ရေးနဲ့ ပတ်သက်ပြီး အဆင်မပြေတာတွေ ရှိတယ်။ သုံးသပ်ချက်သည် တစ်ရက် သို့မဟုတ် ထို့ထက်ပို၍ ကြာရှည်မခံသင့်ပါ။ ဒါက အရင်မေးခွန်းနဲ့ အတူတူပါပဲ၊ နည်းနည်းပျော့သွားတယ်။ သုံးသပ်ချက်တစ်ခုသည် တစ်ရက်ကြာသွားပါက၊ ဤသုံးသပ်ချက်သည် အလွန်ကြီးမားသော အပြောင်းအလဲတစ်ခု ဖြစ်လာနိုင်သည်။ ဆိုလိုသည်မှာ ၎င်းကို သေးငယ်အောင်ပြုလုပ်ရန် လိုအပ်သည်။ Oleg အကြံပြုထားသည့် transbase ဖွံ့ဖြိုးတိုးတက်မှုတွင် စဉ်ဆက်မပြတ် ပြန်လည်သုံးသပ်ခြင်းဟုခေါ်သော ဇာတ်လမ်းတစ်ပုဒ်ရှိသည်။ သူမ၏ စိတ်ကူးမှာ ကျွန်ုပ်တို့သည် အဆက်မပြတ်နှင့် တစ်ကြိမ်လျှင် အနည်းငယ် ပေါင်းစည်းရန် ကြိုးစားသောကြောင့် ရည်ရွယ်ချက်ရှိရှိ သေးငယ်သော တောင်းဆိုမှုတစ်ခုကို ပြုလုပ်ရန်ဖြစ်သည်။ ထို့ကြောင့် ဆွဲထုတ်တောင်းဆိုမှုသည် abstraction တစ်ခု သို့မဟုတ် 10 စာကြောင်းကို ပြောင်းလဲသည်။ ဤသုံးသပ်ချက်ကြောင့် ကျွန်ုပ်တို့သည် မိနစ်အနည်းငယ်ကြာပါသည်။

ပြန်လည်သုံးသပ်မှုသည် တစ်ရက် သို့မဟုတ် ထိုထက်ပိုကြာပါက တစ်ခုခုမှားနေပါသည်။ ပထမဦးစွာ သင်သည် ဗိသုကာပညာနှင့် ပတ်သက်၍ ပြဿနာအချို့ရှိနိုင်သည်။ ဒါမှမဟုတ် ဒါက ကုဒ်အပိုင်းအစကြီးတစ်ခု၊ ဥပမာ၊ စာကြောင်း ၁၀၀၀။ ဒါမှမဟုတ် မင်းရဲ့ဗိသုကာလက်ရာက ရှုပ်ထွေးလွန်းလို့ လူတစ်ယောက်က အဲဒါကို နားမလည်နိုင်ဘူး။ ဤသည်မှာ အနည်းငယ် ဘေးတိုက်ပြဿနာဖြစ်သော်လည်း ဖြေရှင်းရပေလိမ့်မည်။ ပြန်လည်သုံးသပ်ရန် လုံးဝမလိုအပ်ပါ။ ဒါကိုလည်း ကျွန်တော်တို့ စဉ်းစားဖို့ လိုပါတယ်။ ပြန်လည်သုံးသပ်ခြင်းသည် သင့်အား နှေးကွေးစေသော အရာဖြစ်သည်။ ယေဘူယျအားဖြင့် ၎င်းသည် ၎င်း၏ အားသာချက်များ ရှိသော်လည်း ၎င်းကို သင်ဘာကြောင့် လုပ်သည်ကို နားလည်ရန် လိုအပ်သည်။ ဤအရာသည် သင့်အား သတင်းအချက်အလတ်များကို လျင်မြန်စွာပေးပို့ရန် နည်းလမ်းတစ်ခုဖြစ်သလော၊ ၎င်းသည် သင့်အတွင်း၌ အချို့သော စံနှုန်းများကို သတ်မှတ်ရန်နည်းလမ်းဖြစ်ပါသလား။ ဒါကို ဘာကြောင့် လိုအပ်တာလဲ။ အဘယ်ကြောင့်ဆိုသော် ပြန်လည်သုံးသပ်မှုကို အလွန်လျင်မြန်စွာ လုပ်ဆောင်ရန် သို့မဟုတ် လုံးလုံးလျားလျား ပယ်ဖျက်ရန် လိုအပ်သောကြောင့် ဖြစ်သည်။ ၎င်းသည် transbase ဖွံ့ဖြိုးတိုးတက်မှုကဲ့သို့ပင်ဖြစ်သည် - ဇာတ်လမ်းသည် အလွန်လှပသော်လည်း ရင့်ကျက်သောယောက်ျားများအတွက်သာဖြစ်သည်။

မက်ထရစ်(၄)ခုနှင့်ပတ်သက်၍၊ ၎င်းကို အဘယ်အရာဖြစ်ပေါ်စေသည်ကို နားလည်ရန် ၎င်းတို့အား ဖယ်ရှားရန် အကြံပြုလိုပါသည်။ ဂဏန်းတွေကိုကြည့်၊ ပုံမှာကြည့်လိုက်၊ ဘယ်လောက်ဆိုးသလဲ၊

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

အဲဒါခက်ခဲရှုပ်ထွေးတယ်။ Toggle လုပ်ဆောင်ချက်အကြောင်း အသေးစိတ်အချက်အလက်များကို သင်ဖတ်ရှုလိုပါက၊ ကျွန်ုပ်သည် ၎င်းကို အထူးအကြံပြုလိုပါသည်။ https://trunkbaseddevelopment.com/. မာတင် Fowler ၏ အံ့သြဖွယ်ကောင်းသော ဆောင်းပါးသည် ခလုတ်ဖွင့်ခြင်းအင်္ဂါရပ်များအကြောင်းဖြစ်သည်- အမျိုးအစားများ ၊ ဘဝသံသရာစသည်ဖြင့် ခလုတ်နှိပ်ခြင်းအင်္ဂါရပ်သည် ရှုပ်ထွေးပါသည်။

"Jenkins လိုအပ်သလား၊ မရှိဘူးလား" ဆိုတဲ့မေးခွန်းကို သင်မဖြေရသေးပါ။

Jenkins သည် မည်သည့်ကိစ္စတွင်မဆို အမှန်တကယ် မလိုအပ်ပါ။ လေးနက်စွာပင်၊ ကိရိယာများ- Jenkins၊ Gitlab သည် သင့်အား အဆင်ပြေစေမည်ဖြစ်သည်။ စည်းဝေးပွဲသည် စည်းဝေးသည်ဖြစ်စေ၊ မစုဝေးသည်ကို သင်တွေ့လိမ့်မည်။ သူတို့က မင်းကိုကူညီနိုင်ပေမယ့် မင်းကိုလေ့ကျင့်ပေးမှာမဟုတ်ဘူး။ ၎င်းတို့သည် သင့်အား စက်ဝိုင်းတစ်ခုသာ ပေးနိုင်သည် - အိုကေ၊ မဟုတ်ဘူး၊ အိုကေ။ ပြီးတော့ စာမေးပွဲတွေလည်း ရေးထားရင်၊ စာမေးပွဲတွေ မရှိရင် အဓိပ္ပာယ်မရှိသလောက်ပါပဲ။ ထို့ကြောင့် ၎င်းသည် ပိုမိုအဆင်ပြေသောကြောင့် လိုအပ်သော်လည်း ယေဘူယျအားဖြင့် ၎င်းမပါဘဲ သင်နေထိုင်နိုင်ပြီး သင်အများကြီးဆုံးရှုံးမည်မဟုတ်ပါ။

အဲဒါက မင်းမှာ အလေ့အကျင့်ရှိရင် အဲဒါကို မလိုအပ်ဘူးလို့ ဆိုလိုတာလား။

မှန်တယ်။ Jez Humble စာမေးပွဲကို ကျွန်ုပ်အကြံပြုပါသည်။ အဲဒီမှာ နောက်ဆုံးအချက်အပေါ် သဘောထားကွဲလွဲမှုတွေရှိတယ်။ ဒါပေမယ့် ယေဘူယျအားဖြင့်၊ သင့်မှာ အရာသုံးခုရှိတယ်၊ အဆက်မပြတ်ပေါင်းစည်းမယ်၊ မာစတာထဲမှာ commits တွေကို စမ်းသပ်မှုတွေလုပ်တယ်၊ master in build ကို မြန်မြန်ပြင်မယ်၊ ပြီးတော့ တခြားဘာမှ မလိုအပ်တော့တာဖြစ်နိုင်တယ်။

ကျွန်ုပ်တို့သည် ပါဝင်သူများထံမှ မေးခွန်းများကို စောင့်ဆိုင်းနေချိန်တွင် ကျွန်ုပ်တွင် မေးခွန်းတစ်ခုရှိပါသည်။ ထုတ်ကုန်ကုဒ်အကြောင်းပဲ ပြောနေတာ။ အခြေခံအဆောက်အအုံကုဒ်အတွက် သင်အသုံးပြုဖူးပါသလား။ ကုဒ်တူသလား၊ တူညီသော နိယာမများနှင့် တူညီသော ဘဝသံသရာ ရှိသလား၊ သို့မဟုတ် မတူညီသော ဘဝသံသရာနှင့် သဘောတရားများ ရှိပါသလား။ အများအားဖြင့် လူတိုင်းက Continuous Integration and Development အကြောင်းပြောကြတဲ့အခါ၊ အခြေခံအဆောက်အအုံကုဒ်လည်း ရှိတယ်ဆိုတာ လူတိုင်းမေ့သွားတတ်ကြပါတယ်။ အခုနောက်ပိုင်းမှာ အဲဒါတွေ ပိုများလာတယ်။ ပြီးတော့ ဒီစည်းမျဥ်းတွေအားလုံးကို ယူဆောင်လာသင့်သလား။

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

ရပ်ပါ၊ ရပ်ပါ၊ bash script သည်ကုဒ်လည်းဖြစ်သည်။ အချစ်ဟောင်းကို မထိနဲ့။

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

ကျွန်ုပ်တို့သည် ကုဒ်အဖြစ် အခြေခံအဆောက်အဦနှင့် အလုပ်လုပ်သည်နှင့် တပြိုင်နက်၊ ကျွန်ုပ်တို့သည် developer များကဲ့သို့ ပြဿနာအားလုံးကို ရရှိပါသည်။ လွန်ခဲ့သောလအနည်းငယ်က၊ လုပ်ဖော်ကိုင်ဖက်တစ်ဦးက bash ဖြင့် လိုင်း 1 အတွက် ဆွဲထုတ်ရန် တောင်းဆိုမှုတစ်ခု ပေးပို့ခဲ့သည့် အခြေအနေနှင့် ကြုံတွေ့ခဲ့ရသည်။ ပြီး​တော့ သင်​က စမ်း​သပ်​မှု​မှာ 000 နာရီ​ကြာ​နေ​တယ်။ တူညီသောပြဿနာများပေါ်ပေါက်။ ကုဒ်ပဲရှိသေးတာ။ နောက်ပြီးတော့ ပူးပေါင်းဆောင်ရွက်ဆဲပါ။ ကျွန်ုပ်တို့သည် ဆွဲတင်တောင်းဆိုမှုတွင် မှီဝဲပြီး တူညီသော ပေါင်းစပ်ပဋိပက္ခများကို တူညီသော bash တွင် ဖြေရှင်းနေသည်ဟူသော အချက်နှင့် မှီဝဲနေရပါသည်။

ယခု ကျွန်ုပ်သည် ဤအရာအားလုံးကို အလှပဆုံး အင်ဖရာ ပရိုဂရမ်ရေးခြင်းအတွက် အလွန်တက်ကြွစွာ ကြည့်ရှုနေပါသည်။ ယခုကျွန်ုပ်သည် Pulumi ကို အခြေခံအဆောက်အအုံထဲသို့ ယူဆောင်လာခဲ့သည်။ ၎င်းသည် ၎င်း၏ အသန့်ရှင်းဆုံးပုံစံဖြင့် ပရိုဂရမ်ရေးဆွဲခြင်း ဖြစ်သည်။ အဲဒီမှာ ပိုကောင်းတာပေါ့၊ ဘာဖြစ်လို့လဲဆိုတော့ ငါ့မှာ ပရိုဂရမ်းမင်းဘာသာစကားရဲ့ စွမ်းဆောင်နိုင်ရည်တွေ အားလုံးရှိတယ်၊ ဆိုလိုတာက ifs တစ်ခုတည်းနဲ့ အပြာရောင်ကနေ လှပတဲ့ toggle ကို အပြာရောင်ကနေ ဖန်တီးပြီး အားလုံးအဆင်ပြေပါတယ်။ ဆိုလိုသည်မှာ ကျွန်ုပ်၏ပြောင်းလဲမှုသည် သခင်၌ရှိနေပြီဖြစ်သည်။ လူတိုင်းက သူ့ကို မြင်နိုင်နေပြီ။ တခြား အင်ဂျင်နီယာတွေလည်း သိပါတယ်။ အဲဒီမှာ တစ်ခုခု လွှမ်းမိုးနေပြီ။ သို့သော် အခြေခံအဆောက်အအုံအားလုံးအတွက် ၎င်းကို ဖွင့်မထားပါ။ ဥပမာအားဖြင့် ကျွန်ုပ်၏ စာမေးပွဲခုံများအတွက် ဖွင့်ထားသည်။ ထို့ကြောင့် သင့်မေးခွန်းကို ထပ်မံဖြေဆိုရန် လိုအပ်ပါသည်။ ကုဒ်ဖြင့်အလုပ်လုပ်သောအင်ဂျင်နီယာများကဲ့သို့ပင်ကျွန်ုပ်တို့အတွက်ဘဝပိုမိုလွယ်ကူစေသည်။

တခြားတစ်ယောက်ယောက်က မေးစရာရှိလို့လား။

မေးစရာရှိပါတယ်။ Oleg နဲ့ ဆွေးနွေးမှုတွေ ဆက်လုပ်ချင်တယ်။ ယေဘူယျအားဖြင့်၊ အလုပ်တစ်ခုပြီးမြောက်ဖို့ တစ်လလောက်ကြာရင်၊ ဗိသုကာပညာမှာ ပြဿနာရှိတယ်၊ ခွဲခြမ်းစိတ်ဖြာမှု၊ ပြိုကွဲမှု၊ စီစဉ်မှုစသဖြင့် ပြဿနာရှိနေတယ်လို့ ငါထင်တယ်၊ ဒါပေမယ့် မင်းစလုပ်ရင် ငါခံစားရတယ်။ Continuous Integration အရ အသက်ရှင်နေထိုင်ကြိုးစားပါ၊ ထို့နောက် သင်သည် နာကျင်မှုကို အစီအစဉ်ဆွဲခြင်းဖြင့် စတင်ပြင်ဆင်နိုင်သည်၊ အကြောင်းမှာ သင်သည် ၎င်းနှင့်ဝေးရာနေရာမှ လွတ်မြောက်မည်မဟုတ်ပါ။

(Oleg) ဟုတ်တယ်၊ မှန်တယ်။ ဤအလေ့အကျင့်သည် အခြားသော ပြင်းထန်သော ယဉ်ကျေးမှုကို ပြောင်းလဲသည့် အလေ့အကျင့်နှင့် ယှဉ်၍ အားထုတ်နိုင်သည်။ ကျော်လွှားရန် အခက်ခဲဆုံးအရာမှာ အလေ့အကျင့်များ အထူးသဖြင့် အကျင့်ဆိုးများဖြစ်သည်။ အကယ်၍ ဤအလေ့အကျင့်ကို အကောင်အထည်ဖော်ရန်အတွက် သင့်ပတ်ဝန်းကျင်ရှိသူများ၏ အလေ့အထကို ပြင်းထန်စွာပြောင်းလဲရန် လိုအပ်သည်- ဆော့ဖ်ဝဲအင်ဂျင်နီယာများ၊ စီမံခန့်ခွဲမှု၊ ထုတ်လုပ်ရေးမန်နေဂျာ၊ ထို့နောက် အံ့ဩစရာများက သင့်ကို စောင့်ကြိုနေပါသည်။

ဘယ်လိုအံ့သြစရာတွေရှိနိုင်မလဲ။ မကြာခဏ ပေါင်းစည်းမည်ဟု သင်ဆုံးဖြတ်သည်ဆိုပါစို့။ ပေါင်းစည်းခြင်းနှင့် ဆက်စပ်နေသော အခြားအရာများ ဥပမာ၊ ရှေးဟောင်းပစ္စည်းများ သင့်တွင်ရှိသည်။ ဥပမာအားဖြင့်၊ သင့်ကုမ္ပဏီတွင်၊ ပစ္စည်းတိုင်းကို ရှေးဟောင်းပစ္စည်းသိုလှောင်မှုစနစ်တွင် တစ်နည်းတစ်ဖုံအားဖြင့် ထည့်သွင်းတွက်ချက်ရမည့် မူဝါဒတစ်ခုရှိသည်။ ပြီးတော့ အချိန်တစ်ခုကြာတယ်။ ထုတ်လုပ်ရေးမန်နေဂျာအနေဖြင့် ၎င်းသည် ထုတ်လုပ်ရေးတွင် အဆင်သင့်ဖြစ်ပြီဖြစ်ကြောင်း သေချာစေရန် လူတစ်ဦးသည် ဤပစ္စည်းကို ထုတ်လုပ်ရန် အဆင်သင့်ဖြစ်ကြောင်း သေချာစေရန် ထုတ်ဝေရေးမန်နေဂျာအနေဖြင့် စမ်းသပ်စစ်ဆေးရန် လိုအပ်ပါသည်။ 5-10-15 မိနစ်ကြာသော်လည်း တစ်ပတ်လျှင် တစ်ကြိမ် layout လုပ်ပါက တစ်ပတ်လျှင် တစ်ကြိမ် နာရီဝက် သုံးစွဲခြင်းသည် အခွန်အနည်းငယ်သာဖြစ်သည်။

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

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

အကယ်၍ သင်သည်တစ်စုံတစ်ဦးထံမှအထောက်အထားလိုအပ်ပါက၊ သူဌေးက၎င်းကိုလက်မှတ်ထိုးရန် Vasya သည်ခွင့်ပြုသည်ဟုစသည်တို့ကိုမပြောဘဲထုတ်လုပ်ခြင်းသို့မ၀င်ပါ - ဤအမိုက်စားအရာအားလုံးသည်လေ့ကျင့်သူ၏နည်းလမ်းဖြစ်သည်။ ဘာကြောင့်လဲဆိုတော့ အခွန်နဲ့ဆက်စပ်တဲ့ လုပ်ဆောင်ချက်အချို့ရှိနေရင် အရာအားလုံးဟာ အဆ 100 တိုးလာလို့ပါပဲ။ ထို့ကြောင့် အပြောင်းအရွှေ့ကို လူတိုင်းက ပျော်ရွှင်စွာ နှုတ်ဆက်လေ့မရှိပေ။ ဘာကြောင့်လဲ ဆိုတော့ လူတွေရဲ့ အလေ့အထကို ပြောင်းလဲဖို့ ခက်တယ်။

လူတစ်ယောက်ဟာ သူ့ရဲ့ပုံမှန်အလုပ်တွေကို တွေးတောတွေးတောမနေဘဲ လုပ်နေတတ်ပါတယ်။ သူမ၏ မှတ်ဥာဏ်ဝန်သည် သုညဖြစ်သည်။ သူက အဲဒါကို ဝိုင်းကစားရုံပဲ၊ သူ့ခေါင်းထဲမှာ checklist တစ်ခုရှိနေပြီ၊ သူက အဲဒါကို အကြိမ်တစ်ထောင်ပြီးပြီ။ ပြီးတော့ မင်းသူ့ကိုလာပြောပြီးတာနဲ့ "ဒီအလေ့အကျင့်ကို ပယ်ဖျက်ပြီး တနင်္လာနေ့ကစပြီး အသစ်တစ်ခုကို မိတ်ဆက်ပေးလိုက်ရအောင်" ၊ သူ့အတွက်ကတော့ အားကောင်းတဲ့ သိမြင်မှုဆိုင်ရာဝန်ထုပ်ဝန်ပိုး ဖြစ်လာပါတယ်။ တစ်ချိန်တည်းမှာ လူတိုင်းဆီကို ရောက်လာတယ်။

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

ဤနေရာတွင် သင်လုပ်ဆောင်ရမည့်အရာကို ဦးစွာနားလည်သဘောပေါက်ထားရန် လိုအပ်သည်ဟု နိဂုံးချုပ်လာပါသည်။ လောကကြီးက စံမမီသလို ထုတ်ကုန်လည်း စံမမီဘူး။

ဟုတ်တယ်၊ ဒီအရာတွေက အပြန်အလှန်ဆက်စပ်နေတယ်။

လုပ်ငန်းရှင်များကလည်း ဤနည်းအတိုင်းသွားရမည်ကို အမြဲနားမလည်ပါ။

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

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

(Oleg) ဒါက ဂန္ထဝင် လွဲမှားမှုတစ်ခုပါ။ ယုံကြည်မှုရှိဖို့ လုံလောက်တဲ့ စမ်းသပ်မှုတွေ ရှိသင့်ပါတယ်။ ဆက်တိုက်ပေါင်းစည်းခြင်းသည် စစ်ဆေးမှုများ၏ 100% ကို ဦးစွာလုပ်ဆောင်ပြီးမှသာ ဤအလေ့အကျင့်ကို စတင်ကျင့်သုံးသည့် အရာမဟုတ်ပါ။ ဆက်တိုက်ပေါင်းစည်းခြင်းသည် သင့်မျက်လုံးဖြင့်မြင်ရသော ပြောင်းလဲမှုတစ်ခုစီတိုင်းသည် စမ်းသပ်မှုများမပြုလုပ်ဘဲ တစ်ခုခုကွဲသွားသည်ဖြစ်စေ၊ ပျက်သည်ဖြစ်စေ သင်နားလည်နိုင်သောကြောင့် စဉ်ဆက်မပြတ်ပေါင်းစပ်ခြင်းသည် သင်၏သိမြင်နိုင်စွမ်းကို လျော့နည်းစေသည်။ အပြောင်းအလဲများသည် သေးငယ်သောကြောင့် သင့်ခေါင်းထဲတွင် ၎င်းကို လျှင်မြန်စွာ စမ်းသပ်နိုင်သည်။ သင့်တွင် လက်စွဲစမ်းသပ်သူများသာရှိလျှင်ပင် ၎င်းတို့အတွက်လည်း ပိုမိုလွယ်ကူပါသည်။ မင်းက လှိမ့်ထုတ်ပြီး "ကြည့်စမ်း၊ တစ်ခုခု ကွဲသွားပြီလား?" သူတို့က စစ်ဆေးပြီး “မဟုတ်ဘူး၊ ဘာမှ မကွဲဘူး” လို့ပြောတယ်။ အဘယ်ကြောင့်ဆိုသော် စမ်းသပ်သူသည် မည်သည့်နေရာတွင် ကြည့်ရမည်ကို သိသောကြောင့်ဖြစ်သည်။ သင့်တွင် ကုဒ်အပိုင်းအစတစ်ခုနှင့် ဆက်စပ်သော ကုဒ်တစ်ခုရှိသည်။ ၎င်းကို သီးခြားအပြုအမူဖြင့် အသုံးချသည်။

ဤတွင်သင်, သင်တန်း, အလှဆင်။

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

(Oleg) အင်း၊ ငါ အဲဒီ့နေရာကို မရောက်သေးဘူး။ ပထမဆုံး ထင်ယောင်ထင်မှားမှာ သင်သည် စာမေးပွဲများ 100% ရေးရန် လိုအပ်သည် သို့မဟုတ် ဆက်တိုက်ပေါင်းစည်းမှု လုံးဝပြုလုပ်ရန် မလိုအပ်ပါ။ မမှန်ပါဘူး။ ဤနှစ်ခုသည် ပြိုင်တူကျင့်စဉ်များဖြစ်သည်။ ၎င်းတို့သည် တိုက်ရိုက်မှီခိုခြင်း မရှိပါ။ သင်၏စမ်းသပ်မှုလွှမ်းခြုံမှုသည် အကောင်းဆုံးဖြစ်ရပါမည်။ အကောင်းဆုံး - ဆိုလိုသည်မှာ ကတိကဝတ်ပြုပြီးနောက်တွင် ကျန်ခဲ့သော သင်၏သခင်၏အရည်အသွေးသည် မူးနေသောသောကြာညနေခင်းတွင် "Deploy" ခလုတ်ကို ယုံကြည်စိတ်ချစွာ နှိပ်နိုင်သည်ကို သင်ကိုယ်တိုင်ယုံကြည်မှုရှိကြောင်း ဆိုလိုသည်။ ဒါကို သင်ဘယ်လိုအောင်မြင်မလဲ။ ပြန်လည်သုံးသပ်ခြင်းမှတဆင့်၊ လွှမ်းခြုံမှုမှတဆင့်၊ ကောင်းမွန်သောစောင့်ကြည့်မှုမှတဆင့်။

ကောင်းမွန်သော စောင့်ကြည့်စစ်ဆေးမှုသည် စမ်းသပ်မှုများနှင့် ခွဲခြား၍မရပေ။ pre prod တွင် တစ်ကြိမ် စမ်းသပ်မှုများ လုပ်ဆောင်ပါက၊ ၎င်းတို့သည် သင်၏ အသုံးပြုသူ scripts အားလုံးကို တစ်ကြိမ် စစ်ဆေးပြီး ဒါပါပဲ။ အကယ်၍ သင်သည် ၎င်းတို့အား အဆုံးမရှိသော ကွင်းဆက်တစ်ခုတွင် လုပ်ဆောင်ပါက၊ ၎င်းသည် ပျက်ကျသည်ဖြစ်စေ၊ ပျက်သည်ဖြစ်စေ အရာအားလုံးကို အဆုံးမရှိ စမ်းသပ်ပေးသည့် သင်၏ ဖြန့်ကျက်စောင့်ကြည့်ရေးစနစ်ဖြစ်သည်။ ဤကိစ္စတွင်၊ တစ်ကြိမ်၊ နှစ်ကြိမ်ပြုလုပ်သည်ဖြစ်စေ တစ်ခုတည်းသောကွာခြားချက်ဖြစ်သည်။ အလွန်ကောင်းမွန်သော စာမေးပွဲများ... အဆုံးမရှိ လုပ်ဆောင်နေသည်၊ ဤသည်မှာ စောင့်ကြည့်ခြင်းပင်ဖြစ်သည်။ မှန်ကန်သော စောင့်ကြည့်မှု သည် ဤကဲ့သို့ ဖြစ်သင့်သည်။

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

Continuous Integration ကို နည်းနည်းပြန်သွားကြည့်ရအောင်။ ကျွန်ုပ်တို့သည် အနည်းငယ် ကွဲပြားသော ရှုပ်ထွေးသော အလေ့အကျင့်တစ်ခုသို့ ထွက်ပြေးသွားခဲ့သည်။

ပြီးတော့ ဒုတိယ ထင်ယောင်ထင်မှား ကတော့ MVP က မြန်မြန်ဆန်ဆန် လုပ်ဖို့ လိုတယ် ဆိုတော့ စာမေးပွဲ တွေ မှာ လုံးဝ မလိုအပ်ဘူး ။ ဒီနည်းနဲ့ မသေချာဘူး။ အမှန်မှာ MVP တွင် အသုံးပြုသူပုံပြင်တစ်ပုဒ်ကို သင်ရေးသားသည့်အခါတွင် ၎င်းကို ဘောလုံးပေါ်တွင် ဖန်တီးနိုင်သည်၊ ဆိုလိုသည်မှာ အသုံးပြုသူဇာတ်လမ်းမျိုးရှိကြောင်းကို သင်ကြားပြီး ၎င်းကို ကုဒ်လုပ်ရန် ချက်ချင်းပြေးခြင်း သို့မဟုတ် TDD ကို အသုံးပြု၍ လုပ်ဆောင်နိုင်သည်။ TDD ၏အဆိုအရ၊ လက်တွေ့ပြသထားသည့်အတိုင်း၊ ၎င်းသည်ပိုကြာမည်မဟုတ်ပါ၊ ဆိုလိုသည်မှာစမ်းသပ်မှုများသည်ဘေးထွက်ဆိုးကျိုးဖြစ်သည်။ TDD ၏အလေ့အကျင့်သည်စမ်းသပ်ခြင်းအကြောင်းမဟုတ်ပါ။ Test Driven Development ဟုခေါ်သော်လည်း၊ ၎င်းသည် စစ်ဆေးမှုများနှင့် လုံးဝပတ်သက်ခြင်းမရှိပါ။ ဒါကလည်း ဗိသုကာဆိုင်ရာ ချဉ်းကပ်မှုတစ်ခုလည်း ဖြစ်ပါတယ်။ ဤသည်မှာ လိုအပ်သည်များကို အတိအကျရေးရန်နှင့် မလိုအပ်သောအရာကို မရေးရန် ချဉ်းကပ်မှုဖြစ်သည်။ ဤသည်မှာ အပလီကေးရှင်းဗိသုကာတစ်ခုဖန်တီးခြင်းနှင့်ပတ်သက်၍ သင်၏စဉ်းစားတွေးခေါ်မှုနောက်ထပ်ထပ်လုပ်ခြင်းအပေါ် အာရုံစိုက်ခြင်းအလေ့အကျင့်တစ်ခုဖြစ်သည်။

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

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

(Dmitry) ဒီနေရာမှာ လူတော်တော်များများက MVP လို့ ခေါ်ရင် သာမန်စာရေးဖို့ ပျင်းကြတယ်။ ပြီးတော့ ဒါတွေက ကွဲပြားနေသေးတယ်။ MVP ကို ​​အလုပ်မလုပ်သော မကောင်းသောအရာအဖြစ်သို့ ပြောင်းလဲရန် မလိုအပ်ပါ။

ဟုတ်တယ်၊ မင်းပြောတာမှန်တယ်။

ပြီးတော့ ရုတ်တရက် MVP နဲ့ ရော့။

ထာဝရအမြဲတမ်း။

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

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

(Dmitry) အခြေခံအဆောက်အအုံ လည်ပတ်မှုအမြင်ကနေ ဒီစိတ်ကူးကို ချဲ့ထွင်နိုင်ပါတယ်။ အသစ်အဆန်းတစ်ခုခုကို မလွှင့်ခင်မှာ စောင့်ကြည့်ပြီး စတင်လိုက်ပါ။ ဤကိစ္စတွင်၊ စောင့်ကြည့်ခြင်းသည် ကျွန်ုပ်တို့အတွက် ပုံမှန်စမ်းသပ်မှုဖြစ်လာသည်။ စောင့်ကြည့်ခြင်းအားဖြင့် ဖွံ့ဖြိုးတိုးတက်မှုတွေ ရှိနေပါတယ်။ ဒါပေမယ့် လူတိုင်းနီးပါးက ရှည်တယ်၊ ငါပျင်းတယ်၊ ယာယီမူကြမ်းတစ်ခု လုပ်ခဲ့တယ်တဲ့။ ပုံမှန်စောင့်ကြည့်မှု ပြုလုပ်ပြီးပါက CI စနစ်၏ အခြေအနေကို နားလည်ပါသည်။ ပြီးတော့ CI စနစ်မှာ စောင့်ကြည့်မှုတွေ အများကြီးရှိတယ်။ ကျွန်ုပ်တို့သည် စနစ်၏အခြေအနေကို နားလည်သည်၊ ၎င်းအတွင်း၌ရှိသောအရာကို ကျွန်ုပ်တို့နားလည်သည်။ ပြီးတော့ ဖွံ့ဖြိုးတိုးတက်ရေးကာလမှာ ကျွန်တော်တို့က လိုချင်တဲ့အခြေအနေရောက်အောင် စနစ်ကိုပဲ ဖန်တီးနေပါတယ်။

ဤအလေ့အကျင့်များကို အချိန်အတော်ကြာအောင် သိမြင်လာခဲ့သည်။ ဒါကို လွန်ခဲ့တဲ့ ၄ နှစ်လောက်က ဆွေးနွေးခဲ့ကြတယ်။ ဒါပေမယ့် 4 နှစ်တာအတွင်း လက်တွေ့မှာတော့ ဘာမှမပြောင်းလဲပါဘူး။

ဒါပေမယ့် ဒီမှတ်စုမှာတော့ တရားဝင် ဆွေးနွေးမှုကို အဆုံးသတ်ဖို့ အဆိုပြုပါတယ်။

ဗီဒီယို (မီဒီယာဒြပ်စင်တစ်ခုအနေဖြင့် ထည့်သွင်းထားသော်လည်း အကြောင်းတစ်ခုခုကြောင့် အလုပ်မလုပ်ပါ)

https://youtu.be/zZ3qXVN3Oic

source: www.habr.com