DevOps ဆိုတာ ဘယ်သူလဲ၊ ဘယ်အချိန်ကမှ မလိုအပ်ပါဘူး။

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

အချို့က ဝေါဟာရ၏အနှစ်သာရကို အမြဲမသိနားမလည်ကြသော်လည်း ၎င်းတို့၏ကိုယ်ရေးရာဇဝင်တွင် DevOps ညွှန်ပြသည်။ Ansible၊ GitLab၊ Jenkins၊ Terraform နှင့် အခြားအရာများကို လေ့လာပြီး (စာရင်းကို သင့်အရသာအတိုင်း ဆက်လက်လုပ်ဆောင်နိုင်သည်) သူသည် ချက်ချင်းဆိုသလို "devops" ဖြစ်လာလိမ့်မည်ဟု တစ်စုံတစ်ယောက်က ထင်မြင်ယူဆသည်။ ဤသည်မှာ မမှန်ပါ။

လွန်ခဲ့သည့်နှစ်အနည်းငယ်အတွင်း၊ ကုမ္ပဏီအမျိုးမျိုးရှိ DevOps အကောင်အထည်ဖော်မှုတွင် အဓိကပါဝင်ခဲ့သည်။ ယင်းမတိုင်မီက စနစ်စီမံခန့်ခွဲသူမှ အိုင်တီဒါရိုက်တာအထိ အနှစ် ၂၀ ကျော် တာဝန်ထမ်းဆောင်ခဲ့သည်။ လောလောဆယ် Playgendary တွင် DevOps ဦးစီးအင်ဂျင်နီယာ။

DevOps ဆိုတာ ဘယ်သူလဲ။

ဆောင်းပါးတစ်ပုဒ်ရေးဖို့ စိတ်ကူးက “DevOps ဆိုတာ ဘယ်သူလဲ” ဆိုတဲ့ မေးခွန်းတစ်ခု ထွက်ပေါ်လာတယ်။ ဘယ်သူဘယ်ဝါဆိုတာ အတိအကျ အတိအကျ မပြောသေးဘူး။ အဖြေအချို့က ဒီထဲမှာ ရှိပြီးသားပါ။ видео. ပထမဦးစွာ ဤအရာများမှ အဓိကအကြောင်းအရာများကို မီးမောင်းထိုးပြမည်ဖြစ်ပြီး၊ ထို့နောက် ကျွန်ုပ်၏ လေ့လာတွေ့ရှိချက်များနှင့် အတွေးအမြင်များကို မျှဝေပါမည်။

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

DevOps သည် ဒဿနိကဗေဒနှင့် နည်းစနစ်တစ်ခုဖြစ်သည်။

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

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

DevOps ပန်းတိုင်များကို အချက်သုံးချက်ဖြင့် အကျဉ်းချုံးနိုင်သည်။

• ဆော့ဖ်ဝဲကို ပုံမှန်မွမ်းမံရပါမည်။
• Software မြန်မြန်လုပ်ရမယ်။
• ဆော့ဖ်ဝဲလ်ကို အချိန်တိုအတွင်း အဆင်ပြေပြေ အသုံးချသင့်သည်။

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

၎င်းသည် DevOps ကိရိယာများ၏ တစ်စိတ်တစ်ပိုင်းမျှသာဖြစ်သည်။

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

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

အဓိက ဥပမာတစ်ခုရှိခဲ့သည်။ လူငယ်တစ်ဦးသည် သူ၏ကိုယ်ရေးရာဇဝင်တွင် ကျယ်ပြောလှသော စကားများစွာဖြင့် အင်တာဗျူးသို့ ရောက်လာသည်။ နောက်ဆုံး သုံးနေရာ မှာ လုပ်သက် 5-6 လ ရှိတယ်။ သူတို့ "မဆင်းဘူး" ဖြစ်သောကြောင့် လုပ်ငန်းနှစ်ခုမှ ထွက်ခွာခဲ့သည်။ ဒါပေမယ့် တတိယကုမ္ပဏီအကြောင်း၊ သူက သူ့ကို အဲဒီမှာ ဘယ်သူမှ နားမလည်ဘူးလို့ ပြောပါတယ်- developer တွေက Windows အတွက် code တွေရေးပြီး ဒါရိုက်တာက ဒီကုဒ်ကို ပုံမှန် Docker မှာ “ခြုံ” ပြီး CI/CD ပိုက်လိုင်းထဲကို မြှုပ်နှံထားပါတယ်။ ကောင်လေးက သူ့လက်ရှိအလုပ်နဲ့ သူ့လုပ်ဖော်ကိုင်ဖက်တွေနဲ့ ပတ်သက်ပြီး အပျက်သဘောဆောင်တဲ့ စကားတွေအများကြီးပြောခဲ့တယ် - "ဒါဆို မင်းဆင်တစ်ကောင်ကို မရောင်းရဘူး" လို့ ဖြေချင်ပါတယ်။

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

DevOps သည် သင့်အတွက် ပုဂ္ဂိုလ်ရေးအရ ဘာကိုဆိုလိုသနည်း။
- ယေဘူယျအားဖြင့်၊ သို့မဟုတ် ကျွန်ုပ်က ၎င်းကို မည်သို့မြင်နိုင်မည်နည်း။

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

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

DevOps နည်းစနစ်နှင့် ဒဿနိကဗေဒ

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

DevOps နည်းစနစ်သည် သင့်ပန်းတိုင်များကို အောင်မြင်ရန် နည်းလမ်းတစ်ခုမျှသာဖြစ်သည်။

ယခု DevOps ၏ဒဿနကဘာလဲ။ ပြီးတော့ ဒါက အခက်ခဲဆုံးမေးခွန်းဖြစ်နိုင်ပါတယ်။

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

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

ကျွန်ုပ်၏ကိုယ်ပိုင်အတွေ့အကြုံကိုအခြေခံ၍ ဤဒဿနိကဗေဒ၏ "စံနှုန်းများ" အချို့ကို တရားဝင်ဖြစ်အောင်ကြိုးစားခဲ့သည်။ အောက်ပါအတိုင်း ထွက်ပေါ်လာခဲ့သည်-

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

ကျွန်ုပ်၏ "postulates" သည် ဆွေးနွေးရန် သီးခြားခေါင်းစဉ်တစ်ခုဖြစ်သည်ဟု ကျွန်ုပ်ထင်သည်။ ဒါပေမယ့် အခု တည်ဆောက်ဖို့ တစ်ခုခုတော့ ရှိတယ်။

DevOps ဘာလုပ်သလဲ။

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

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

ရုရှားတွင် DevOps သည် အလွန်ငယ်သေးသော်လည်း ခေတ်စားနေသော အကြောင်းအရာတစ်ခု ဖြစ်နေပါပြီ။ ငါသိသလောက်၊ မော်စကိုတစ်ခုတည်းတွင်၊ 2019 ခုနှစ်တွင်ထိုကဲ့သို့သောကျွမ်းကျင်သူများပြတ်လပ်မှုပမာဏသည်လူ 1000 ကျော်ရှိသည်။ အလုပ်ရှင်များအတွက် Kubernetes ဟူသောစကားလုံးသည် နွားတစ်ကောင်အတွက် အနီရောင်အ၀တ်စုတ်နှင့်တူသည်။ ဤကိရိယာ၏ ဆက်စပ်သူများသည် မလိုအပ်ဘဲ စီးပွားရေးအရ အကျိုးအမြတ်မရှိသည့်တိုင် ၎င်းကို အသုံးပြုရန် အဆင်သင့်ဖြစ်နေပြီဖြစ်သည်။ မည်သည့်ကိစ္စများတွင် အသုံးပြုရန် ပိုသင့်လျော်သည်ကို အလုပ်ရှင်က အမြဲတမ်းနားမလည်ဘဲ၊ သင့်လျော်စွာ အသုံးချခြင်းဖြင့် Kubernetes အစုအဝေးကို ထိန်းသိမ်းခြင်းသည် သမားရိုးကျ အစုအဝေးအစီအစဉ်ကို အသုံးပြု၍ အက်ပ်တစ်ခုအား အသုံးချခြင်းထက် 2-3 ဆ ပိုမိုကုန်ကျပါသည်။ တကယ်လိုအပ်တဲ့နေရာမှာ သုံးပါ။

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

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

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

ဆော့ဖ်ဝဲရေးသားသူသည် ကုဒ်နှင့် စမ်းသပ်မှုများကိုသာ ရေးသားသင့်သည်။ ၎င်းကိုလုပ်ဆောင်ရန်၊ ပြည်တွင်း၌ ပရောဂျက်၏ အခြေခံအဆောက်အအုံတစ်ခုလုံးကို ဖြန့်ကျက်ထိန်းသိမ်းပေးမည့် စူပါအစွမ်းထက် လက်ပ်တော့တစ်လုံး မလိုအပ်ပါ။ ဥပမာအားဖြင့်၊ front-ender သည် database၊ S3 (minio) emulator အပါအဝင် ၎င်း၏ laptop တွင် application ၏ element အားလုံးကို သိမ်းဆည်းထားသည်။ ဆိုလိုသည်မှာ၊ သူသည် ဤဒေသခံ အခြေခံအဆောက်အအုံကို ထိန်းသိမ်းရန် အချိန်များစွာ သုံးစွဲပြီး ထိုကဲ့သို့သော ဖြေရှင်းချက်၏ ပြဿနာအားလုံးကို လက်တစ်ကမ်းတည်းဖြင့် ရုန်းကန်နေရသည်။ ရှေ့ကုဒ်ကို တီထွင်မယ့်အစား။ ထိုသို့သောသူများသည် မည်သည့်အပြောင်းအလဲကိုမဆို ပြင်းပြင်းထန်ထန် တွန်းလှန်နိုင်သည်။

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

DevOps မလိုအပ်သည့်အခါ

DevOps မလိုအပ်သည့်အခါ အခြေအနေများရှိပါသည်။ ဤသည်မှာ အမှန်ဖြစ်သည်- ၎င်းကို နားလည်လက်ခံရပါမည်။

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

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

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

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

• DevOops
• DevOpsConf
• HighLoad++
• ဖယောင်းတိုင်
• MailRu Cloud ဖြေရှင်းချက်

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

အကယ်၍ သင့်ကုမ္ပဏီသည် ဆိုင်ငယ်တစ်ခုတွင် ငါးရောင်းပြီး တစ်ခုတည်းသော IT ထုတ်ကုန်သည် 1C ဖွဲ့စည်းမှုပုံစံ နှစ်ခုဖြစ်သည်- လုပ်ငန်း (စာရင်းကိုင်နှင့် UNF) ဆိုလျှင် DevOps အကြောင်းကို ပြောဆိုရန် အဓိပ္ပါယ်မရှိပေ။

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

နှစ်စဉ်ဘဏ္ဍာရေးအလှည့်အပြောင်း၏ အရွယ်အစားနှင့် ပမာဏသည် သင့်ကုမ္ပဏီ DevOps လိုအပ်မှုရှိမရှိ ဆုံးဖြတ်ရန် အဓိကစံသတ်မှတ်ချက်မဟုတ်ပေ။

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

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

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

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

DevOps လိုအပ်မှု ရှိမရှိ နားလည်ရန် အဓိက စံသတ်မှတ်ချက်- သင်၏ IT ထုတ်ကုန်များသည် ကုမ္ပဏီနှင့် ဖောက်သည်များအတွက် မည်မျှတန်ဖိုးရှိသည်။

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

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

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

ယခု ကျွန်ုပ်တို့သည် Jenkins အား Unity ဖြင့် စည်းလုံးညီညွှတ်သော ပိုက်လိုင်းများအားလုံးကို လုပ်ဆောင်ရန်နှင့် App Store နှင့် Play Market သို့ ဖြန့်ကျက်ခြင်းအတွက် CI/CD ပိုက်လိုင်းများတူးလ်အဖြစ် တက်ကြွစွာအသုံးပြုနေပါသည်။ ဂန္တဝင်ကိရိယာအစုံမှ နောက်ထပ်အကြောင်းအရာများ

• Asana - ပရောဂျက်စီမံခန့်ခွဲမှုအတွက်။ Jenkins နှင့် ပေါင်းစည်းမှုကို သတ်မှတ်ပါ။
• Google Meet - ဗီဒီယိုအစည်းအဝေးများအတွက်။
• Slack - Jenkins မှ အသိပေးချက်များ အပါအဝင် ဆက်သွယ်ရေးနှင့် အမျိုးမျိုးသော အသိပေးချက်များအတွက်။
• Atlassian မြစ်ဆုံ - စာတမ်းပြုစုခြင်းနှင့် အဖွဲ့လိုက်လုပ်ဆောင်ခြင်းအတွက်။

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

အဲဒီအစားတစ်ဦးနိဂုံးပိုင်း၏

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

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

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

source: www.habr.com