DevOps LEGO- ကျွန်ုပ်တို့သည် ပိုက်လိုင်းကို တုံးများအဖြစ် ပုံဖော်နည်း

တစ်ချိန်က ကျွန်ုပ်တို့သည် စက်ရုံတစ်ခုတွင် ဖောက်သည်တစ်ဦးအား အီလက်ထရွန်းနစ်စာရွက်စာတမ်းစီမံခန့်ခွဲမှုစနစ်တစ်ခုကို ပံ့ပိုးပေးခဲ့သည်။ ပြီးမှ အခြားအရာတစ်ခုဆီသို့။ နောက်တစ်ခု။ စတုတ္ထနေ့နှင့် ပဉ္စမနေ့။ သယ်သွားတော့ ဖြန့်ဝေထားတဲ့ ပစ္စည်း ၁၀ ခုကို ရောက်သွားတယ်။ အထူးသဖြင့် အပြောင်းအလဲတွေကို ပေးဆောင်ရတဲ့အခါ အားကောင်းလာပါတယ်။ ထုတ်လုပ်မှုပတ်လမ်းသို့ ပို့ဆောင်မှု၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့်၊ စမ်းသပ်မှုစနစ်၏ အဖြစ်အပျက် ၅ ခုသည် နောက်ဆုံးတွင် ၁၀ နာရီနှင့် ဝန်ထမ်း ၆-၇ ဦး လိုအပ်သည်။ ထိုသို့သော ကုန်ကျစရိတ်များသည် ကျွန်ုပ်တို့ကို တတ်နိုင်သမျှ ရှားပါးသလောက် ပို့ဆောင်ခိုင်းစေခဲ့သည်။ သုံးနှစ်ကြာ လည်ပတ်ပြီးနောက်၊ ကျွန်ုပ်တို့ သည်းမခံနိုင်တော့ဘဲ DevOps ကို နည်းနည်းလေးဖြင့် ပရောဂျက်ကို အမွှေးအကြိုင်လုပ်ရန် ဆုံးဖြတ်ခဲ့သည်။

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

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

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

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

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

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

DevOps တည်ဆောက်သူ ဖန်တီးခြင်း။

Agile တွင် ၎င်း၏ကိုယ်ပိုင်ဖော်ပြချက်ရှိသည်။ ITIL တွင်၎င်း၏ကိုယ်ပိုင်နည်းစနစ်ရှိသည်။ DevOps သည် ကံနည်းသည် - ၎င်းသည် နမူနာများနှင့် စံနှုန်းများကို မရယူရသေးပါ။ သို့ပေမယ့် အချို့သော ကြိုးစားနေကြသည်။ ၎င်းတို့၏ ဖွံ့ဖြိုးတိုးတက်မှုနှင့် လုပ်ငန်းလည်ပတ်မှုဆိုင်ရာ အလေ့အကျင့်များကို အကဲဖြတ်ခြင်းအပေါ် အခြေခံ၍ ကုမ္ပဏီများ၏ ရင့်ကျက်မှုကို ဆုံးဖြတ်ပါ။

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

အဲဒါကို ငါတို့က ငါတို့အတွက် အခြေခံအဖြစ် ယူတယ်။ ဒီဇိုင်နာ. နယ်ပယ်လေးခုတွင် တစ်ခုစီတွင် ကိရိယာအစုံပါရှိသည် - ၎င်းတို့ကို ဒေတာဘေ့စ်တစ်ခုအဖြစ် စုဆောင်းကာ လူကြိုက်အများဆုံးများကို ဖော်ထုတ်ခြင်း၊ ပေါင်းစည်းမှုဆိုင်ရာ အချက်များနှင့် သင့်လျော်သော ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း ယန္တရားများကို ဖော်ထုတ်ခဲ့သည်။ စုစုပေါင်း ထွက်လာတယ်။ အလေ့အကျင့် ၃၆ ခုနှင့် ကိရိယာ ၁၁၅ ခုလေးပုံတစ်ပုံသည် open source သို့မဟုတ် အခမဲ့ဆော့ဖ်ဝဲများဖြစ်သည်။ ထို့နောက်၊ ကျွန်ုပ်တို့သည် နယ်ပယ်တစ်ခုစီတွင် ကျွန်ုပ်တို့အောင်မြင်မှုရရှိခဲ့သည်များကို ဆွေးနွေးမည်ဖြစ်ပြီး ဥပမာအနေဖြင့် ကျွန်ုပ်တို့သည် ပို့စ်ကိုစတင်ခဲ့သည့် နည်းပညာဆိုင်ရာစာရွက်စာတမ်းစီမံခန့်ခွဲမှုကိုဖန်တီးရန် ပရောဂျက်တွင် ၎င်းကို အကောင်အထည်ဖော်ပုံအကြောင်း ဆွေးနွေးပါမည်။

လုပ်ငန်းစဉ်များ

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

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

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

ယဉျကြေးမှု

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

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

တူညီသောအဖွဲ့အတွင်း၊ ကျွမ်းကျင်သူများသည် အချင်းချင်းကူညီရန် ဆုံးဖြတ်ကြသည်။ အရင်အတိုင်းပဲလား? ဥပမာအားဖြင့်၊ စာမျက်နှာ ၅၀ ခန့်ရှည်သော ထူထဲသောနေရာချထားရေးဆိုင်ရာ ညွှန်ကြားချက်အချို့ကို ပြင်ဆင်နေပါသည်။ အင်ဂျင်နီယာသည် ၎င်းကိုဖတ်ကာ တစ်ခုခုကို နားမလည်ပါက ကျိန်ဆဲပြီး မှတ်ချက်ပေးရန် ဆော့ဖ်ဝဲကို နံနက်သုံးနာရီတွင် တောင်းဆိုခဲ့သည်။ ပြုစုသူသည် မှတ်ချက်ပေးကာ ကျိန်ဆဲခဲ့သည်- နောက်ဆုံးတွင် မည်သူမျှ မပျော်ရွှင်ခဲ့ပါ။ ထို့အပြင်၊ ညွှန်ကြားချက်ပါအရာအားလုံးကို သင်မမှတ်မိနိုင်သောကြောင့် အမှားအယွင်းအချို့ရှိခဲ့သည်။ ယခုလည်း developer နှင့်အတူ အင်ဂျင်နီယာသည် အပလီကေးရှင်းဆော့ဖ်ဝဲလ်အခြေခံအဆောက်အအုံ၏ အလိုအလျောက် ဖြန့်ကျက်မှုအတွက် script တစ်ခုကို ရေးသားနေပါသည်။ သူတို့သည် တူညီသော ဘာသာစကားဖြင့် လက်တွေ့ကျကျ ပြောဆိုကြသည်။

လူထု

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

နည်းပညာ

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

Code ကိုအဖြစ်အခြေခံအဆောက်အအုံ

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

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

အခြေခံအဆောက်အဦ script များနှင့် ပိုက်လိုင်းများအပြင်၊ Documentation as a Code နည်းလမ်းကို မှတ်တမ်းပြုစုရန်အတွက်လည်း အသုံးပြုပါသည်။ ယင်းကြောင့် လူသစ်များကို ပရောဂျက်သို့ ချိတ်ဆက်ရန်၊ ဥပမာ၊ စမ်းသပ်မှု အစီအစဉ်တွင် ဖော်ပြထားသည့် လုပ်ဆောင်ချက်များအပေါ် အခြေခံ၍ ၎င်းတို့အား စနစ်သို့ မိတ်ဆက်ရန်နှင့် စမ်းသပ်မှုကိစ္စများတွင် ပြန်လည်အသုံးပြုရန် လွယ်ကူသည်။

စဉ်ဆက်မပြတ် ပေးပို့ခြင်းနှင့် စောင့်ကြည့်ခြင်း။

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

အင်္ဂလိပ်ဘာသာတွင် Continuous Delivery နှင့် Continuous Deployment ဟူ၍ အယူအဆအမျိုးမျိုးရှိသည်။ နှစ်ခုလုံးကို "စဉ်ဆက်မပြတ် ပေးပို့ခြင်း" ဟု ဘာသာပြန်ဆိုနိုင်သော်လည်း အမှန်တကယ်တွင် ၎င်းတို့ကြားတွင် အနည်းငယ်ကွာခြားမှုရှိပါသည်။ ဖြန့်ဝေထားသော စွမ်းအင်ကုမ္ပဏီတစ်ခု၏ နည်းပညာဆိုင်ရာစာရွက်စာတမ်းစီးဆင်းမှုအတွက် ကျွန်ုပ်တို့၏ပရောဂျက်တွင်၊ ထုတ်လုပ်မှုအတွက် တပ်ဆင်မှုကို အမိန့်ပေးသည့်အခါတွင် ပို့ဆောင်ခြင်းကို အသုံးပြုပါသည်။ Deployment တွင်၊ တပ်ဆင်မှုသည် အလိုအလျောက် ဖြစ်ပေါ်ပါသည်။ စဉ်ဆက်မပြတ် ပေးပို့ခြင်းအတွက် ဤပရောဂျက်သည် ယေဘုယျအားဖြင့် ဖြစ်လာသည်။ DevOps ၏ဗဟို.

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

ဘယ်သူက ငါတို့လိုမှာလဲ။ DevOps ဒီဇိုင်နာ?

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

ဒီဇိုင်နာ၏ ဖော်မတ်သည် တည်ဆောက်မှုလုပ်ငန်းစဉ်များနှင့် အလိုအလျောက်စနစ်တွင် ကုမ္ပဏီ၏ လက်ရှိဖြစ်ပေါ်တိုးတက်မှုများကို ထည့်သွင်းစဉ်းစားနိုင်စေပါသည်။ ရှိပြီးသား လုပ်ငန်းစဉ်များနှင့် ကောင်းမွန်စွာ ပေါင်းစပ်နိုင်ပြီး ကွက်လပ်များကို ရိုးရှင်းစွာ ဖြည့်ဆည်းပေးနိုင်မှသာ အရာအားလုံးကို ဖြိုဖျက်ပြီး ပြန်လည်တည်ဆောက်ရန် မလိုအပ်ပါ။

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

source: www.habr.com