اسان هڪ دفعو هڪ سهولت تي هڪ ڪسٽمر کي هڪ اليڪٽرانڪ دستاويز مينيجمينٽ سسٽم فراهم ڪيو. ۽ پوءِ ٻي شئي ڏانهن. ۽ هڪ وڌيڪ. ۽ چوٿين تي، ۽ پنجين تي. اسان ايترو پري ٿي وياسون ته اسان 10 ورهايل شيون پهچي ويا. اهو طاقتور طور تي نڪتو ... خاص طور تي جڏهن اسان تبديلين کي پهچائڻو پوندو. پيداوار جي سرڪٽ تائين پهچائڻ جي حصي جي طور تي، ٽيسٽنگ سسٽم جي 5 منظرنامي آخرڪار 10 ڪلاڪ ۽ 6-7 ملازمن جي ضرورت آهي. اهڙن خرچن اسان کي ترسيل ڪرڻ تي مجبور ڪيو جيترو ممڪن طور تي. ٽن سالن جي آپريشن کان پوءِ، اسان ان کي برداشت نه ڪري سگهياسين ۽ ڊيو اوپس جي هڪ چوٽي سان منصوبي کي مسالا ڪرڻ جو فيصلو ڪيو.
ھاڻي سڀ ٽيسٽنگ 3 ڪلاڪن ۾ ٿيندي آھي، ۽ 3 ماڻھو ان ۾ حصو وٺندا آھن: ھڪ انجنيئر ۽ ٻه ٽيسٽر. سڌارا واضح طور تي انگن ۾ ظاهر ڪيا ويا آهن ۽ تمام گهڻو پسند ڪيل TTM ۾ گهٽتائي جو سبب بڻجن ٿا. اسان جي تجربي ۾، اهڙا ڪيترائي گراهڪ آهن جيڪي DevOps مان فائدو حاصل ڪري سگھن ٿا انهن جي ڀيٽ ۾ جيڪي ان بابت ڄاڻن ٿا. تنهن ڪري، DevOps کي ماڻهن جي ويجھو آڻڻ لاءِ، اسان هڪ سادو تعمير ڪندڙ ٺاهيو آهي، جنهن بابت اسين هن پوسٽ ۾ وڌيڪ تفصيل سان ڳالهائينداسين.
هاڻي اچو ته توهان کي وڌيڪ تفصيل سان ٻڌايو. هڪ توانائي ڪمپني 10 وڏين سهولتن تي هڪ ٽيڪنيڪل دستاويز مينيجمينٽ سسٽم کي ترتيب ڏئي رهي آهي. DevOps کان سواءِ هن پيماني جي منصوبن کي نيويگيٽ ڪرڻ آسان ناهي ، ڇاڪاڻ ته دستي مزدوري جو وڏو حصو ڪم کي تمام گهڻو دير ڪري ٿو ۽ معيار کي به گهٽائي ٿو - سڀ دستي ڪم غلطين سان ڀريل آهي. ٻئي طرف، اهڙا منصوبا آهن جتي صرف هڪ تنصيب آهي، پر هر شيء کي خودڪار طريقي سان ڪم ڪرڻ جي ضرورت آهي، مسلسل ۽ ناڪامي کان سواء - مثال طور، وڏي monolithic تنظيمن ۾ ساڳئي دستاويز جي وهڪري سسٽم. ٻي صورت ۾، ڪو ماڻهو دستي طور تي سيٽنگون ٺاهيندو، ترتيب ڏيڻ جي هدايتن جي باري ۾ وساريندو - ۽ نتيجي ۾، پيداوار ۾ سيٽنگون گم ٿي وينديون ۽ سڀ ڪجهه ختم ٿي ويندو.
عام طور تي اسان هڪ معاهدي جي ذريعي گراهڪ سان ڪم ڪندا آهيون، ۽ انهي صورت ۾ اسان جا مفاد ٿورڙي ڌار ٿي ويندا آهن. گراهڪ منصوبي کي سختي سان بجيٽ ۽ ٽيڪنيڪل وضاحتن ۾ ڏسي ٿو. هن کي مختلف DevOps طريقن جي فائدن جي وضاحت ڪرڻ ڏکيو ٿي سگهي ٿو جيڪي ٽيڪنيڪل وضاحتن ۾ شامل نه آهن. ڇا جيڪڏهن هو شامل ڪيل ڪاروباري قدر سان جلدي رليز ۾ دلچسپي رکي ٿو، يا هڪ آٽوميشن پائيپ لائين تعمير ڪرڻ ۾؟
افسوس، جڏهن اڳ-منظور ٿيل قيمت سان ڪم ڪندي، هي دلچسپي هميشه نه ملندي آهي. اسان جي عمل ۾، هڪ ڪيس هو جڏهن اسان کي هڪ بي ايمان ۽ لاپرواهه ٺيڪيدار جي ترقي کي کڻڻو پيو. اهو خوفناڪ هو: ڪو به تازه ترين ماخذ ڪوڊ نه هئا، ساڳئي سسٽم جو ڪوڊ بيس مختلف تنصيب تي مختلف هو، دستاويز جزوي طور تي غير حاضر هو، ۽ جزوي طور تي خوفناڪ معيار جو. يقينن، گراهڪ کي ماخذ ڪوڊ، اسيمبلي، رليز، وغيره تي ڪنٽرول نه هو.
ايترو پري، هرڪو نه ڄاڻي ٿو DevOps بابت، پر جيئن ئي اسان ان جي فائدن بابت ڳالهائينداسين، حقيقي وسيلن جي بچت بابت، سڀني گراهڪن جون اکيون روشن ٿي وينديون آهن. تنهن ڪري درخواستن جو تعداد جنهن ۾ DevOps شامل آهن وقت سان وڌي رهيو آهي. هتي، گراهڪن سان آساني سان ساڳي ٻولي ڳالهائڻ لاءِ، اسان کي جلدي ڳنڍڻ جي ضرورت آهي ڪاروباري مسئلن ۽ DevOps عملن کي جيڪي مدد ڪنديون هڪ مناسب ڊولپمينٽ پائيپ لائين ٺاهڻ ۾.
تنهن ڪري، اسان وٽ هڪ طرف مسئلن جو هڪ سيٽ آهي، اسان وٽ آهي DevOps علم، عمل ۽ اوزار ٻئي طرف. ڇو نه هر ڪنهن سان تجربو حصيداري ڪريو؟
هڪ DevOps تعمير ڪندڙ ٺاهڻ
چستيءَ جو پنهنجو منشور آهي. ITIL جو پنهنجو طريقو آهي. DevOps گهٽ خوش قسمت آهي - اهو اڃا تائين ٽيمپليٽ ۽ معيار حاصل نه ڪيو آهي. جيتوڻيڪ انهن جي ترقي ۽ آپريشنل طريقن جي تشخيص جي بنياد تي ڪمپنين جي پختگي جو اندازو لڳايو.
خوشقسمتيء سان، معروف ڪمپني گارٽنر 2014 ۾ ۽ اهم DevOps طريقن ۽ انهن جي وچ ۾ لاڳاپن جو تجزيو ڪيو. انهي جي بنياد تي، مون هڪ انفراگرافڪ جاري ڪيو:
اسان ان کي اسان جي بنياد جي طور تي ورتو . چئن علائقن مان هر هڪ وٽ اوزارن جو هڪ سيٽ آهي - اسان انهن کي ڊيٽابيس ۾ گڏ ڪيو، سڀ کان وڌيڪ مشهور ماڻهن جي نشاندهي ڪئي، انٽيگريشن پوائنٽس ۽ مناسب اصلاحي ميڪانيزم جي سڃاڻپ ڪئي. مجموعي طور تي اهو نڪتو 36 طريقا ۽ 115 اوزار، جن جو چوٿون حصو اوپن سورس يا مفت سافٽ ويئر آهن. اڳيون، اسان ان بابت ڳالهائينداسين جيڪو اسان هر علائقي ۾ حاصل ڪيو آهي ۽، مثال طور، هن منصوبي ۾ ڪيئن لاڳو ڪيو ويو ٽيڪنيڪل دستاويز مينيجمينٽ ٺاهڻ، جنهن سان اسان پوسٽ شروع ڪيو.
پروسيس
بدنام EDMS پروجيڪٽ ۾، ٽيڪنيڪل دستاويزن مينيجمينٽ سسٽم کي 10 شين مان هر هڪ تي ساڳئي اسڪيم جي مطابق لڳايو ويو. تنصيب ۾ 4 سرور شامل آهن: ڊيٽابيس سرور، ايپليڪيشن سرور، مڪمل ٽيڪسٽ انڊيڪسنگ ۽ مواد جو انتظام. تنصيب ۾، اهي هڪ واحد نوڊ اندر هلندا آهن ۽ سهولتن تي ڊيٽا سينٽر ۾ واقع آهن. سڀ شيون انفراسٽرڪچر ۾ ٿورو مختلف آهن، پر اهو عالمي رابطي سان مداخلت نٿو ڪري.
پهرين، DevOps جي عملن جي مطابق، اسان مقامي طور تي انفراسٽرڪچر کي خودڪار ڪيو، پوء اسان ترسيل کي ٽيسٽ سرڪٽ تائين پهچايو، ۽ پوء گراهڪ جي پيداوار ڏانهن. هر عمل کي قدم سان ڪم ڪيو ويو. ماحول جي سيٽنگون ماخذ ڪوڊ سسٽم ۾ مقرر ڪيون ويون آهن، انهي حساب ۾ وٺندي جيڪا تقسيم کٽ خودڪار تازه ڪاري لاء مرتب ڪئي وئي آهي. ترتيب جي تبديلين جي صورت ۾، انجنيئرن کي صرف ورزن ڪنٽرول سسٽم ۾ مناسب تبديليون ڪرڻ جي ضرورت آهي - ۽ پوء خودڪار تازه ڪاري بغير مسئلن جي ٿيندي.
هن طريقي جي مهرباني، جاچ واري عمل کي تمام گهڻو آسان ڪيو ويو آهي. اڳي، پروجيڪٽ ۾ ٽيسٽ ڪندڙ هئا جن ڪجهه نه ڪيو پر دستي طور تي اسٽينڊ کي اپڊيٽ ڪيو. ھاڻي اھي رڳو اچن ٿا، ڏسو ته سڀ ڪجھ ڪم ڪري رھيو آھي ۽ وڌيڪ مفيد شيون ڪريو. هر تازه ڪاري خودڪار طور تي آزمائي ڪئي وئي آهي - سطح جي سطح کان وٺي ڪاروباري منظر جي آٽوميشن تائين. نتيجا ٽيسٽ ريل ۾ الڳ رپورٽن طور پوسٽ ڪيا ويا آهن.
ثقافت
مسلسل تجربا ٽيسٽ ڊيزائن جي مثال ذريعي وضاحت ڪئي وئي آهي. هڪ سسٽم کي جانچڻ جيڪو اڃا تائين موجود ناهي تخليقي ڪم آهي. جڏهن هڪ ٽيسٽ پلان لکڻ، توهان کي سمجهڻ جي ضرورت آهي ته ڪيئن صحيح طريقي سان جانچ ڪجي ۽ ڪهڙي شاخن جي پيروي ڪجي. ۽ وقت ۽ بجيٽ جي وچ ۾ توازن پڻ ڳوليو چيڪن جي بهترين تعداد کي طئي ڪرڻ لاءِ. اهو ضروري آهي ته صحيح طور تي ضروري ٽيسٽ چونڊڻ، سوچيو ته صارف ڪيئن سسٽم سان لهه وچڙ ڪندو، ماحول ۽ ممڪن خارجي عنصر کي نظر ۾ رکندي. مسلسل تجربن کان سواء ائين ڪرڻ ناممڪن آهي.
هاڻي رابطي جي ثقافت جي باري ۾. اڳي، اتي ٻه مخالف ڌر هئا - انجنيئر ۽ ڊولپر. ڊولپرز چيو ته: ”اسان کي پرواه ناهي ته اهو ڪيئن شروع ڪيو ويندو. توهان انجنيئر آهيو، توهان هوشيار آهيو، پڪ ڪريو ته اهو ناڪامي کان سواء هلندو آهي ". انجنيئرن جواب ڏنو: ”توهان ڊولپر ڏاڍا لاپرواهه آهيو. اچو ته وڌيڪ محتاط رهون، ۽ اسان توهان جي رليز کي گهٽ ۾ گهٽ ادا ڪنداسين. ڇاڪاڻ ته هر دفعي توهان اسان کي هڪ لڪي ڪوڊ ڏيو ٿا، اهو اسان کي واضح ناهي ته ڪيئن رابطو ڪجي.. هي هڪ ثقافتي رابطي جو مسئلو آهي جيڪو مختلف طرح سان ٺهيل آهي DevOps نقطه نظر کان. هتي، انجنيئر ۽ ڊولپر ٻئي هڪ واحد ٽيم جو حصو آهن جيڪي مسلسل تبديل ڪرڻ تي مرکوز آهن، پر ساڳئي وقت قابل اعتماد سافٽ ويئر.
ساڳئي ٽيم جي اندر، ماهرن هڪ ٻئي جي مدد ڪرڻ لاء پرعزم آهن. جيئن ته اهو اڳ هو؟ مثال طور، اٽڪل 50 صفحا ڊگھا، ڪجهه ٿلها ڊولپمينٽ هدايتون تيار ٿي رهيون هيون، انجنيئر اهو پڙهيو، ڪجهه نه سمجھي، لعنت ڪئي ۽ صبح جو ٽي وڳي ڊولپر کي تبصرو ڪرڻ لاءِ چيو. ڊولپر تبصرو ڪيو ۽ پڻ لعنت ڪئي - آخر ۾، ڪو به خوش نه هو. ان سان گڏ، قدرتي طور تي، ڪجهه غلطيون هيون، ڇو ته توهان هدايتن ۾ سڀ ڪجهه ياد نه ٿا ڪري سگهو. ۽ هاڻي انجنيئر، ڊولپر سان گڏ، ايپليڪيشن سافٽ ويئر انفراسٽرڪچر جي خودڪار ترتيب ڏيڻ لاء هڪ اسڪرپٽ لکي رهيو آهي. ۽ اهي هڪ ٻئي سان عملي طور تي ساڳي ٻولي ۾ ڳالهائيندا آهن.
ماڻهو
ٽيم جو سائز اپڊيٽ جي دائري سان طئي ڪيو ويندو آهي. ٽيم کي ترسيل جي ٺهڻ دوران نوڪر ڪيو ويو آهي؛ ان ۾ شامل آهن جيڪي عام پروجيڪٽ ٽيم مان دلچسپي وٺندا آهن. ان کان پوء هڪ تازه ڪاري منصوبو هر اسٽيج جي ذميوارن سان لکيو ويو آهي، ۽ ٽيم رپورٽ ڪري ٿي جيئن اها ترقي ڪري ٿي. سڀئي ٽيم جا ميمبر مٽائي سگهجن ٿا. ٽيم جي حصي جي طور تي، اسان وٽ هڪ بيڪ اپ ڊولپر پڻ آهي، پر هن کي تقريبا ڪڏهن به ڳنڍڻ جي ضرورت ناهي.
ٽيڪنالاجي جو
ٽيڪنالاجي ڊراگرام ۾، ڪجھ نقطا نمايان ٿيل آھن، پر انھن جي ھيٺان ٽيڪنالاجيز جو ھڪڙو گروپ آھي - توھان انھن جي تفصيل سان پورو ڪتاب شايع ڪري سگھو ٿا. تنهنڪري اسان سڀ کان وڌيڪ دلچسپ بيان ڪنداسين.
بنيادي ڍانچي جيئن ڪوڊ
هاڻي، شايد، اهو تصور ڪنهن کي حيران نه ڪندو، پر اڳي ئي انفراسٽرڪچر جي وضاحت گهڻو ڪري ڇڏي ويو آهي. ، امتحان جا ماحول منفرد هئا، انهن کي پاليو ويو ۽ پاليو ويو، مٽي جا ذرڙا انهن مان ڦٽي ويا.
اڄڪلهه ڪو به تجربو ڪرڻ کان ڊپ ناهي. ورچوئل مشينن جون بنيادي تصويرون آھن، ماحوليات کي ترتيب ڏيڻ لاءِ تيار ٿيل منظرنامو آھن. سڀئي ٽيمپليٽ ۽ اسڪرپٽ ورزن ڪنٽرول سسٽم ۾ ذخيرو ٿيل آهن ۽ فوري طور تي اپڊيٽ ڪيا ويندا آهن. اڳي، جڏهن اهو ضروري هو ته هڪ پيڪيج کي اسٽينڊ تي پهچائڻ، هڪ تشڪيل خلا ظاهر ٿيو. هاڻي توهان کي صرف سورس ڪوڊ ۾ هڪ لائن شامل ڪرڻ جي ضرورت آهي.
انفراسٽرڪچر اسڪرپٽس ۽ پائپ لائنن کان علاوه، دستاويزن لاءِ به استعمال ڪيو ويندو آهي هڪ ڪوڊ اپروچ جي طور تي دستاويز. انهي جي مهرباني، نئين ماڻهن کي منصوبي سان ڳنڍڻ آسان آهي، انهن کي بيان ڪيل ڪمن جي بنياد تي سسٽم ۾ متعارف ڪرايو، مثال طور، ٽيسٽ پلان ۾، ۽ پڻ ٽيسٽ ڪيس ٻيهر استعمال ڪريو.
مسلسل پهچائڻ ۽ نگراني
DevOps جي باري ۾، اسان ڳالهايو ته ڪيئن اسان مسلسل ترسيل ۽ نگراني کي لاڳو ڪرڻ لاءِ اوزار چونڊيو. گهڻو ڪري ڪا به شيء ٻيهر لکڻ جي ڪا ضرورت ناهي - اهو ڪافي آهي اڳي لکيل اسڪرپٽ استعمال ڪرڻ، صحيح طور تي اجزاء جي وچ ۾ انضمام ۽ هڪ عام انتظام ڪنسول ٺاهي. ۽ سڀني عملن کي ھڪڙي بٽڻ يا شيڊول استعمال ڪندي شروع ڪري سگھجي ٿو.
انگريزيءَ ۾ مختلف مفهوم آهن، مسلسل پهچائڻ ۽ مسلسل ترتيب ڏيڻ. ٻنهي کي ”مسلسل ترسيل“ طور ترجمو ڪري سگهجي ٿو، پر حقيقت ۾ انهن جي وچ ۾ ٿورو فرق آهي. اسان جي منصوبي ۾ ورهايل توانائي ڪمپني جي ٽيڪنيڪل دستاويز جي وهڪري لاء، بلڪه، پهچائڻ استعمال ڪيو ويندو آهي - جڏهن پيداوار لاء انسٽاليشن حڪم تي ٿيندي آهي. لڳائڻ ۾، انسٽاليشن خودڪار طريقي سان ٿيندي آهي. هن منصوبي ۾ مسلسل ترسيل عام ٿي چڪو آهي DevOps جو مرڪزي حصو.
عام طور تي، ڪجهه پيٽرولر گڏ ڪرڻ سان، توهان واضح طور تي سمجهي سگهو ٿا ڇو DevOps طريقا ڪارآمد آهن. ۽ ھن کي انتظاميا تائين پھچايو، جيڪو واقعي نمبرن سان پيار ڪندو آھي. لانچن جو ڪل تعداد، اسڪرپٽ مرحلن جي عمل جو وقت، ڪامياب لانچن جو حصو - اهو سڀ سڌو سنئون اثر انداز ٿئي ٿو هر ڪنهن جي پسنديده وقت مارڪيٽ ڏانهن، اهو آهي، ورزن ڪنٽرول سسٽم جي وابستگي کان وٺي هڪ ورزن جي جاري ٿيڻ تائين. پيداوار ماحول. ضروري اوزارن جي عمل درآمد سان، انجنيئر ميل ذريعي قيمتي اشارا وصول ڪن ٿا، ۽ پروجيڪٽ مئنيجر انھن کي ڊيش بورڊ تي ڏسي ٿو. هن طريقي سان توهان فوري طور تي نئين اوزار جي فائدن جو اندازو لڳائي سگهو ٿا. ۽ توھان انھن کي آزمائي سگھوٿا پنھنجي انفراسٽرڪچر تي استعمال ڪندي DevOps ڊيزائنر.
جنهن کي اسان جي ضرورت پوندي ?
اچو ته ٺڳي نه ڪريون: شروعات لاءِ، هو اسان لاءِ ڪارآمد ثابت ٿيو. جيئن اسان اڳ ۾ ئي چيو آهي، توهان کي ڪسٽمر سان ساڳي ٻولي ڳالهائڻ جي ضرورت آهي، ۽ DevOps ڊزائنر جي مدد سان اسان جلدي طور تي اهڙي گفتگو جو بنياد ٺاهي سگهون ٿا. ڪاروباري ماهر پاڻ لاءِ اندازو لڳائي سگهندا ته انهن کي ڪهڙي ضرورت آهي ۽ اهڙي طرح تيزيءَ سان ترقي ڪندا. اسان ڊزائنر کي ممڪن طور تي تفصيلي بڻائڻ جي ڪوشش ڪئي، وضاحتن جو هڪ گروپ شامل ڪيو ته جيئن ڪو به صارف سمجهي ته هو ڇا چونڊي رهيو آهي.
ڊزائنر جو فارميٽ توهان کي ڪمپني جي موجوده ترقيات کي عمارت جي عملن ۽ آٽوميشن ۾ اڪائونٽ ۾ رکڻ جي اجازت ڏئي ٿو. هر شي کي ٽوڙڻ ۽ ان کي ٻيهر تعمير ڪرڻ جي ڪا ضرورت ناهي جيڪڏهن توهان صرف اهي حل چونڊي سگهو ٿا جيڪي موجوده عملن سان چڱي طرح ضم ٿي سگهن ٿا ۽ اهو صرف خال ڀري سگهي ٿو.
شايد توهان جي ترقي اڳ ۾ ئي هڪ اعلي سطح تي منتقل ٿي چڪي آهي ۽ اسان جو اوزار پڻ "ڪئپٽن جو" نظر ايندو. پر اسان ان کي پنهنجي لاءِ مفيد سمجهون ٿا ۽ اميد ٿا ڪريون ته اهو ڪجهه پڙهندڙن لاءِ مفيد ثابت ٿيندو. اسان توهان کي ياد ڏياريندا آهيون ڊزائنر ڏانهن - جيڪڏهن ڪجھ به، توهان شروعاتي ڊيٽا داخل ڪرڻ کان پوء فوري طور تي ڊراگرام وصول ڪندا. اسان توهان جي راء ۽ اضافو لاء شڪرگذار ٿينداسين.
جو ذريعو: www.habr.com