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

ကျွန်ုပ်တို့သည် True Engineering မှ သုံးစွဲသူဆာဗာများသို့ အပ်ဒိတ်များ စဉ်ဆက်မပြတ် ပေးပို့ခြင်းအတွက် လုပ်ငန်းစဉ်ကို ချမှတ်ထားပြီး ဤအတွေ့အကြုံကို မျှဝေလိုပါသည်။

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

ဤဆောင်းပါးတွင် Continuous Deployment (CD) လုပ်ငန်းစဉ်၏ အဆင့်များအားလုံး သို့မဟုတ် ဖောက်သည်၏ platform သို့ အပ်ဒိတ်များပေးပို့ခြင်းအကြောင်း ဆွေးနွေးပါမည်။

1. ဤလုပ်ငန်းစဉ်သည် မည်သို့စတင်သနည်း။
2. ဖောက်သည်၏ Git repository နှင့် ထပ်တူပြုခြင်း၊
3. backend နှင့် frontend များ စုဝေးမှု၊
4. စမ်းသပ်မှုပတ်ဝန်းကျင်တွင် အလိုအလျောက် အသုံးချပလီကေးရှင်း ဖြန့်ကျက်ခြင်း၊
5. Prod သို့ အလိုအလျောက် ဖြန့်ကျက်မှု။

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

1. CD ကိုစတင်ပါ။

စဉ်ဆက်မပြတ် ဖြန့်ကျက်ခြင်းသည် ကျွန်ုပ်တို့၏ Git repository ၏ ထွက်ရှိမှုဌာနခွဲသို့ developer မှ အပြောင်းအလဲများကို တွန်းအားပေးခြင်းဖြင့် စတင်ပါသည်။

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

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

• ဖွံ့ဖြိုးတိုးတက်မှုလွယ်ကူခြင်း - အပလီကေးရှင်းသည်တက်ကြွစွာဖွံ့ဖြိုးနေသောကြောင့်၊ သင်သည်ကုဒ်အားလုံးကိုတစ်ပြိုင်နက်တည်းလုပ်ဆောင်နိုင်သည်။
• စနစ်တစ်ခုအနေဖြင့် အပလီကေးရှင်းသည် စမ်းသပ်မှုများအားလုံးကို ကျော်ဖြတ်ပြီး ဖောက်သည်၏ထုတ်လုပ်မှုပတ်ဝန်းကျင်သို့ ပို့ဆောင်ကြောင်းအာမခံသည့် CI/CD ပိုက်လိုင်းတစ်ခု။
• ကျွန်ုပ်တို့သည် ဗားရှင်းများတွင် ရှုပ်ထွေးမှုများကို ဖယ်ရှားပေးသည် - ကျွန်ုပ်တို့သည် Microservice ဗားရှင်းများ၏ မြေပုံကို သိမ်းဆည်းပြီး Helm scripts များတွင် microservice တစ်ခုစီအတွက် ၎င်း၏ဖွဲ့စည်းပုံကို ဖော်ပြရန် မလိုအပ်ပါ။

2. ဖောက်သည်၏အရင်းအမြစ်ကုဒ်၏ Git repository နှင့် ထပ်တူပြုခြင်း။

ပြုလုပ်ထားသော အပြောင်းအလဲများသည် ဖောက်သည်၏ Git repository နှင့် အလိုအလျောက် ထပ်တူပြုပါသည်။ အဆိုပါဌာနခွဲကိုမွမ်းမံပြီးနောက်စတင်လုပ်ဆောင်ပြီးဆက်လက်လုပ်ဆောင်ရန်အသုံးချမှုအားဆက်လက်လုပ်ဆောင်သည့် application assembly ကိုဤနေရာတွင်စီစဉ်ထားသည်။ လုပ်ငန်းစဉ်နှစ်ခုစလုံးသည် Git repository မှ ၎င်းတို့၏ ပတ်ဝန်းကျင်တွင် ပေါက်ဖွားသည်။

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

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

3. နောက်တန်းနှင့် ရှေ့တန်းကို စုစည်းခြင်း။

backend နှင့် frontend ကိုတည်ဆောက်ခြင်းသည် GitLab Runner စနစ်တွင်လုပ်ဆောင်သည့်အပြိုင်အလုပ်နှစ်ခုဖြစ်သည်။ ၎င်း၏မူရင်း စုဝေးဖွဲ့စည်းမှုပုံစံသည် တူညီသောသိုလှောင်ခန်းတွင် တည်ရှိသည်။

GitLab တွင်တည်ဆောက်ရန်အတွက် YAML script ကိုရေးသားခြင်းအတွက်ကျူတိုရီရယ်.

GitLab Runner သည် လိုအပ်သော repository မှ ကုဒ်ကိုယူပြီး Java application build command ဖြင့် စုစည်းပြီး Docker registry သို့ ပေးပို့သည်။ ဤနေရာတွင် ကျွန်ုပ်တို့သည် backend နှင့် frontend တို့ကို စုစည်းပြီး ဖောက်သည်၏ဘက်ခြမ်းရှိ repository တစ်ခုတွင် ထည့်ထားသော Docker ပုံများကို ရယူလိုက်ပါ။ Docker ပုံများကို စီမံခန့်ခွဲရန် ကျွန်ုပ်တို့အသုံးပြုသည်။ Gradle ပလပ်အင်.

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

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

2. Helm မှတစ်ဆင့် အပလီကေးရှင်းတစ်ခုကို အပ်ဒိတ်လုပ်ရန်၊ သင်သည် ၎င်း၏ဗားရှင်းကို သတ်မှတ်ရပါမည်။ ကျွန်ုပ်တို့သည် backend၊ frontend ကိုတည်ဆောက်ပြီး အပလီကေးရှင်းကို အပ်ဒိတ်လုပ်သည် - ဤအရာများသည် မတူညီသောအလုပ်သုံးခုဖြစ်သောကြောင့် နေရာတိုင်းတွင် application ၏တူညီသောဗားရှင်းကိုအသုံးပြုရန်အရေးကြီးပါသည်။ ကျွန်ုပ်တို့၏ K8S အစုအဝေးဖွဲ့စည်းပုံနှင့် အပလီကေးရှင်းများသည် တူညီသော Git သိုလှောင်မှုတွင် ရှိနေသောကြောင့် ဤလုပ်ဆောင်စရာအတွက်၊ ကျွန်ုပ်တို့သည် Git မှတ်တမ်းမှ ဒေတာကို အသုံးပြုပါသည်။

ကျွန်ုပ်တို့သည် command execution ရလဒ်များမှ အပလီကေးရှင်းဗားရှင်းကို ရရှိပါသည်။
git describe --tags --abbrev=7.

4. စမ်းသပ်ပတ်ဝန်းကျင် (UAT) သို့ ပြောင်းလဲမှုများအားလုံးကို အလိုအလျောက် ဖြန့်ကျက်ခြင်း

ဤတည်ဆောက်မှု script ၏နောက်ထပ်အဆင့်မှာ K8S အစုအဝေးကို အလိုအလျောက် အပ်ဒိတ်လုပ်ရန်ဖြစ်သည်။ အပလီကေးရှင်းတစ်ခုလုံးကို တည်ဆောက်ပြီး ပစ္စည်းများအားလုံးကို Docker Registry သို့ လွှင့်တင်ထားခြင်းကြောင့် ဖြစ်ပေါ်ပါသည်။ ၎င်းပြီးနောက်၊ စမ်းသပ်ပတ်ဝန်းကျင် အပ်ဒိတ် စတင်သည်။

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

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

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

5. Prod သို့ ပြောင်းလဲမှုများအားလုံးကို အလိုအလျောက် ဖြန့်ကျက်ခြင်း။

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

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

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

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

အပလီကေးရှင်းဆက်တင်များသည် ပတ်ဝန်းကျင်ပြောင်းလဲမှုများကို အသုံးပြုသည်။ ၎င်းတို့၏တန်ဖိုးများကို Go templates များအသုံးပြု၍ ပုံစံပလိတ်ပြုလုပ်ထားသည့် K8S configmap ကို အသုံးပြု၍ ကွန်တိန်နာများတွင် သတ်မှတ်ထားသည်။ ဥပမာအားဖြင့်၊ ဒိုမိန်းအမည်အတွက် ပတ်၀န်းကျင်ပြောင်းလဲနိုင်သော ပြောင်းလဲသတ်မှတ်ခြင်းကို ဤကဲ့သို့လုပ်ဆောင်နိုင်သည်-

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.values.global.env - ဤကိန်းရှင်သည် ပတ်ဝန်းကျင် (ထုတ်ကုန်၊ အဆင့်၊ UAT) အမည်ကို သိမ်းဆည်းထားသည်။
.values.app.properties.app_external_domain - ဤကိန်းရှင်တွင် ကျွန်ုပ်တို့သည် .Values.yaml ဖိုင်တွင် လိုချင်သောဒိုမိန်းကို သတ်မှတ်သည်။

အပလီကေးရှင်းကို အပ်ဒိတ်လုပ်သောအခါ၊ Helm သည် ပုံစံပလိတ်များမှ configmap.yaml ဖိုင်ကို ဖန်တီးပြီး အပလီကေးရှင်းအပ်ဒိတ်စတင်သည့် ပတ်ဝန်းကျင်အပေါ် မူတည်၍ APP_EXTERNAL_DOMAIN တန်ဖိုးကို အလိုရှိသောတန်ဖိုးဖြင့် ဖြည့်ပေးသည်။ ဤကိန်းရှင်ကို ကွန်တိန်နာတွင် သတ်မှတ်ပြီးဖြစ်သည်။ ၎င်းကို အပလီကေးရှင်းမှ ဝင်ရောက်ကြည့်ရှုနိုင်သည်၊ ထို့ကြောင့် အပလီကေးရှင်းပတ်ဝန်းကျင်တစ်ခုစီသည် ဤကိန်းရှင်အတွက် မတူညီသောတန်ဖိုးတစ်ခုရှိမည်ဖြစ်သည်။

မကြာသေးမီက၊ K8S အထောက်အပံ့သည် configMaps နှင့်လုပ်ဆောင်ခြင်းအပါအဝင် Spring Cloud တွင်ပေါ်လာသည်- Spring Cloud Kubernetes. ပရောဂျက်သည် တက်ကြွစွာ ဖွံ့ဖြိုးတိုးတက်ပြီး ပြင်းထန်စွာ ပြောင်းလဲနေချိန်တွင်၊ ၎င်းကို ထုတ်လုပ်မှုတွင် ကျွန်ုပ်တို့ အသုံးမပြုနိုင်ပါ။ သို့သော် ကျွန်ုပ်တို့သည် ၎င်း၏အခြေအနေကို တက်ကြွစွာစောင့်ကြည့်ပြီး DEV ဖွဲ့စည်းမှုပုံစံများတွင် အသုံးပြုပါသည်။ ၎င်းသည် တည်ငြိမ်လာသည်နှင့်တပြိုင်နက်၊ ကျွန်ုပ်တို့သည် ပတ်ဝန်းကျင်ပြောင်းလဲမှုများကို အသုံးပြုခြင်းမှ ၎င်းသို့ ပြောင်းသွားပါမည်။

စုစုပေါင်း

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

အနာဂတ်အစီအစဉ်များ- အလိုအလျောက်ဒေတာဘေ့စ်ပြောင်းရွှေ့ခြင်း။

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

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

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

ကျွန်ုပ်တို့သည် K8S အလုပ်မှတစ်ဆင့် ဒေတာဘေ့စ်ပြောင်းရွှေ့ခြင်းကို အလိုအလျောက်လုပ်ဆောင်ပြီး ၎င်းကို CD လုပ်ငန်းစဉ်တွင် ပေါင်းစည်းရန် စီစဉ်ထားပါသည်။ ပြီးတော့ ဒီအတွေ့အကြုံကို Habré မှာ ကျိန်းသေ မျှဝေပါမယ်။

source: www.habr.com