ဇာတ်ညွှန်းများမှ ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ပလပ်ဖောင်းသို့- CIAN တွင် ကျွန်ုပ်တို့ အလိုအလျောက် ဖွံ့ဖြိုးတိုးတက်လာပုံ

RIT 2019 တွင် ကျွန်ုပ်တို့၏လုပ်ဖော်ကိုင်ဖက် Alexander Korotkov က ပြုလုပ်ခဲ့သည်။ အစီရင်ခံစာ CIAN တွင် ဖွံ့ဖြိုးတိုးတက်မှု၏ အလိုအလျောက်စနစ်နှင့်ပတ်သက်ပြီး- ဘဝနှင့်အလုပ် ရိုးရှင်းစေရန် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် Integro ပလပ်ဖောင်းကို အသုံးပြုပါသည်။ ၎င်းသည် လုပ်ငန်းဆောင်တာများ၏ ဘဝစက်ဝန်းကို ခြေရာခံကာ၊ ပုံမှန်လုပ်ငန်းဆောင်တာများ၏ developer များကို သက်သာစေပြီး ထုတ်လုပ်မှုတွင် ချွတ်ယွင်းမှုအရေအတွက်ကို သိသိသာသာ လျှော့ချပေးသည်။ ဤပို့စ်တွင်၊ ကျွန်ုပ်တို့သည် Alexander ၏အစီရင်ခံစာကို ဖြည့်စွက်ပြီး ရိုးရှင်းသော scripts များမှ ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ပလပ်ဖောင်းမှတဆင့် open source ထုတ်ကုန်များကို ပေါင်းစပ်ပြီး ကျွန်ုပ်တို့၏ သီးခြားအလိုအလျောက်စနစ်လုပ်ဆောင်သည့်အဖွဲ့မှ လုပ်ဆောင်ပုံကို ပြောပြပါမည်။
 

သုညအဆင့်

"သုညအဆင့်လောက်တော့ မရှိဘူး၊ ငါလည်း မသိဘူး"
"Kung Fu Panda" ရုပ်ရှင်ထဲက Master Shifu

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

ထိုအချိန်တွင်၊ ကျွန်ုပ်တို့တွင် Linux/Windows ဆာဗာများပေါ်တွင် အသုံးပြုထားသော Python, C# နှင့် PHP တို့၏ ကြီးမားသော monolith တစ်ခုရှိသည်။ ဤဘီလူးကို အသုံးချရန် ကျွန်ုပ်တို့တွင် ကျွန်ုပ်တို့ကိုယ်တိုင် လုပ်ဆောင်သည့် ဇာတ်ညွှန်းအစုံရှိသည်။ အကိုင်းအခက်များကို ပေါင်းစည်းခြင်း၊ ချို့ယွင်းချက်များကို ပြုပြင်ခြင်းနှင့် “တည်ဆောက်မှုတွင် မတူညီသောအလုပ်များ” ဖြင့် ပြန်လည်တည်ဆောက်သည့်အခါ ပဋိပက္ခများကြောင့် နာကျင်ကိုက်ခဲမှုနှင့် ဝေဒနာများကို ဆောင်ကြဉ်းပေးသည့် မိုနီ၏စည်းဝေးပွဲလည်း ရှိခဲ့သည်။ ရိုးရှင်းသော လုပ်ငန်းစဉ်သည် ဤကဲ့သို့ ဖြစ်သည်-

ဤအရာကို ကျွန်ုပ်တို့ မကျေမနပ်ဖြစ်ပြီး ထပ်ခါတလဲလဲ လုပ်ဆောင်နိုင်သော၊ အလိုအလျောက် စီမံနိုင်သော တည်ဆောက်မှုနှင့် အသုံးချမှု လုပ်ငန်းစဉ်ကို တည်ဆောက်လိုပါသည်။ ယင်းအတွက်၊ ကျွန်ုပ်တို့သည် CI/CD စနစ် လိုအပ်ပြီး Teamcity ၏ အခမဲ့ဗားရှင်းနှင့် Jenkins ၏ အခမဲ့ဗားရှင်းကြားတွင် ကျွန်ုပ်တို့သည် ၎င်းတို့နှင့် လုပ်ဆောင်ခဲ့ပြီး လုပ်ဆောင်ချက်အစုံအလင်ဖြင့် ကျွန်ုပ်တို့နှင့် နှစ်ဦးစလုံး ကိုက်ညီသောကြောင့် ရွေးချယ်ခဲ့သည်။ ကျွန်ုပ်တို့သည် Teamcity ကို မကြာသေးမီက ထုတ်ကုန်တစ်ခုအဖြစ် ရွေးချယ်ခဲ့သည်။ ထိုအချိန်တွင်၊ ကျွန်ုပ်တို့သည် မိုက်ခရိုဆားဗစ်ဗိသုကာကို အသုံးမပြုသေးဘဲ အလုပ်များနှင့် ပရောဂျက်အများအပြားကို မမျှော်လင့်ထားမိသေးပါ။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ ကိုယ်ပိုင်စနစ်၏ အယူအဆကို ရောက်ရှိလာပါသည်။

Teamcity ကို အကောင်အထည်ဖော်ခြင်းသည် လက်စွဲအလုပ်၏ တစ်စိတ်တစ်ပိုင်းကိုသာ ဖယ်ရှားလိုက်သည်- ကျန်အရာမှာ Pull Requests ဖန်တီးခြင်း၊ Jira ရှိ အဆင့်အလိုက် ပြဿနာများကို မြှင့်တင်ခြင်းနှင့် ထုတ်ဝေရန်အတွက် ရွေးချယ်ခြင်းဆိုင်ရာ ပြဿနာများဖြစ်သည်။ Teamcity စနစ်က ဒါကို မကိုင်တွယ်နိုင်တော့ဘူး။ နောက်ထပ် automation ၏လမ်းကြောင်းကိုရွေးချယ်ရန်လိုအပ်သည်။ Teamcity တွင် scripts များဖြင့် လုပ်ဆောင်ရန် သို့မဟုတ် ပြင်ပမှ အလိုအလျောက်စနစ်သို့ ပြောင်းခြင်းအတွက် ရွေးချယ်မှုများကို ကျွန်ုပ်တို့ ထည့်သွင်းစဉ်းစားထားပါသည်။ သို့သော် နောက်ဆုံးတွင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဖြေရှင်းချက်တစ်ခုသာပေးနိုင်သည့် အမြင့်ဆုံးပြောင်းလွယ်ပြင်လွယ်လိုအပ်ကြောင်း ဆုံးဖြတ်ခဲ့သည်။ ဤသည်မှာ Integro ဟုခေါ်သော စက်တွင်း အလိုအလျောက်စနစ်၏ ပထမဗားရှင်း ပေါ်လာပုံဖြစ်သည်။

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

လုပ်ငန်းလုပ်ငန်းစဉ်များတွင် အလိုအလျောက်စနစ်များ တိုးလာခြင်းကြောင့် Teamcity တွင် ပရောဂျက်များနှင့် လုပ်ဆောင်မှုများ များပြားလာသည်။ ထို့ကြောင့် ပြဿနာအသစ်တစ်ခုရောက်လာသည်- အခမဲ့ Teamcity ဥပမာတစ်ခုသည် မလုံလောက်ပါ (အေးဂျင့် 3 ဦးနှင့် ပရောဂျက် 100)၊ ကျွန်ုပ်တို့သည် အခြားဥပမာတစ်ခု (နောက်ထပ် အေးဂျင့် 3 ဦးနှင့် ပရောဂျက် 100) ကို ပေါင်းထည့်ခဲ့သည်။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် စီမံခန့်ခွဲရန်ခက်ခဲသော အစုအဝေးများစွာရှိသော စနစ်တစ်ခုဖြင့် အဆုံးသတ်ခဲ့သည်-

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

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

ကျွန်ုပ်တို့သည် စမ်းသပ်မှုကို အလိုအလျောက်လုပ်ဆောင်ပါသည်။

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

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

အလိုအလျောက်စနစ်အဖွဲ့

လက်ရှိတွင် ကျွန်ုပ်တို့တွင် developer 130 ၏ ဝန်ထမ်းတစ်ဦးရှိပြီး ဆက်လက်လုပ်ဆောင်နေပါသည်။ ကြီးထွား. စဉ်ဆက်မပြတ်ပေါင်းစပ်ခြင်းနှင့် ကုဒ်ပေးပို့ခြင်းအတွက် အဖွဲ့ (ယခုနောက်ပိုင်းတွင် ဖြန့်ကျက်ခြင်းနှင့် ပေါင်းစည်းခြင်း သို့မဟုတ် DI အဖွဲ့ဟု ရည်ညွှန်းသည်) တွင် လူ 7 ဦးပါဝင်ပြီး Integro အလိုအလျောက်စနစ်ဆိုင်ရာ ပလပ်ဖောင်းဖွံ့ဖြိုးတိုးတက်ရေးနှင့် DevOps တို့ကို လမ်းညွှန်ချက် 2 ခုဖြင့် လုပ်ဆောင်သည်။ 

DevOps သည် CIAN site ၏ Dev/Beta ပတ်ဝန်းကျင်၊ Integro ပတ်၀န်းကျင်၊ developer များအား ပြဿနာများကို ဖြေရှင်းပေးကာ အရွယ်အစားချဲ့ထွင်သည့် ပတ်ဝန်းကျင်အတွက် ချဉ်းကပ်မှုအသစ်များကို ဖန်တီးပေးသည်။ Integro ဖွံ့ဖြိုးတိုးတက်ရေးဦးတည်ချက်သည် Integro ကိုယ်တိုင်နှင့် ဆက်စပ်ဝန်ဆောင်မှုများ နှစ်ခုလုံးနှင့် သက်ဆိုင်သည်၊ ဥပမာအားဖြင့်၊ Jenkins၊ Jira၊ Confluence အတွက် ပလပ်အင်များနှင့် ဖွံ့ဖြိုးရေးအဖွဲ့များအတွက် အရန် utilities များနှင့် applications များကိုလည်း ပြုစုပေးပါသည်။ 

DI အဖွဲ့သည် ဗိသုကာလက်ရာများ၊ စာကြည့်တိုက်များနှင့် ဖွံ့ဖြိုးတိုးတက်ရေးဆိုင်ရာ ချဉ်းကပ်မှုများကို အတွင်းပိုင်း၌ ဖော်ဆောင်ပေးသော ပလပ်ဖောင်းအဖွဲ့နှင့် ပူးပေါင်းလုပ်ဆောင်သည်။ တစ်ချိန်တည်းမှာပင်၊ CIAN အတွင်းရှိ developer များသည် အလိုအလျောက်စနစ်အတွက် အထောက်အကူပြုနိုင်သည်၊ ဥပမာအားဖြင့်၊ အဖွဲ့၏လိုအပ်ချက်များနှင့်ကိုက်ညီစေရန် micro-automation ပြုလုပ်ခြင်း သို့မဟုတ် automation ပိုကောင်းအောင်ပြုလုပ်နည်းကို အကြံကောင်းတစ်ခုကို မျှဝေပါ။

CIAN တွင် အလိုအလျောက်စနစ်၏ အလွှာကိတ်မုန့်

အလိုအလျောက်စနစ်တွင် ပါဝင်သော စနစ်အားလုံးကို အလွှာများစွာ ခွဲခြားနိုင်သည်-

1. ပြင်ပစနစ်များ (Jira၊ Bitbucket စသည်ဖြင့်)။ ဖွံ့ဖြိုးရေးအဖွဲ့တွေက သူတို့နဲ့လုပ်တယ်။
2. Integro ပလပ်ဖောင်း။ အများစုမှာ developer များသည် ၎င်းနှင့် တိုက်ရိုက်အလုပ်မလုပ်သော်လည်း ၎င်းသည် automation အားလုံးကို ဆက်လက်လည်ပတ်စေသည်။
3. ပို့ဆောင်မှု၊ စည်းရုံးမှုနှင့် ရှာဖွေတွေ့ရှိမှု ဝန်ဆောင်မှုများ (ဥပမာ၊ Jeknins၊ ကောင်စစ်ဝန်၊ Nomad)။ ၎င်းတို့၏အကူအညီဖြင့်၊ ကျွန်ုပ်တို့သည် ဆာဗာများပေါ်တွင် ကုဒ်ကိုဖြန့်ကျက်ပြီး ဝန်ဆောင်မှုများ တစ်ခုနှင့်တစ်ခု လုပ်ဆောင်ကြောင်း သေချာစေသည်။
4. ရုပ်ပိုင်းဆိုင်ရာအလွှာ (ဆာဗာများ၊ OS၊ ဆက်စပ်ဆော့ဖ်ဝဲ)။ ကျွန်ုပ်တို့၏ကုဒ်သည် ဤအဆင့်တွင် လုပ်ဆောင်ပါသည်။ ၎င်းသည် ရုပ်ပိုင်းဆိုင်ရာဆာဗာ သို့မဟုတ် virtual တစ်ခု (LXC၊ KVM၊ Docker) ဖြစ်နိုင်သည်။

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

အရင်အတိုင်း

Integro ကိုအာရုံစိုက်ပြီး နည်းပညာအစုအဝေးဖြင့် စတင်ကြပါစို့။

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (Integro monolith အဟောင်းသည် Java 8 တွင် ရှိနေမည်)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql ၁၁
• ယုန် MQ 
• Apache Ignite
• Camunda (မြှပ်နှံထားသည်)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• ဝဘ် UI- တုံ့ပြန်မှု (CSR) + MobX
• SSO- သော့ချိတ်

ကျွန်ုပ်တို့သည် Integro ၏အစောပိုင်းဗားရှင်းတစ်ခု၏ monolith ပုံစံဖြင့် အမွေအနှစ်များရှိနေသော်လည်း၊ ကျွန်ုပ်တို့သည် အသေးစားဝန်ဆောင်မှုဖွံ့ဖြိုးတိုးတက်ရေးနိယာမကို လိုက်နာပါသည်။ မိုက်ခရိုဝန်ဆောင်မှုတစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင် Docker ကွန်တိန်နာတွင် လုပ်ဆောင်နေပြီး ဝန်ဆောင်မှုများသည် HTTP တောင်းဆိုမှုများနှင့် RabbitMQ မက်ဆေ့ဂျ်များမှတစ်ဆင့် အချင်းချင်း ဆက်သွယ်သည်။ Microservices များသည် Consul မှတဆင့် အပြန်အလှန်ရှာဖွေပြီး SSO (Keycloak၊ OAuth 2/OpenID Connect) မှတဆင့် ခွင့်ပြုချက်ရယူပြီး ၎င်းထံ တောင်းဆိုချက်တစ်ခုပြုလုပ်ပါ။

လက်တွေ့ဘဝနမူနာအနေဖြင့် အောက်ပါအဆင့်များပါ၀င်သော Jenkins နှင့် အပြန်အလှန်ဆက်ဆံခြင်းကို စဉ်းစားပါ။

1. အလုပ်အသွားအလာ စီမံခန့်ခွဲမှု မိုက်ခရိုဝန်ဆောင်မှု (ယခုနောက်ပိုင်းတွင် Flow microservice အဖြစ် ရည်ညွှန်းသည်) သည် Jenkins တွင် တည်ဆောက်မှုကို လုပ်ဆောင်လိုသည်။ ၎င်းကိုလုပ်ဆောင်ရန်၊ Jenkins နှင့်ပေါင်းစည်းရန်အတွက် microservice ၏ IP:PORT ကိုရှာဖွေရန် Consul ကိုအသုံးပြုပြီး Jenkins တွင်တည်ဆောက်မှုစတင်ရန် ၎င်းထံ asynchronous တောင်းဆိုချက်တစ်ခုပေးပို့သည်။
2. တောင်းဆိုမှုတစ်ခုကို လက်ခံရရှိပြီးနောက်၊ Jenkins microservice သည် အလုပ်၏ရလဒ်ကို သိရှိနိုင်စေရန် အသုံးပြုနိုင်သည့် Job ID ဖြင့် ထုတ်ပေးပြီး တုံ့ပြန်ပါသည်။ တစ်ချိန်တည်းမှာပင်၊ ၎င်းသည် REST API ခေါ်ဆိုမှုမှတစ်ဆင့် Jenkins တွင် တည်ဆောက်မှုကို အစပျိုးစေသည်။
3. Jenkins သည် တည်ဆောက်မှုကို လုပ်ဆောင်ပြီး ပြီးစီးပြီးနောက်၊ လုပ်ဆောင်ချက်ရလဒ်များနှင့်အတူ Jenkins မိုက်ခရိုဝန်ဆောင်မှုထံသို့ ဝဘ်ချိတ်တစ်ခု ပေးပို့သည်။
4. Jenkins microservice သည် webhook ကိုလက်ခံရရှိပြီးနောက်၊ တောင်းဆိုမှုလုပ်ဆောင်ခြင်းပြီးစီးမှုနှင့်ပတ်သက်ပြီး မက်ဆေ့ချ်တစ်ခုထုတ်ပေးပြီး အကောင်အထည်ဖော်မှုရလဒ်များကို ၎င်းတွင် ပူးတွဲထားသည်။ ထုတ်လုပ်ထားသော မက်ဆေ့ဂျ်ကို RabbitMQ တန်းစီရန် ပေးပို့သည်။
5. RabbitMQ မှတဆင့် ထုတ်ပြန်ထားသော မက်ဆေ့ချ်သည် တောင်းဆိုချက်မှ Job ID နှင့် လက်ခံရရှိထားသော မက်ဆေ့ချ်ကို ကိုက်ညီခြင်းဖြင့် ၎င်း၏လုပ်ငန်းလုပ်ဆောင်ခြင်း၏ ရလဒ်ကို သိရှိသည့် Flow microservice သို့ ရောက်ရှိသည်။

ယခု ကျွန်ုပ်တို့တွင် အုပ်စုများစွာ ခွဲခြားနိုင်သော အသေးစားဝန်ဆောင်မှု 30 ခန့်ရှိသည်။

1. ဖွဲ့စည်းမှုစီမံခန့်ခွဲမှု။
2. သတင်းအချက်အလက်နှင့် အသုံးပြုသူများ (တမန်များ၊ မေးလ်) နှင့် အပြန်အလှန် ဆက်သွယ်မှု။
3. အရင်းအမြစ်ကုဒ်နှင့်အတူအလုပ်လုပ်။
4. အသုံးချကိရိယာများ (ဂျိန်းကင်များ၊ ခြေသလုံး၊ ကောင်စစ်ဝန် စသည်ဖြင့်) ပေါင်းစပ်ခြင်း။
5. စောင့်ကြည့်ခြင်း (ထုတ်ဝေမှုများ၊ အမှားအယွင်းများ စသည်)။
6. ဝဘ်အသုံးအဆောင်များ (စမ်းသပ်မှုပတ်ဝန်းကျင်များကို စီမံခန့်ခွဲရန်၊ စာရင်းအင်းများစုဆောင်းခြင်း စသည်ဖြင့်)။
7. အလုပ်ခြေရာခံကိရိယာများနှင့် အလားတူစနစ်များနှင့် ပေါင်းစပ်ခြင်း။
8. မတူညီသောအလုပ်များအတွက် Workflow စီမံခန့်ခွဲမှု။

အလုပ်အသွားအလာ အလုပ်များ

Integro သည် Task lifecycle နှင့် သက်ဆိုင်သည့် လုပ်ဆောင်ချက်များကို အလိုအလျောက်ပြန်လုပ်ပေးသည်။ ရိုးရှင်းသောစကားအရ အလုပ်တစ်ခု၏ဘဝသံသရာကို Jira ရှိ အလုပ်တစ်ခု၏လုပ်ငန်းအသွားအလာအဖြစ် နားလည်မည်ဖြစ်သည်။ ကျွန်ုပ်တို့၏ ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်များတွင် ပရောဂျက်၊ အလုပ်အမျိုးအစားနှင့် သီးခြားလုပ်ငန်းတစ်ခုတွင် ရွေးချယ်ထားသည့် ရွေးချယ်စရာများပေါ်မူတည်၍ အလုပ်အသွားအလာ ကွဲပြားမှုများရှိသည်။ 

ကျွန်ုပ်တို့ အများဆုံးအသုံးပြုသည့် အလုပ်အသွားအလာကို ကြည့်ကြပါစို့။

ပုံတွင်၊ ဂီယာသည် အကူးအပြောင်းကို Integro မှ အလိုအလျောက် ခေါ်ဆိုကြောင်း ညွှန်ပြပြီး လူသားပုံသဏ္ဍာန်သည် အသွင်ကူးပြောင်းမှုကို လူတစ်ဦးမှ ကိုယ်တိုင်ခေါ်ဆိုကြောင်း ညွှန်ပြသည်။ ဤလုပ်ငန်းအသွားအလာတွင် အလုပ်တစ်ခုလုပ်ဆောင်နိုင်သည့် လမ်းကြောင်းများစွာကို ကြည့်ကြပါစို့။

ကိန္နရီစမ်းသပ်မှုများမပါဘဲ DEV+BETA တွင် ကိုယ်တိုင်စမ်းသပ်ခြင်း (ပုံမှန်အားဖြင့် ဤသည်မှာ ကျွန်ုပ်တို့သည် monolith ကိုထုတ်လွှတ်ပုံဖြစ်သည်)။

အခြားအကူးအပြောင်း ပေါင်းစပ်မှုများလည်း ရှိနိုင်ပါသည်။ တစ်ခါတစ်ရံတွင် ပြဿနာတက်မည့်လမ်းကြောင်းကို Jira တွင် ရွေးချယ်မှုများမှတစ်ဆင့် ရွေးချယ်နိုင်သည်။

အလုပ်လှုပ်ရှားမှု

အလုပ်တစ်ခုသည် "DEV Testing + Canary Tests" အလုပ်အသွားအလာကို ဖြတ်သန်းသည့်အခါ လုပ်ဆောင်ရမည့် အဓိကအဆင့်များကို ကြည့်ကြပါစို့။

1. ဆော့ဖ်ဝဲရေးသားသူ သို့မဟုတ် PM သည် လုပ်ဆောင်စရာကို ဖန်တီးသည်။

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

3. Jira သည် Jira microservice သို့ Webhook ပေးပို့သည် (Jira နှင့် ပေါင်းစည်းမှုအတွက် တာဝန်ရှိသည်)။

4. Jira microservice သည် အလုပ်အသွားအလာကိုစတင်ရန် Flow ဝန်ဆောင်မှု (အလုပ်လုပ်ဆောင်သည့်အတွင်းပိုင်းအလုပ်အသွားအလာများအတွက် တာဝန်ရှိသည်) သို့ တောင်းဆိုချက်တစ်ခုပေးပို့သည်။

5. Flow ဝန်ဆောင်မှုအတွင်းပိုင်း-

• ပြန်လည်သုံးသပ်သူများကို တာဝန်ပေးအပ်ခြင်းခံရသည် (အသုံးပြုသူများ၏ မိုက်ခရိုဝန်ဆောင်မှု + Jira microservice)။
• Source microservice မှတဆင့် (၎င်းသည် repositories နှင့် branchs များအကြောင်းကိုသိသော်လည်း code ကိုယ်တိုင်နှင့်အလုပ်မလုပ်ပါ) သည်ကျွန်ုပ်တို့၏ပြဿနာ၏အခွဲပါရှိသော repositories အတွက်ရှာဖွေမှုကိုပြုလုပ်သည် (ရှာဖွေမှုကိုရိုးရှင်းစေရန်၊ ဌာနခွဲအမည်သည် ပြဿနာနှင့်တိုက်ဆိုင်ပါသည်။ Jira တွင်နံပါတ်)။ အများစုမှာ၊ လုပ်ငန်းတစ်ခုတွင် repository တစ်ခုတွင် ဌာနခွဲတစ်ခုသာရှိသည်၊ ၎င်းသည် deployment queue ၏စီမံခန့်ခွဲမှုကို ရိုးရှင်းစေပြီး repositories များကြားချိတ်ဆက်မှုကို လျှော့ချပေးသည်။
• တွေ့ရှိသောဌာနခွဲတစ်ခုစီအတွက်၊ အောက်ပါလုပ်ဆောင်မှုများ၏ အစီအစဥ်ကို လုပ်ဆောင်သည်-

  i) မာစတာဌာနခွဲကို အပ်ဒိတ်လုပ်ခြင်း (ကုဒ်ဖြင့်လုပ်ဆောင်ရန်အတွက် Git microservice)။
  ii) ဌာနခွဲအား developer (Bitbucket microservice) မှ အပြောင်းအလဲများမှ ပိတ်ဆို့ထားသည်။
  iii) ဤဌာနခွဲ (Bitbucket microservice) အတွက် Pull Request တစ်ခု ဖန်တီးထားသည်။
  iv) Pull Request အသစ်တစ်ခုအကြောင်း မက်ဆေ့ဂျ်တစ်စောင်ကို developer chats သို့ ပေးပို့သည် (အကြောင်းကြားချက်များနှင့်အတူ လုပ်ဆောင်ရန်အတွက် microservice ကို အသိပေးပါ)။
  v) တည်ဆောက်ခြင်း၊ စမ်းသပ်ခြင်းနှင့် အသုံးချခြင်း လုပ်ငန်းများကို DEV (Jenkins နှင့် လုပ်ဆောင်ရန်အတွက် Jenkins မိုက်ခရိုဝန်ဆောင်မှု) တွင် စတင်ဆောင်ရွက်ပါသည်။
  vi) ယခင်အဆင့်များအားလုံးကို အောင်မြင်စွာပြီးမြောက်ပါက၊ Integro သည် ၎င်း၏ Approve ကို Pull Request (Bitbucket microservice) တွင် ထည့်သွင်းသည်။

• Integro သည် သတ်မှတ်ထားသော သုံးသပ်သူများထံမှ Pull Request တွင် အတည်ပြုရန် စောင့်နေသည်။
• လိုအပ်သောခွင့်ပြုချက်အားလုံးကို လက်ခံရရှိပြီးသည်နှင့် (အလိုအလျောက်စမ်းသပ်မှုများအပါအဝင် အပြုသဘောဆောင်သောအောင်မြင်မှု) ကိုရရှိသည်နှင့်တပြိုင်နက် Integro သည် အလုပ်အား Dev (Jira microservice) တွင် စမ်းသပ်မှုအခြေအနေသို့ လွှဲပြောင်းပေးပါသည်။

6. Testers များသည် လုပ်ငန်းတာဝန်ကို စမ်းသပ်သည်။ ပြဿနာမရှိပါက၊ အလုပ်အား Ready For Build အဆင့်သို့ လွှဲပြောင်းမည်ဖြစ်သည်။

7. Integro "မြင်သည်" သည် လုပ်ငန်းသည် ထုတ်ဝေရန် အဆင်သင့်ဖြစ်ပြီး Canary မုဒ် (Jenkins microservice) တွင် ၎င်း၏ဖြန့်ကျက်မှုကို စတင်သည်။ လွှတ်ပေးရန် အဆင်သင့်ကို စည်းမျဉ်း အစုံဖြင့် ဆုံးဖြတ်သည်။ ဥပမာအားဖြင့်၊ လုပ်ဆောင်စရာသည် လိုအပ်သောအခြေအနေတွင်ရှိပြီး၊ အခြားလုပ်ဆောင်စရာများတွင် လော့ခ်ချခြင်းမရှိပါ၊ လောလောဆယ်တွင် ဤမိုက်ခရိုဝန်ဆောင်မှု၏ အသက်ဝင်သော အပ်လုဒ်များ မရှိပါ။

8. အလုပ်အား Canary status (Jira microservice) သို့ လွှဲပြောင်းသည်။

9. Jenkins သည် Canary မုဒ်တွင် Nomad (ပုံမှန်အားဖြင့် 1-3 သာဓက) မှတဆင့် ဖြန့်ကျက်ခြင်းလုပ်ငန်းကို စတင်လိုက်ပြီး ဖြန့်ကျက်မှုနှင့်ပတ်သက်၍ ထုတ်ပြန်မှုစောင့်ကြည့်ရေးဝန်ဆောင်မှု (DeployWatch microservice) ကို အသိပေးသည်။

10. DeployWatch microservice သည် အမှားအယွင်းနောက်ခံကို စုဆောင်းပြီး လိုအပ်ပါက ၎င်းကိုတုံ့ပြန်သည်။ အမှားအယွင်း နောက်ခံကို ကျော်လွန်နေပါက (နောက်ခံစံနှုန်းကို အလိုအလျောက် တွက်ချက်သည်)၊ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများကို Notify microservice မှတစ်ဆင့် အကြောင်းကြားမည်ဖြစ်သည်။ 5 မိနစ်အကြာတွင် ဆော့ဖ်ဝဲရေးသားသူက တုံ့ပြန်ခြင်းမရှိပါက (ပြန်ပြောင်းရန် သို့မဟုတ် ဆက်နေမည်ကို နှိပ်ပါ)၊ ထို့နောက် ကိန္နရီဖြစ်ရပ်များကို အလိုအလျောက် ပြန်လှည့်လာမည်ဖြစ်သည်။ နောက်ခံကို မကျော်လွန်ပါက၊ ဆော့ဖ်ဝဲရေးသားသူသည် အလုပ်ဖြန့်ကျက်မှုကို ထုတ်လုပ်မှုသို့ ကိုယ်တိုင်စတင်ရပါမည် (UI ရှိ ခလုတ်တစ်ခုကို နှိပ်ခြင်းဖြင့်)။ မိနစ် 60 အတွင်း developer သည် ထုတ်လုပ်မှုသို့ ဖြန့်ကျက်မှုကို မလုပ်ဆောင်ပါက၊ လုံခြုံရေးအကြောင်းပြချက်များကြောင့် Canary instances များကိုလည်း ပြန်လည်အသုံးပြုနိုင်မည်ဖြစ်သည်။

11. ထုတ်လုပ်မှုကို စတင်ပြီးနောက်၊

• လုပ်ငန်းကို ထုတ်လုပ်မှုအခြေအနေ (Jira microservice) သို့ လွှဲပြောင်းထားသည်။
• Jenkins microservice သည် ဖြန့်ကျက်မှုလုပ်ငန်းစဉ်ကို စတင်ပြီး DeployWatch microservice အား ဖြန့်ကျက်မှုအကြောင်း အသိပေးသည်။
• DeployWatch microservice သည် ထုတ်လုပ်ရေးရှိ ကွန်တိန်နာများအားလုံးကို အပ်ဒိတ်လုပ်ပြီးကြောင်း စစ်ဆေးသည် (အားလုံးကို မွမ်းမံထားသည့်အခါ ဖြစ်ရပ်များရှိခဲ့သည်)။
• Notify microservice မှတဆင့်၊ ဖြန့်ကျက်မှု၏ရလဒ်များအကြောင်း အသိပေးချက်ကို ထုတ်လုပ်ရေးသို့ ပေးပို့သည်။

12. Developer များသည် မမှန်ကန်သော microservice အပြုအမူကို တွေ့ရှိပါက Production မှ လုပ်ဆောင်စရာတစ်ခုကို ပြန်လည်စတင်ရန် မိနစ် 30 ကြာမြင့်မည်ဖြစ်ပါသည်။ ဤအချိန်ပြီးနောက်၊ လုပ်ဆောင်စရာကို မာစတာ (Git microservice) အဖြစ် အလိုအလျောက် ပေါင်းစပ်သွားပါမည်။

13. အောင်မြင်သော မာစတာအဖြစ် ပေါင်းစည်းပြီးနောက်၊ လုပ်ဆောင်စရာ အခြေအနေအား Closed (Jira microservice) သို့ ပြောင်းလဲသွားပါမည်။

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

နောက်တစ်ခုကဘာလဲ

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

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

source: www.habr.com