موږ یوځل په یوه تاسیساتو کې پیرودونکي ته د بریښنایی سند مدیریت سیسټم چمتو کړ. او بیا بل څیز ته. او یو بل. او په څلورم، او په پنځمه. موږ دومره لیرې شو چې موږ 10 ویشل شوي شیانو ته ورسیدو. دا په ځواکمنه توګه وګرځید ... په ځانګړي توګه کله چې موږ بدلونونه وړاندې کړو. د تولید سرکټ ته د تحویلي برخې په توګه ، د ازموینې سیسټم 5 سناریوګانې په نهایت کې 10 ساعتونو او 6-7 کارمندانو ته اړتیا لري. دا ډول لګښتونو موږ دې ته اړ کړل چې د امکان تر حده په ندرت سره تحویلي وکړو. د دریو کلونو عملیاتو وروسته، موږ نشو کولی دا ودروو او پریکړه یې وکړه چې پروژه د DevOps سره مساله کړو.
اوس ټول ازموینه په 3 ساعتونو کې ترسره کیږي، او 3 خلک پدې کې برخه اخلي: یو انجنیر او دوه ټیسټران. پرمختګونه په واضح ډول په شمیرو کې څرګند شوي او د ډیر خوښ شوي TTM کمولو لامل کیږي. زموږ په تجربه کې، ډیری نور پیرودونکي شتون لري چې د هغو کسانو په پرتله چې حتی د دې په اړه پوهیږي د DevOps څخه ګټه پورته کولی شي. له همدې امله ، د DevOps خلکو ته نږدې کولو لپاره ، موږ یو ساده جوړونکی رامینځته کړی ، کوم چې موږ به پدې پوسټ کې په تفصیل سره خبرې وکړو.
اوس راځئ چې تاسو ته په تفصیل سره ووایم. د انرژۍ یو شرکت په 10 لوی تاسیساتو کې د تخنیکي اسنادو مدیریت سیسټم ځای په ځای کوي. د DevOps پرته د دې پیمانه پروژې نیویګیټ کول اسانه ندي ، ځکه چې د لاسي کار لویه برخه کار خورا ځنډوي او کیفیت هم کموي - ټول لاسي کار له غلطیو ډک دی. له بلې خوا، داسې پروژې شتون لري چیرې چې یوازې یو نصب شتون لري، مګر هرڅه باید په اوتومات ډول کار وکړي، په دوامداره توګه او پرته له ناکامۍ - د بیلګې په توګه، په لوی monolithic سازمانونو کې د ورته سند جریان سیسټمونه. که نه نو ، یو څوک به په لاسي ډول تنظیمات رامینځته کړي ، د پلي کولو لارښوونو په اړه هیر کړي - او د پایلې په توګه ، په تولید کې به تنظیمات له لاسه ورکړي او هرڅه به سقوط وکړي.
معمولا موږ د پیرودونکي سره د تړون له لارې کار کوو، او پدې حالت کې زموږ ګټې یو څه توپیر لري. پیرودونکي د بودیجې او تخنیکي مشخصاتو سره سم پروژې ته په کلکه ګوري. دا ستونزمن کیدی شي هغه ته د مختلف DevOps کړنو ګټې تشریح کړي چې په تخنیکي مشخصاتو کې شامل ندي. څه که چیرې هغه د اضافه سوداګرۍ ارزښت سره ګړندي خوشې کولو کې علاقه ولري ، یا د اتومات پایپ لاین په جوړولو کې؟
افسوس، کله چې د مخکې تصویب شوي لګښت سره کار کوي، دا دلچسپي تل نه موندل کیږي. زموږ په عمل کې، داسې قضیه وه کله چې موږ باید د یو بې رحمه او بې پرواه قراردادي پراختیا غوره کړو. دا ویره وه: هیڅ تازه سرچینې کوډونه شتون نلري ، د ورته سیسټم کوډ اساس په مختلف تاسیساتو کې توپیر درلود ، اسناد په جزوي ډول غیر حاضر و ، او یو څه د خراب کیفیت. البته، پیرودونکي د سرچینې کوډ، مجلس، ریلیزونو، او نورو باندې کنټرول نلري.
تر دې دمه ، هرڅوک د DevOps په اړه نه پوهیږي ، مګر هرڅومره ژر چې موږ د دې ګټو په اړه وغږیږو ، د اصلي سرچینو سپمولو په اړه ، د ټولو پیرودونکو سترګې روښانه کیږي. نو د غوښتنو شمیر چې پکې DevOps شامل دي د وخت په تیریدو سره ډیریږي. دلته، د دې لپاره چې په اسانۍ سره د پیرودونکو سره ورته ژبه خبرې وکړو، موږ اړتیا لرو چې ژر تر ژره د سوداګرۍ ستونزې او د DevOps کړنې سره وصل کړو چې د مناسب پراختیا پایپ لاین په جوړولو کې به مرسته وکړي.
نو ، موږ له یوې خوا د ستونزو سیټ لرو ، موږ له بلې خوا د DevOps پوهه ، کړنې او اوزار لرو. ولې تجربه له ټولو سره نه شریکوي؟
د DevOps جوړونکی رامینځته کول
هوښیار خپل منشور لري. ITIL خپل میتودولوژي لري. DevOps لږ بختور دی - دا لاهم ټیمپلیټونه او معیارونه ندي ترلاسه کړي. که څه هم د دوی د پراختیا او عملیاتي کړنو د ارزونې پراساس د شرکتونو بشپړتیا ټاکي.
له نېکه مرغه، په 2014 کې د ګارټینر مشهور شرکت او د DevOps کلیدي کړنې او د دوی ترمنځ اړیکې تحلیل کړي. د دې پر بنسټ، ما یو انفوګرافیک خپور کړ:
موږ دا زموږ د اساس په توګه واخیست . د څلورو برخو څخه هر یو د وسیلو سیټ لري - موږ دوی په ډیټابیس کې راټول کړل، خورا مشهور یې وپیژندل، د ادغام ټکي او د اصلاح کولو مناسب میکانیزمونه پیژندل. په مجموع کې دا معلومه شوه 36 تمرینونه او 115 وسیلې، چې څلورمه برخه یې خلاصې سرچینې یا وړیا سافټویر دي. بیا به موږ د هغه څه په اړه وغږیږو چې موږ په هره برخه کې ترلاسه کړي دي او د بیلګې په توګه، دا چې دا څنګه د تخنیکي اسنادو مدیریت رامینځته کولو په پروژه کې پلي شوي، چې موږ یې پوسټ پیل کړ.
پروسې
په بدنامه EDMS پروژه کې، د تخنیکي اسنادو مدیریت سیسټم د ورته سکیم سره سم په 10 شیانو کې ځای پرځای شوی و. په نصب کې 4 سرورونه شامل دي: ډیټابیس سرور، د غوښتنلیک سرور، د بشپړ متن لیست کول او د مینځپانګې مدیریت. په نصب کې، دوی په یو واحد نوډ کې کار کوي او په تاسیساتو کې د معلوماتو مرکز کې موقعیت لري. ټول شیان په زیربنا کې یو څه توپیر لري، مګر دا د نړیوال تعامل سره مداخله نه کوي.
لومړی، د DevOps کړنو سره سم، موږ په سیمه ایزه توګه زیربنا اتومات کړه، بیا موږ د ازموینې سرکټ ته رسولو، او بیا د پیرودونکي محصول ته راوړو. هره پروسه ګام په ګام ترسره شوه. د چاپیریال ترتیبات د سرچینې کوډ سیسټم کې تنظیم شوي، په پام کې نیولو سره چې د توزیع کټ د اتوماتیک تازه کولو لپاره ترتیب شوی. د تشکیلاتو د بدلونونو په صورت کې، انجینران په ساده ډول د نسخې کنټرول سیسټم کې مناسب بدلونونو ته اړتیا لري - او بیا اتوماتیک تازه کول به پرته له کومې ستونزې ترسره شي.
د دې طریقې څخه مننه، د ازموینې پروسه خورا ساده شوې. پخوا، پروژې ټیسټران درلودل چې په لاسي ډول د سټینډونو تازه کولو پرته بل څه نه کوي. اوس دوی یوازې راځي، وګورئ چې هرڅه کار کوي او نور ګټور کارونه کوي. هر تازه معلومات په اوتومات ډول ازمول کیږي - د سطحې کچې څخه د سوداګرۍ سناریو اتومات پورې. پایلې په TestRail کې د جلا راپورونو په توګه ځړول شوي.
کلتور
دوامداره تجربه د ازموینې ډیزاین د مثال له لارې غوره توضیح شوې. د داسې سیسټم ازموینه چې لا تر اوسه شتون نلري تخلیقی کار دی. کله چې د ازموینې پلان ولیکئ، تاسو اړتیا لرئ پوه شئ چې څنګه سمه ازموینه وکړئ او کومې څانګې تعقیب کړئ. او همدارنګه د وخت او بودیجې تر مینځ توازن ومومئ ترڅو د چکونو مطلوب شمیر مشخص کړئ. دا مهمه ده چې دقیقا اړین ازموینې غوره کړئ، په دې اړه فکر وکړئ چې کاروونکي به څنګه د سیسټم سره اړیکه ونیسي، چاپیریال او ممکنه بهرني عوامل په پام کې ونیسي. د دوامداره تجربې پرته دا ناشونې ده.
اوس د تعامل کلتور په اړه. پخوا، دوه مخالف اړخونه وو - انجنیران او پراختیا کونکي. پرمخ وړونکو وویل: "موږ پروا نه لرو چې دا به څنګه پیل شي. تاسو انجنیران یاست، تاسو هوښیار یاست، ډاډ ترلاسه کړئ چې دا پرته له ناکامۍ څخه کار کوي ". انجنیرانو ځواب ورکړ: "تاسو پراختیا کونکي ډیر بې پروا یاست. راځئ چې ډیر محتاط اوسو، او موږ به ستاسو ریلیزونه لږ ځله ولوبوو. ځکه چې هرکله چې تاسو موږ ته یو لیک کوډ راکړئ، دا موږ ته روښانه نه ده چې څنګه تعامل وکړو.. دا د کلتوري متقابل عمل مسله ده چې د DevOps لید څخه په مختلف ډول تنظیم شوې. دلته، دواړه انجنیران او پراختیا کونکي د یو واحد ټیم برخه ده چې په دوامداره توګه بدلون باندې تمرکز کوي، مګر په ورته وخت کې د باور وړ سافټویر.
په ورته ټیم کې، متخصصین د یو بل سره د مرستې لپاره ټاکل شوي. لکه څنګه چې مخکې وه؟ د بېلګې په توګه، څه د پاسه 50 پاڼې اوږدوالی، د نصبولو ځینې لارښوونې چمتو شوې وې، انجنیر یې ولوستل، په یو څه پوه نه شو، لعنت یې وکړ او د سهار په دریو بجو یې له جوړونکي څخه وغوښتل چې تبصره وکړي. پرمخ وړونکي تبصره وکړه او لعنت یې هم وکړ - په پای کې، هیڅوک خوشحاله نه و. برسیره پردې، په طبیعي توګه، ځینې غلطۍ وې، ځکه چې تاسو په لارښوونو کې هرڅه په یاد نشئ کولی. او اوس انجینر ، د پراختیا کونکي سره یوځای ، د غوښتنلیک سافټویر زیربنا د اتوماتیک پلي کولو لپاره سکریپټ لیکي. او دوی یو بل سره په عملي توګه په ورته ژبه خبرې کوي.
خلک
د ټیم اندازه د تازه کولو ساحې لخوا ټاکل کیږي. ټیم د تحویلي رامینځته کولو پرمهال ګمارل کیږي؛ پدې کې هغه کسان شامل دي چې د عمومي پروژې ټیم څخه علاقه لري. بیا یو تازه پلان د هرې مرحلې لپاره مسؤلینو سره لیکل کیږي ، او ټیم راپور ورکوي لکه څنګه چې دا پرمختګ کوي. د ټیم ټول غړي د تبادلې وړ دي. د ټیم د یوې برخې په توګه، موږ یو بیک اپ جوړونکی هم لرو، مګر هغه تقریبا هیڅکله اړیکه نلري.
د تکنالوژۍ
د ټیکنالوژۍ په ډیاګرام کې، یو څو ټکي په ګوته شوي، مګر د دوی لاندې د ټیکنالوژیو یوه ډله ده - تاسو کولی شئ د دوی د توضیحاتو سره یو بشپړ کتاب خپور کړئ. نو موږ به خورا په زړه پوري روښانه کړو.
د کوډ په توګه زیربنا
اوس، شاید، دا مفهوم به هیڅوک حیران نه کړي، مګر مخکې د زیربناوو توضیحات د غوښتلو لپاره ډیر څه پریښودل. ، د ازموینې چاپیریال ځانګړی و ، دوی پالل شوي او پالل شوي ، د دوړو ذرات له دوی څخه غورځول شوي.
نن ورځ هیڅوک د تجربې کولو څخه ویره نلري. د مجازی ماشینونو بنسټیز انځورونه، او د چاپیریال د ځای پرځای کولو لپاره چمتو شوي سناریوګانې شتون لري. ټول ټیمپلیټونه او سکریپټونه په نسخه کنټرول سیسټم کې زیرمه شوي او سمدستي تازه کیږي. پخوا، کله چې دا اړینه وه چې یو سټینډ ته کڅوړه وړاندې کړئ، د ترتیب تشه ښکاره شوه. اوس تاسو اړتیا لرئ د سرچینې کوډ ته یوه کرښه اضافه کړئ.
د زیربناوو سکریپټونو او پایپ لاینونو سربیره، د کوډ طریقې په توګه اسناد د اسنادو لپاره هم کارول کیږي. د دې څخه مننه ، دا اسانه ده چې نوي خلک پروژې ته وصل کړئ ، دوی د بیان شوي دندو پراساس سیسټم ته معرفي کړئ ، د مثال په توګه ، د ازموینې پلان کې ، او د ازموینې قضیې بیا کارول.
دوامداره تحویل او څارنه
د DevOps په اړه، موږ د دې په اړه خبرې وکړې چې څنګه موږ د دوامداره تحویلۍ او څارنې پلي کولو لپاره وسیلې غوره کړې. ډیری وختونه د هیڅ شی بیا لیکلو ته اړتیا نشته - دا د مخکینیو لیکلو سکریپټونو کارولو لپاره کافي دي، په سمه توګه د اجزاوو تر مینځ ادغام رامینځته کړئ او د عمومي مدیریت کنسول رامینځته کړئ. او ټولې پروسې د یوې تڼۍ یا مهالویش په کارولو سره پیل کیدی شي.
په انګلیسي کې مختلف مفکورې شتون لري، پرله پسې تحویلي او دوامداره ځای پرځای کول. دواړه د "دوامداره تحویل" په توګه ژباړل کیدی شي ، مګر په حقیقت کې د دوی ترمینځ یو څه توپیر شتون لري. زموږ په پروژه کې د توزیع شوي انرژي شرکت تخنیکي سند جریان لپاره ، بلکه تحویلي کارول کیږي - کله چې د تولید لپاره نصب کول په قوماندې پیښیږي. په پلي کولو کې، نصب کول په اتوماتيک ډول ترسره کیږي. په دې پروژه کې دوامداره تحویلي په عمومي توګه رامینځته شوي د DevOps مرکزي برخه.
په عموم کې، د ځانګړو پیرامیټونو په راټولولو سره، تاسو کولی شئ په روښانه توګه پوه شئ چې ولې د DevOps کړنې ګټورې دي. او دا مدیریت ته ورسوئ ، څوک چې واقعیا شمیر سره مینه لري. د لانچونو ټوله شمیره ، د سکریپټ مرحلو اجرا کولو وخت ، د بریالۍ لانچونو برخه - دا ټول په مستقیم ډول بازار ته د هرچا د خوښې وخت اغیزه کوي ، دا د نسخې کنټرول سیسټم ته د ژمنې څخه د نسخې خوشې کیدو پورې وخت دی. د تولید چاپیریال. د اړینو وسیلو په پلي کولو سره، انجنیران د بریښنالیک له لارې ارزښتناکه شاخصونه ترلاسه کوي، او د پروژې مدیر دوی په ډشبورډ کې ګوري. پدې توګه تاسو کولی شئ سمدلاسه د نوي وسیلو ګټې ارزونه وکړئ. او تاسو کولی شئ دا د DevOps ډیزاینر په کارولو سره په خپلو زیربناوو کې هڅه وکړئ.
څوک به زموږ ته اړتیا ولري ?
راځئ چې ویاړ ونه کړو: د پیل لپاره، هغه زموږ لپاره ګټور شو. لکه څنګه چې موږ دمخه وویل ، تاسو اړتیا لرئ د پیرودونکي سره ورته ژبه وغږیږئ ، او د DevOps ډیزاینر په مرسته موږ کولی شو ژر تر ژره د داسې خبرو اترو اساس ترتیب کړو. د سوداګرۍ متخصصین به وکولی شي د ځان لپاره ارزونه وکړي چې دوی ورته اړتیا لري او پدې توګه ګړندی وده کوي. موږ هڅه وکړه چې ډیزاینر د امکان تر حده مفصل کړو ، د توضیحاتو یوه ډله اضافه کړو ترڅو هر کارونکی پوه شي چې هغه څه غوره کوي.
د ډیزاینر بڼه تاسو ته اجازه درکوي چې د جوړونې پروسو او اتومات کولو کې د شرکت موجوده پرمختګونه په پام کې ونیسئ. اړتیا نشته چې هرڅه مات کړئ او بیا یې جوړ کړئ که تاسو کولی شئ یوازې هغه حلونه غوره کړئ چې د موجوده پروسو سره ښه مدغم شي او دا کولی شي په ساده ډول تشې ډکې کړي.
شاید ستاسو پرمختګ لا دمخه لوړې کچې ته رسیدلی وي او زموږ وسیله به ډیر "کپتان" ښکاري. مګر موږ دا د ځان لپاره ګټور ګڼو او امید لرو چې دا به د ځینو لوستونکو لپاره ګټور وي. موږ تاسو ته یادونه کوو ډیزاینر ته - که کوم څه وي، تاسو د لومړنیو معلوماتو د ننوتلو وروسته سمدلاسه ډیاګرام ترلاسه کوئ. موږ به ستاسو د نظرونو او اضافو څخه مننه وکړو.
سرچینه: www.habr.com