رپورٽ ڪجهه DevOps طريقن بابت ڳالهائيندو، پر ڊولپر جي نقطي نظر کان. عام طور تي، سڀئي انجنيئر جيڪي DevOps ۾ شامل ٿيندا آهن انهن جي بيلٽ هيٺ ڪيترن ئي سالن جو انتظامي تجربو آهي. پر هن جو مطلب اهو ناهي ته هتي ڊولپر لاء ڪا جاء ناهي. گهڻو ڪري نه، ڊولپرز ”ڏينهن جي ايندڙ تڪڙي نازڪ بگ“ کي درست ڪرڻ ۾ مصروف آهن، ۽ انهن وٽ وقت نه آهي ته هو DevOps فيلڊ تي تڪڙو نظر وجهن. ليکڪ جي سمجھ ۾، DevOps آهي، پهريون، عام احساس. ٻيو، اهو هڪ موقعو آهي جيڪو وڌيڪ اثرائتو آهي. جيڪڏهن توهان هڪ ڊولپر آهيو، عام عقل آهي ۽ هڪ ٽيم پليئر جي حيثيت سان وڌيڪ اثرائتو ٿيڻ چاهيو ٿا، هي رپورٽ توهان لاءِ آهي.
مون کي پنهنجو تعارف ڪرائڻ ڏيو، مان مڪمل طور تي تسليم ڪريان ٿو ته ڪمري ۾ اهڙا ماڻهو آهن جيڪي مون کي نٿا سڃاڻن. منهنجو نالو Anton Boyko آهي، مان هڪ Microsoft Azure MVP آهيان. MVP ڇا آهي؟ هي آهي Model-View-Presenter. ماڊل-ڏسو- پيش ڪندڙ بلڪل مان آهيان.
ان کان علاوه، مان هن وقت Ciklum ۾ حل معمار جي حيثيت رکي ٿو. ۽ تازو ئي مون پنهنجو پاڻ کي هڪ خوبصورت ڊومين خريد ڪيو، ۽ مون پنهنجي اي ميل کي اپڊيٽ ڪيو، جيڪو آئون اڪثر ڪري پيش ڪيلن ۾ ڏيکاري ٿو. توھان مون کي ھن تي لکي سگھو ٿا: me [dog] byokoant.pro. توھان مون کي سوالن سان اي ميل ڪري سگھو ٿا. آئون اڪثر انهن کي جواب ڏيان ٿو. صرف اها آهي ته مان اي ميل ذريعي سوال حاصل ڪرڻ نه چاهيندس جيڪي ٻن عنوانن سان تعلق رکن ٿا: سياست ۽ مذهب. توهان اي ميل ذريعي مون کي هر شيء بابت لکي سگهو ٿا. ڪجهه وقت گذري ويندو، مان جواب ڏيندس.
منهنجي باري ۾ چند لفظ:
- مان هن فيلڊ ۾ 10 سالن کان وٺي چڪو آهيان.
- مون Microsoft ۾ ڪم ڪيو.
- مان يوڪريني ازور ڪميونٽي جو باني پيء آهيان، جنهن کي اسان 2014 ۾ ڪٿي قائم ڪيو. ۽ اسان وٽ اڃا تائين آهي ۽ ان کي ترقي ڪري رهيا آهيون.
- مان پڻ آهيان Azure ڪانفرنس جي باني جو پيء، جيڪو اسان يوڪرين ۾ ميزباني ڪري رهيا آهيون.
- مان ڪيف ۾ گلوبل ايزور بوٽ ڪيمپ کي منظم ڪرڻ ۾ پڻ مدد ڪريان ٿو.
- جيئن مون چيو، مان هڪ Microsoft Azure MVP آهيان.
- مان اڪثر ڪانفرنسن ۾ ڳالهائيندو آهيان. مون کي واقعي ڪانفرنس ۾ ڳالهائڻ پسند آهي. گذريل سال دوران آئون اٽڪل 40 ڀيرا انجام ڏيڻ جي قابل ٿي چڪو آهيان. جيڪڏهن توهان يوڪرين، بيلاروس، پولينڊ، بلغاريا، سويڊن، ڊنمارڪ، هالينڊ، اسپين وٽان لنگهندا آهيو يا يورپ جو ڪو ٻيو ملڪ ڏيو يا وٺو، ته پوءِ اهو بلڪل ممڪن آهي ته جڏهن توهان ڪنهن ڪانفرنس ۾ وڃو جنهن جي وهڪري ۾ ڪلائوڊ موضوع هجي، توهان مون کي ڳالهائيندڙن جي فهرست تي ڏسي سگهو ٿا.
- مان پڻ هڪ اسٽار ٽريڪ پرستار آهيان.
اچو ته ايجنڊا بابت ٿورو ڳالهايون. اسان جو ايجنڊا بلڪل سادو آهي:
- اسان ڳالهائينداسين ته ڇا آهي DevOps. اچو ته ڳالهايون ڇو ته هي اهم آهي. اڳي، DevOps هڪ لفظ هو جيڪو توهان پنهنجي شروع تي لکيو ۽ فوري طور تي وصول ڪيو + $500 تنخواه ۾. هاڻي توهان کي لکڻ جي ضرورت آهي، مثال طور، توهان جي ريزومي ۾ بلاڪچين حاصل ڪرڻ لاءِ +500 ڊالر توهان جي تنخواه ۾.
- ۽ پوءِ ، جڏهن اسان ٿورو سمجھون ٿا ته اهو ڇا آهي ، اسان ڳالهائينداسين ته ڇا DevOps طريقا آهن. پر عام طور تي DevOps جي حوالي سان ايترو گهڻو نه، پر انهن DevOps طريقن بابت جيڪي ڊولپرز لاءِ دلچسپيءَ جا هوندا. مان توهان کي ٻڌايان ٿو ته اهي توهان لاءِ دلچسپيءَ جا ڇو هوندا. مان توهان کي ٻڌايان ٿو ته توهان کي اهو سڀ ڪجهه ڇو ڪرڻ گهرجي ۽ اهو ڪيئن توهان جي مدد ڪري سگهي ٿو گهٽ درد جو تجربو.
هڪ روايتي تصوير جيڪا ڪيترن ئي ماڻهن کي ڏيکاري ٿي. اھو آھي جيڪو ڪيترن ئي منصوبن ۾ ٿئي ٿو. اهو آهي جڏهن اسان وٽ ترقي ۽ آپريشن جا شعبا آهن جيڪي اسان جي سافٽ ويئر کي سپورٽ ڪن ٿا. ۽ اهي شعبا هڪ ٻئي سان رابطو نٿا ڪن.
ٿي سگهي ٿو، جيڪڏهن توهان ان کي محسوس ڪرڻ جي قابل نه هئا ته اهو واضح طور تي DevOps ۽ آپريشن شعبن ۾، توهان ٺاهي سگهو ٿا هڪ قياس ديو ۽ QA شعبن سان. اهڙا ماڻهو آهن جيڪي سافٽ ويئر ٺاهي رهيا آهن ۽ QA ماڻهو آهن جيڪي ڊولپرز جي نقطي نظر کان خراب آهن. مثال طور، مان پنهنجو شاندار ڪوڊ ريپوزٽري ڏانهن موڪليان ٿو، ۽ اتي ڪجهه بدمعاش بيٺو آهي جيڪو مون کي اهو ڪوڊ واپس ڪري ٿو ۽ چوي ٿو ته توهان جو ڪوڊ خراب آهي.
اهو سڀ ڪجهه ٿئي ٿو ڇاڪاڻ ته ماڻهو هڪ ٻئي سان رابطو نٿا ڪن. ۽ اهي غلط فهمي جي ڪنهن ديوار ذريعي هڪ ٻئي ڏانهن ڪجهه پيڪيجز، ڪجهه ايپليڪيشن اڇليندا آهن ۽ انهن سان ڪجهه ڪرڻ جي ڪوشش ڪندا آهن.
اهو خاص طور تي اها ديوار آهي جيڪا DevOps ڪلچر کي تباهه ڪرڻ لاءِ ٺهيل آهي، يعني. ماڻهن کي مجبور ڪيو ته هو هڪ ٻئي سان رابطو ڪن ۽ گهٽ ۾ گهٽ سمجهن ته پروجيڪٽ ۾ مختلف ماڻهو ڇا ڪندا آهن ۽ انهن جو ڪم ڇو اهم آهي.
۽ جڏهن اسان DevOps بابت ڳالهائينداسين، ڪو توهان کي ٻڌائيندو ته DevOps اهو آهي جڏهن پروجيڪٽ مسلسل انضمام آهي؛ ڪو به چوندو ته DevOps اهو آهي جيڪڏهن پروجيڪٽ لاڳو ٿئي ٿو "بنيادي ڍانچي جي طور تي ڪوڊ" مشق؛ ڪو چوندو ته DevOps ڏانهن پهريون قدم آهي خصوصيت برانچنگ، فيچر پرچم.
لازمي طور تي، اهو سڀ ڪجهه پنهنجي طريقي سان صحيح آهي. پر اهي صرف حتمي طريقا آهن جيڪي اسان وٽ آهن. انهن عملن تي اڳتي وڌڻ کان اڳ، مان هن سلائيڊ کي ڏسڻ جي صلاح ڏيان ٿو، جيڪا ڏيکاري ٿي 3 مرحلن کي لاڳو ڪرڻ جا طريقا Dev-Ops طريقي سان توهان جي ڪمپني ۾.
ھن سلائڊ ۾ ھڪڙو ٻيو غير رسمي نالو پڻ آھي. توھان آن لائن ڳولي سگھوٿا اھو معلوم ڪرڻ لاءِ ته ڇا آھن 3 Musketeers of DevOps. اهو ممڪن آهي ته توهان هن مضمون کي ڳوليندا. ڇو 3 Musketeers؟ هيٺ اهو چوي ٿو: ماڻهو، عمل ۽ مصنوعات، يعني. پيپلز پارٽي - پورٿس، پورٿس ۽ پورٿس. هتي آهن DevOps جا 3 مشڪيا. هي مضمون وڌيڪ تفصيل سان بيان ڪري ٿو ڇو ته اهو اهم آهي ۽ اهو ڇا آهي.
جڏهن توهان هڪ DevOps ڪلچر کي لاڳو ڪرڻ شروع ڪيو، اهو تمام ضروري آهي ته اهو هيٺين ترتيب ۾ لاڳو ٿئي.
شروعات ۾ توهان کي ماڻهن سان ڳالهائڻ جي ضرورت آهي. ۽ توهان کي ماڻهن کي وضاحت ڪرڻ جي ضرورت آهي ته اهو ڇا آهي ۽ اهي ان مان ڪجهه فائدا ڪيئن حاصل ڪري سگهن ٿا.
اسان جي ڪانفرنس کي DotNet Fest سڏيو ويندو آهي. ۽ جيئن منتظمين مون کي ٻڌايو، اسان خاص طور تي هتي ڊولپرز جي سامعين کي دعوت ڏني آهي، تنهنڪري مون کي اميد آهي ته هال ۾ گهڻا ماڻهو ترقي ۾ شامل هوندا.
اسان ماڻهن جي باري ۾ ڳالهائينداسين، اسان ان بابت ڳالهائينداسين جيڪي ڊولپر هر روز ڪرڻ چاهيندا آهن. اهي سڀ کان وڌيڪ ڇا ٿا چاهين؟ اهي ڪجهه نوان ڪوڊ لکڻ چاهين ٿا، نوان فريم ورڪ استعمال ڪن ٿا، نوان خاصيتون ٺاهي رهيا آهن. ڊولپر گهٽ ۾ گهٽ ڇا ٿا چاهين؟ پراڻن غلطين کي درست ڪريو. مون کي اميد آهي ته توهان مون سان متفق آهيو. اهو ئي آهي جيڪو ڊولپر چاهي ٿو. اهي نوان خاصيتون لکڻ چاهين ٿا، اهي ڪيچ کي درست ڪرڻ نٿا چاهين.
بگن جو تعداد جيڪو هڪ خاص ڊولپر پيدا ڪري ٿو ان تي منحصر آهي ته هن جا هٿ ڪيترا سڌا آهن ۽ اهي هن جي ڪلهن مان ڪيترا وڌندا آهن، ۽ هن جي بٽ جي کيسي مان نه. پر ان جي باوجود، جڏهن اسان وٽ ڪو وڏو پروجيڪٽ هوندو آهي، ڪڏهن ڪڏهن ائين ٿيندو آهي ته هر شيءِ تي نظر رکڻ ناممڪن آهي، ان ڪري اسان لاءِ اهو سٺو لڳندو ته ڪجهه طريقا استعمال ڪريون جيڪي اسان کي وڌيڪ مستحڪم ۽ اعليٰ معيار جو ڪوڊ لکڻ ۾ مدد ڏين.
QAs سڀ کان وڌيڪ ڇا چاهين ٿا؟ مون کي خبر ناهي ته اهي هال ۾ آهن. اهو چوڻ منهنجي لاءِ مشڪل آهي ته مان هڪ QA چاهيان ٿو، ڇاڪاڻ ته مان ڪڏهن به نه رهيو آهيان. ۽ ڇوڪرن کي ڪو به ڏوهه ناهي، اهو چيو ويندو ته مون کي اميد آهي ته مان ڪڏهن به نه ڪندس. پر ان لاءِ نه ته مان انهن جي ڪم کي بي معنيٰ ۽ بيڪار سمجهان ٿو، پر ان ڪري جو مان پاڻ کي اهڙو ماڻهو نه ٿو سمجهان جيڪو اهو ڪم ڪارائتي نموني ڪري سگهي، ان ڪري مان ڪوشش به نه ڪندس. پر مان جيڪو سمجھان ٿو، ان مان جيڪو QA پسند نٿو ڪري، اھو آھي صبح جو ڪم ڪرڻ، مسلسل ڪنھن قسم جي ريگريشن ٽيسٽ کي ھلائڻ، انھن ساڳين غلطين تي قدم کڻڻ جيڪي 3 اسپرنٽ اڳ ڊولپرز کي ٻڌايو ۽ چوندا آھن: ”تون ڪڏھن ڪندين؟ , Monsieur D 'Artagnan، هن بگ کي درست ڪريو. ۽ Monsieur D'Artagnan کيس جواب ڏئي ٿو: "ها، ها، ها، مون اڳ ۾ ئي طئي ڪيو آهي." ۽ اهو ڪيئن ٿئي ٿو ته مون هڪ بگ کي درست ڪيو ۽ رستي ۾ 5 ٺاهيو.
اهي ماڻهو جيڪي پيداوار ۾ هن حل جي حمايت ڪن ٿا، اهو حل ڪرڻ جي بغير ڪم ڪرڻ چاهيندا آهن، انهي ڪري انهن کي هر جمعه کي سرور کي ريبوٽ ڪرڻ جي ضرورت ناهي، جڏهن سڀ عام ماڻهو بار ڏانهن ويندا آهن. ڊولپرز جمعي تي مقرر ڪيا ويا، منتظمين ڇنڇر تائين ويٺا آهن، ڪوشش ڪري رهيا آهن ته هن تعیناتي کي اپ ۽ مقرر ڪيو وڃي.
۽ جڏھن توھان ماڻھن کي بيان ڪندا آھيو ته اھي ساڳيا مسئلا حل ڪرڻ جو مقصد آھن، توھان اڳتي وڌائي سگھوٿا عمل کي رسمي ڪرڻ لاءِ. اهو تمام ضروري آهي. ڇو؟ ڇاڪاڻ ته جڏهن اسان چئون ٿا ”رسمي سازي“، اهو توهان لاءِ ضروري آهي ته توهان بيان ڪيو ته توهان جا عمل گهٽ ۾ گهٽ ڪنهن نيپين تي ڪٿي ٿين ٿا. توهان کي اهو سمجهڻ جي ضرورت آهي ته جيڪڏهن توهان، مثال طور، هڪ QA ماحول يا پيداوار جي ماحول ۾ ترتيب ڏيو، پوء اهو هميشه هن ترتيب ۾ ٿئي ٿو؛ انهن مرحلن تي اسين هلون ٿا، مثال طور، خودڪار يونٽ ٽيسٽ ۽ UI ٽيسٽ. تعیناتي کان پوء، اسان چيڪ ڪريون ٿا ته ڇا تعیناتي چڱي طرح يا خراب ٿي وئي. پر توهان وٽ اڳ ۾ ئي ڪارناما جي هڪ واضح فهرست آهي جنهن کي بار بار بار بار ڪيو وڃي جڏهن توهان پيداوار تي لڳايو.
۽ صرف جڏھن توھان جا عمل باضابطا آھن، ڇا توھان پروڊڪٽ چونڊڻ شروع ڪندا آھيو جيڪي توھان کي انھن عملن کي خودڪار ڪرڻ ۾ مدد ڏين ٿيون.
بدقسمتي سان، مان اڪثر ڪري ڏسان ٿو ته اهو ريورس ۾ ٿئي ٿو. جيئن ئي ڪو ماڻهو ”DevOps“ لفظ ٻڌي ٿو، اهي فوري طور تي جينڪنز کي انسٽال ڪرڻ جي صلاح ڏين ٿا، ڇاڪاڻ ته انهن کي يقين آهي ته جيئن ئي اهي جينڪنز انسٽال ڪندا، انهن وٽ DevOps هوندو. هنن جينڪنز کي انسٽال ڪيو، جينڪنز جي ويب سائيٽ تي ”ڪيئن ڪجي“ آرٽيڪل پڙهيا، انهن ڪيئن ڪجي آرٽيڪلز ۾ پروسيس کي ڀرڻ جي ڪوشش ڪئي، ۽ پوءِ ماڻهن وٽ آيا ۽ ماڻهن کي جھڪايو، چيو ته ڪتاب چوي ٿو ته توهان کي هن طريقي سان ڪرڻ جي ضرورت آهي، تنهنڪري اسان هن طريقي سان ڪندا آهيون.
اهو نه آهي ته جينڪنز هڪ خراب اوزار آهي. منهنجو مطلب اهو ناهي ته ڪنهن به طريقي سان. پر هي صرف هڪ پراڊڪٽ آهي. ۽ جيڪو پراڊڪٽ توهان استعمال ڪيو اهو توهان جو آخري فيصلو هجڻ گهرجي، ۽ نه ئي توهان جو پهريون. توهان جي پيداوار کي ثقافت ۽ طريقن جي عمل جي ذريعي هلائڻ نه گهرجي. اهو سمجھڻ تمام ضروري آهي، ڇو ته مان هن سلائيڊ تي گهڻو وقت گذاريو ۽ اهو سڀ ڪجهه ايترو ڊگهو وقت تائين بيان ڪيو.
اچو ته عام طور تي DevOps طريقن بابت ڳالهايون. اهي ڇا آهن؟ فرق ڇا آهي؟ ان کي ڪيئن آزمايو؟ اهي اهم ڇو آهن؟
پھريون مشق جيڪو توھان ٻڌو ھوندو اھو آھي مسلسل انضمام. شايد منصوبي تي ڪو ماڻهو مسلسل انٽيگريشن (CI) آهي.
سڀ کان وڏو مسئلو اهو آهي ته اڪثر ڪري جڏهن آئون هڪ شخص کان پڇان ٿو: "ڇا توهان وٽ منصوبي تي CI آهي؟" ۽ هو چوي ٿو: ”ها،“ پوءِ جڏهن مان پڇان ٿو ته هو ڇا ٿو ڪري، هو مون کي مڪمل آٽوميشن وارو عمل بيان ڪري ٿو. اهو بلڪل صحيح ناهي.
حقيقت ۾، CI جي مشق جو مقصد صرف ڪوڊ کي ضم ڪرڻ جو مقصد آهي ته مختلف ماڻهو لکن ٿا ڪنهن قسم جي سنگل ڪوڊ بيس ۾. اهو ئي سڀ ڪجهه آهي.
CI سان گڏ، اتي عام طور تي ٻين طريقن سان گڏ آهن - جهڙوڪ مسلسل تعیناتي، رليز مينيجمينٽ، پر اسان ان بابت بعد ۾ ڳالهائينداسين.
CI پاڻ اسان کي ٻڌائي ٿو ته مختلف ماڻهو ڪوڊ لکن ٿا ۽ اهو ڪوڊ لازمي طور تي هڪ واحد ڪوڊ بيس ۾ ضم ٿيڻ گهرجي.
هي اسان کي ڇا ڏئي ٿو ۽ اهو ڇو ضروري آهي؟ جيڪڏهن اسان وٽ DotNet آهي ته پوءِ اهو سٺو آهي، اها هڪ مرتب ٿيل ٻولي آهي، اسان پنهنجي اپليڪيشن کي گڏ ڪري سگهون ٿا. جيڪڏهن اهو گڏ ڪري ٿو، پوء اهو اڳ ۾ ئي سٺو نشاني آهي. ان جو مطلب اڃا تائين ڪجھ به نه آھي، پر اھو پھريون سٺي نشاني آھي جنھن کي اسين گھٽ ۾ گھٽ مرتب ڪري سگھون ٿا.
ان کان پوء اسان ڪجهه ٽيسٽ هلائي سگهون ٿا، جيڪو پڻ هڪ الڳ مشق آهي. ٽيسٽ سڀ سائي آهن - هي ٻيو سٺو نشاني آهي. پر ٻيهر، هن جو مطلب ڪجهه به ناهي.
پر تون ائين ڇو ڪندين؟ اهي سڀئي طريقا جن جي باري ۾ آئون اڄ ڳالهائيندس تقريبن هڪجهڙائي رکي ٿو، يعني لڳ ڀڳ ساڳيا فائدا ۽ پڻ ماپيل آهن تقريبن ساڳئي طريقي سان.
پهرين، اهو توهان کي پهچائڻ جي رفتار کي تيز ڪرڻ جي اجازت ڏئي ٿو. اهو ڪيئن توهان کي پهچائڻ جي رفتار کي تيز ڪرڻ جي اجازت ڏئي ٿو؟ جڏهن اسان پنهنجي ڪوڊ بيس ۾ ڪجهه نيون تبديليون ڪيون ٿا، اسان فوري طور تي هن ڪوڊ سان ڪجهه ڪرڻ جي ڪوشش ڪري سگهون ٿا. اسان انتظار نٿا ڪريون جيستائين خميس اچي ڇو ته خميس تي اسان ان کي QA ماحول ڏانهن جاري ڪريون ٿا، اسان اهو هتي ۽ هتي ئي ڪندا آهيون.
مان توهان کي پنهنجي زندگي جي هڪ اداس ڪهاڻي ٻڌايان ٿو. اهو گهڻو وقت اڳ جي ڳالهه آهي، جڏهن مان اڃا جوان ۽ سهڻو هوس. هاڻي مان اڳ ۾ ئي جوان آهيان، خوبصورت ۽ هوشيار، ۽ معمولي. ڪجهه وقت اڳ مان هڪ پروجيڪٽ ۾ هو. اسان وٽ اٽڪل 30 ڊولپرز جي وڏي ٽيم هئي. ۽ اسان وٽ ھڪڙو وڏو، وڏو انٽرپرائز پروجيڪٽ آھي جيڪو اٽڪل 10 سالن تائين ترقي ڪئي. ۽ اسان وٽ مختلف شاخون هيون. مخزن ۾ اسان وٽ هڪ شاخ هئي جنهن ۾ ڊولپر هلندا هئا. ۽ اتي ھڪڙو برانچ آھي جيڪو ڪوڊ جو نسخو ڏيکاري ٿو جيڪو پيداوار ۾ آھي.
پيداوار جي برانچ شاخ کان 3 مهينا پوئتي هئي جيڪا ڊولپرز وٽ موجود هئي. هن جو مطلب ڇا آهي؟ ان جو مطلب اهو آهي ته جيئن ئي مون وٽ ڪٿي ڪو بگ آهي جيڪو ڊولپرز جي غلطي جي ڪري پيداوار ڏانهن وڃي ٿو، ڇاڪاڻ ته انهن ان جي اجازت ڏني، ۽ QA جي غلطي جي ڪري، ڇاڪاڻ ته انهن ان کي ڏٺو، پوء هن جو مطلب اهو آهي ته جيڪڏهن مون کي حاصل ڪيو پيداوار لاءِ hotfix لاءِ ڪم، پوءِ مون کي 3 مهينا اڳ منهنجي ڪوڊ تبديلين کي واپس ڪرڻو پوندو. مون کي ياد ڪرڻو پوندو ته مون وٽ 3 مهينا اڳ ڇا هو ۽ ان کي درست ڪرڻ جي ڪوشش ڪريو.
جيڪڏهن توهان اڃا تائين اهو تجربو نه ڪيو آهي، توهان پنهنجي گهر جي منصوبي تي ڪوشش ڪري سگهو ٿا. مکيه شيء آهي، ان کي هڪ تجارتي تي ڪوشش نه ڪريو. ڪوڊ جون ٻه لائينون لکو، انھن جي باري ۾ ڇھن مھينن لاءِ وساريو، ۽ پوءِ واپس اچو ۽ جلدي وضاحت ڪرڻ جي ڪوشش ڪريو ته اھي ڪوڊ جون لائينون ڪھڙين بابت آھن ۽ توھان انھن کي ڪيئن درست ڪري سگھو ٿا يا بهتر ڪري سگھو ٿا. اهو هڪ تمام گهڻو، تمام دلچسپ تجربو آهي.
جيڪڏهن اسان وٽ هڪ مسلسل انٽيگريشن مشق آهي، ته پوءِ اهو اسان کي اجازت ڏئي ٿو ته ان کي ڪيترن ئي خودڪار اوزارن سان چيڪ ڪري سگھون هتي ۽ هينئر، جيئن ئي مون پنهنجو ڪوڊ لکيو آهي. اهو شايد مون کي مڪمل تصوير نه ڏئي، پر ان جي باوجود، اهو گهٽ ۾ گهٽ ڪجهه خطرن کي هٽائي ڇڏيندو. ۽ جيڪڏهن ڪو امڪاني بگ آهي، ته مان ان جي باري ۾ هينئر ئي ڄاڻندس، يعني لفظي طور تي چند منٽن ۾. مون کي 3 مهينا پوئتي موٽڻ جي ضرورت نه پوندي. مون کي صرف 2 منٽن کي واپس ڪرڻ جي ضرورت پوندي. هڪ سٺي ڪافي مشين وٽ 2 منٽن ۾ ڪافي پيئڻ جو وقت به نه هوندو، تنهنڪري اهو تمام سٺو آهي.
اهو قدر آهي ته اهو هر منصوبي تي وقت کان پوء بار بار ڪري سگهجي ٿو، يعني. نه صرف اهو جيڪو توهان ان کي سيٽ ڪيو آهي. توھان ٻئي عمل پاڻ کي ورجائي سگھو ٿا ۽ سي آءِ پاڻ کي ورجايو ويندو ھر نئين تبديليءَ لاءِ جيڪو توھان پروجيڪٽ ۾ ٺاھيو. اهو توهان کي وسيلن کي بهتر ڪرڻ جي اجازت ڏئي ٿو ڇو ته توهان جي ٽيم وڌيڪ موثر طريقي سان ڪم ڪري ٿي. توهان کي هاڻي اها صورتحال نه هوندي جتي توهان وٽ هڪ بگ اچي ان ڪوڊ مان جنهن سان توهان 3 مهينا اڳ ڪم ڪيو هو. توھان کي ھاڻي ڪانٽيڪٽ تبديل ڪرڻ جي ضرورت نه پوندي جڏھن توھان ويھي رھندؤ ۽ پھرين ٻن ڪلاڪن کي اھو سمجھڻ جي ڪوشش ۾ گذاريو ته پوءِ ڇا ٿيو ۽ توھان ڪجھھ کي درست ڪرڻ شروع ڪرڻ کان پھريائين سياق و سباق جي جوڙ ۾ وڃو.
اسان هن مشق جي ڪاميابي يا ناڪامي کي ڪيئن اندازو ڪري سگهون ٿا؟ جيڪڏهن توهان وڏي باس کي ٻڌايو ته اسان سي آءِ پروجيڪٽ تي ڇا لاڳو ڪيو آهي، هو ٻڌندو آهي بلاه بله. اسان ان تي عمل ڪيو، ٺيڪ، پر ڇو، اهو اسان وٽ ڇا کڻي آيو، اسان ان کي ڪيئن ماپون، اسان ان کي ڪيئن صحيح يا غلط طريقي سان لاڳو ڪري رهيا آهيون؟
پهريون اهو آهي ته، CI جي مهرباني، اسان وڌيڪ ۽ گهڻو ڪري ترتيب ڏئي سگهون ٿا، ۽ گهڻو ڪري خاص طور تي ڇاڪاڻ ته اسان جو ڪوڊ ممڪن طور تي وڌيڪ مستحڪم آهي. ساڳيءَ طرح، اسان جي غلطي کي ڳولڻ جو وقت گھٽجي ويندو آهي ۽ ان غلطي کي درست ڪرڻ جو وقت گھٽجي ويندو آهي ان ڪري جو اسان کي سسٽم کان جواب ملي ٿو هتي ۽ هن وقت، اسان جي ڪوڊ ۾ ڇا غلط آهي.
ٻيو عمل جيڪو اسان وٽ آهي آٽوميشن ٽيسٽنگ مشق، جيڪو اڪثر ڪري CI مشق سان گڏ اچي ٿو. اهي هٿ ۾ هٿ هلن ٿا.
هتي ڇا سمجهڻ ضروري آهي؟ اهو سمجهڻ ضروري آهي ته اسان جا امتحان مختلف آهن. ۽ هر خودڪار ٽيسٽ جو مقصد پنهنجي مسئلن کي حل ڪرڻ آهي. اسان وٽ آهن، مثال طور، يونٽ ٽيسٽ جيڪي اسان کي اجازت ڏين ٿا ماڊيول الڳ الڳ، يعني. اهو هڪ خلا ۾ ڪيئن ڪم ڪندو آهي؟ هي سٺو آهي.
اسان وٽ انٽيگريشن ٽيسٽ پڻ آهن جيڪي اسان کي اهو سمجهڻ جي اجازت ڏين ٿيون ته مختلف ماڊل هڪ ٻئي سان ڪيئن ضم ٿين ٿا. اهو پڻ سٺو آهي.
اسان وٽ ٿي سگھي ٿو UI آٽوميشن ٽيسٽ جيڪي اسان کي جانچڻ جي اجازت ڏين ٿيون ته UI سان ڪم ڪيتري حد تائين ڪسٽمر طرفان مقرر ڪيل خاص ضرورتن کي پورو ڪري ٿو، وغيره.
مخصوص ٽيسٽ جيڪي توهان هلائيندا آهن اهو متاثر ڪري سگهن ٿا ته توهان انهن کي ڪيترا ڀيرا هلائيندا آهيو. يونٽ جا امتحان عام طور تي ننڍا ۽ ننڍا لکيا ويندا آهن. ۽ اهي باقاعده شروع ڪري سگهجن ٿيون.
جيڪڏهن اسان UI آٽوميشن ٽيسٽ بابت ڳالهائي رهيا آهيون ، پوءِ اهو سٺو آهي جيڪڏهن توهان جو منصوبو ننڍڙو آهي. توهان جي UI آٽوميشن جا امتحان ڪجهه مناسب وقت وٺي سگهن ٿا. پر عام طور تي هڪ UI آٽوميشن ٽيسٽ اهو آهي جيڪو هڪ وڏي منصوبي تي ڪيترائي ڪلاڪ وٺندو آهي. ۽ اھو سٺو آھي جيڪڏھن اھو ڪجھ ڪلاڪ آھي. صرف اها آهي ته هر تعمير لاء انهن کي هلائڻ ۾ ڪو به مقصد ناهي. ان کي رات جي وقت هلائڻ جو مطلب آهي. ۽ جڏهن هرڪو صبح جو ڪم تي آيو: ٻئي ٽيسٽ ڪندڙ ۽ ڊولپر، انهن کي ڪجهه قسم جي رپورٽ ملي ٿي ته اسان رات جو UI آٽو ٽيسٽ ڪيو ۽ اهي نتيجا حاصل ڪيا. ۽ هتي، هڪ سرور جي ڪم جو هڪ ڪلاڪ جيڪو چيڪ ڪندو ته توهان جي پراڊڪٽ ڪجهه ضرورتن کي پورو ڪري ٿي، ساڳئي QA انجنيئر جي ڪم جي هڪ ڪلاڪ جي ڀيٽ ۾ تمام سستو هوندو، جيتوڻيڪ هو هڪ جونيئر QA انجنيئر آهي جيڪو کاڌي لاء ڪم ڪري ٿو ۽ مهرباني. سڀ ساڳي، مشين آپريشن جو هڪ ڪلاڪ سستو ٿيندو. اهو ڇو ته ان ۾ سيڙپڪاري ڪرڻ جو احساس آهي.
مون وٽ هڪ ٻيو منصوبو آهي جنهن تي آئون ڪم ڪري رهيو آهيان. اسان وٽ هن منصوبي تي ٻه هفتي اسپرنٽ هئا. پروجيڪٽ وڏو هو، مالياتي شعبي لاء اهم، ۽ هڪ غلطي نه ٿي سگهي. ۽ ٻن هفتن جي اسپرنٽ کان پوء، ترقي جي چڪر جي پٺيان هڪ جاچ واري عمل جي پٺيان هئي، جنهن ۾ 4 هفتا ٻيا لڳا. سانحي جي پيماني تي تصور ڪرڻ جي ڪوشش ڪريو. اسان ٻن هفتن لاءِ ڪوڊ لکون ٿا، پوءِ اسان ان کي الالا ڪوڊ فريز ڪريون ٿا، ان کي ايپليڪيشن جي نئين ورزن ۾ پيڪيج ڪريون، ۽ ان کي ٽيسٽ ڪندڙن تائين پهچايون. ٽيسٽ ڪندڙ ان کي 4 هفتن لاءِ آزمائيندا آهن، يعني جڏهن اهي ان جي جاچ ڪري رهيا آهن، اسان وٽ وقت آهي انهن لاء ٻه وڌيڪ نسخو تيار ڪرڻ لاء. هي واقعي افسوسناڪ ڪيس آهي.
۽ اسان انھن کي ٻڌايو ته جيڪڏھن توھان چاھيو ٿا وڌيڪ پيداواري، اھو سمجھ ۾ اچي ٿو توھان لاءِ پاڻمرادو ٽيسٽنگ عملن کي لاڳو ڪرڻ، ڇو ته اھو اھو آھي جيڪو توھان کي ھتي، ھاڻي تڪليف ڏئي ٿو.
مسلسل تعیناتي جي مشق ڪريو. عظيم، توهان تعمير ڪيو آهي. اهو اڳ ۾ ئي سٺو آهي. توهان جو ڪوڊ مرتب ڪيو آهي. هاڻي اهو سٺو لڳندو ته هن تعمير کي ڪجهه ماحول تي ترتيب ڏيو. اچو ته ڊولپرز لاء هڪ ماحول ۾.
اهو ڇو ضروري آهي؟ پهرين، توهان ڏسي سگهو ٿا ته توهان ڪيئن ڪامياب ٿي رهيا آهيو لڳائڻ واري عمل سان. مون کي اهڙا پروجيڪٽ مليا آهن، جڏهن مون پڇيو ته: ”توهان ايپليڪيشن جو نئون ورزن ڪيئن لڳايو؟“، ماڻهو مون کي ٻڌايو: ”اسان ان کي گڏ ڪري ان کي زپ آرڪائيو ۾ پيڪ ڪريون ٿا. اسان ان کي ميل ذريعي منتظم ڏانهن موڪليو. منتظم هن آرڪائيو کي ڊائون لوڊ ۽ وڌايو. ۽ سڄي آفيس دعا ڪرڻ لڳندي آهي ته سرور نئون ورزن کڻندو.
اچو ته ڪجھ سادو سان شروع ڪريون. مثال طور، اهي آرڪائيو ۾ CSS رکڻ وسري ويا يا جاوا اسڪرپٽ فائل جي نالي ۾ هيش ٽيگ کي تبديل ڪرڻ وساري ويٺا. ۽ جڏهن اسان سرور کي درخواست ڪريون ٿا، برائوزر سوچي ٿو ته هن وٽ اڳ ۾ ئي هي جاوا اسڪرپٽ فائل آهي ۽ ان کي ڊائون لوڊ نه ڪرڻ جو فيصلو ڪري ٿو. ۽ اتي هڪ پراڻو نسخو هو، ڪجهه غائب هو. عام طور تي، اتي ڪيترائي مسئلا ٿي سگهن ٿا. تنهن ڪري، مسلسل لڳائڻ جي مشق توهان کي گهٽ ۾ گهٽ جانچ ڪرڻ جي اجازت ڏئي ٿي ته ڇا ٿيندو جيڪڏهن توهان صاف ريفرنس تصوير ورتي ۽ ان کي مڪمل طور تي صاف نئين ماحول تي اپ لوڊ ڪيو. توهان ڏسي سگهو ٿا ته اهو ڪٿي آهي.
انهي سان گڏ، جڏهن توهان هڪ ٻئي جي وچ ۾ ڪوڊ ضم ڪيو، يعني. حڪم جي وچ ۾، هي توهان کي پڻ ڏسڻ جي اجازت ڏئي ٿو ته اهو UI تي ڪيئن ڏسڻ ۾ اچي ٿو.
ھڪڙو مسئلو آھي جيڪو ٿئي ٿو جتي گھڻن وينلا جاوا-اسڪرپٽ استعمال ڪيو ويندو آھي اھو آھي ته ٻن ڊولپرز جلدي طور تي ھڪڙي نالي سان ھڪڙي متغير جو اعلان ڪيو ونڊو اعتراض ۾. ۽ پوء، توهان جي قسمت تي منحصر آهي. جنهن جي جاوا اسڪرپٽ فائل کي ڪڍيو ويندو آهي ٻئي جي تبديلين کي اوور رائٽ ڪندو. اهو پڻ تمام دلچسپ آهي. توھان اندر اچو: ھڪڙي شيء ھڪڙي ماڻھوءَ لاءِ ڪم ڪري ٿي، ٻي شيءِ ٻئي لاءِ ڪم نٿي ڪري. ۽ اهو "شاندار" آهي جڏهن اهو سڀ ڪجهه پيداوار ۾ اچي ٿو.
اڳيون مشق جيڪو اسان وٽ آهي اهو آهي خودڪار بحالي جي مشق، يعني ايپليڪيشن جي پوئين ورزن ڏانهن واپس موٽڻ.
ڊولپرز لاءِ هي اهم ڇو آهي؟ اڃا به اهي آهن جن کي 90 واري ڏهاڪي جي دور جي ياد آهي، جڏهن ڪمپيوٽر وڏا هئا ۽ پروگرام ننڍا هئا. ۽ ويب ڊولپمينٽ جو واحد رستو PHP ذريعي هو. اهو نه آهي ته PHP هڪ خراب ٻولي آهي، جيتوڻيڪ اهو آهي.
پر مسئلو مختلف هو. جڏهن اسان پنهنجي php سائيٽ جو نئون ورزن لڳايو، اسان ان کي ڪيئن لڳايو؟ گهڻو ڪري اسان پري مئنيجر يا ٻيو ڪجهه کوليو. ۽ انهن فائلن کي ايف ٽي پي تي اپلوڊ ڪيو. ۽ اسان اوچتو محسوس ڪيو ته اسان وٽ ڪجهه ننڍڙو، ننڍڙو بگ آهي، مثال طور، اسان هڪ سيميڪولن رکڻ وساري ڇڏيو يا ڊيٽابيس لاء پاسورڊ تبديل ڪرڻ وساريو، ۽ ڊيٽابيس لاء هڪ پاسورڊ آهي، جيڪو مقامي ميزبان تي آهي. ۽ اسان فيصلو ڪيو ته فوري طور تي ايف ٽي پي سان ڳنڍڻ ۽ فائلن کي درست ڪريو. هي صرف باهه آهي! اهو آهي جيڪو 90s ۾ مشهور هو.
پر، جيڪڏهن توهان ڪئلينڊر تي نه ڏٺو آهي، 90s لڳ ڀڳ 30 سال اڳ هئا. هاڻي هر شيء ٿورو مختلف ٿي رهيو آهي. ۽ تصور ڪرڻ جي ڪوشش ڪريو سانحي جي پيماني تي جڏهن اهي توهان کي ٻڌائين ٿا: "اسان پيداوار تي مقرر ڪيو، پر اتي ڪجهه غلط ٿي ويو. هتي توهان جو ايف ٽي پي لاگ ان ۽ پاسورڊ آهي، پيداوار سان ڳنڍيو ۽ جلدي ان کي درست ڪريو. جيڪڏهن توهان چک نورس آهيو، اهو ڪم ڪندو. جيڪڏهن نه، ته پوءِ توهان کي خطرو آهي ته جيڪڏهن توهان هڪ بگ درست ڪيو ته توهان 10 وڌيڪ ڪندا. اهو ئي سبب آهي جو پوئين ورزن ڏانهن موٽڻ جو هي عمل توهان کي گهڻو ڪجهه حاصل ڪرڻ جي اجازت ڏئي ٿو.
ايستائين جو جيڪڏهن ڪا خراب شيءِ ڪنهن نه ڪنهن طريقي سان پيداوار ۾ اچي وئي ته پوءِ اها خراب آهي، پر موتمار ناهي. توھان واپس ڪري سگھوٿا پوئين ورزن ڏانھن جيڪو توھان وٽ آھي. ان کي ڪال ڪريو هڪ بيڪ اپ، جيڪڏهن اهو سمجهڻ آسان آهي انهي اصطلاح ۾. توهان هن پوئين ورزن ڏانهن واپس رول ڪري سگهو ٿا، ۽ صارفين اڃا تائين توهان جي پيداوار سان ڪم ڪرڻ جي قابل هوندا، ۽ توهان وٽ مناسب بفر وقت هوندو. توهان آرام سان ڪري سگهو ٿا، بغير جلدي، هي سڀ وٺو ۽ ان کي مقامي طور تي آزمايو، ان کي درست ڪريو، ۽ پوء نئون نسخو اپ لوڊ ڪريو. اهو حقيقت ۾ ائين ڪرڻ جو احساس آهي.
هاڻي اچو ته ڪوشش ڪريون ته ڪنهن نه ڪنهن طريقي سان ٻن پوئين عملن کي گڏ ڪريون. اسان هڪ ٽيون حاصل ڪنداسين جنهن کي رليز مئنيجمينٽ سڏيو ويندو.
جڏهن اسان ان جي ڪلاسيڪل شڪل ۾ مسلسل تعیناتي جي باري ۾ ڳالهايون ٿا، اسان چوندا آهيون ته اسان کي ذخيرو مان ڪنهن برانچ مان ڪوڊ ڪڍڻ گهرجي، ان کي گڏ ڪرڻ ۽ ان کي ترتيب ڏيڻ گهرجي. اهو سٺو آهي جيڪڏهن اسان وٽ ساڳيو ماحول آهي. جيڪڏهن اسان وٽ ڪيترائي ماحول آهن، ان جو مطلب اهو آهي ته اسان کي هر وقت ڪوڊ ڪڍڻو پوندو، جيتوڻيڪ ساڳئي ڪم کان. اسان ان کي هر ڀيري ٻاهر ڪڍنداسين، اسان ان کي هر ڀيري تعمير ڪنداسين ۽ ان کي نئين ماحول ۾ ترتيب ڏينداسين. پهرين، هي وقت آهي، ڇاڪاڻ ته هڪ منصوبو ٺاهڻ لاء، جيڪڏهن توهان وٽ وڏو آهي ۽ 90s کان آيو آهي، پوء اهو ڪيترائي ڪلاڪ وٺي سگھي ٿو.
ان کان علاوه هڪ ٻيو ڏک به آهي. جڏهن توهان تعمير ڪندا، ساڳي مشين تي به، توهان ساڳيا ذريعا ٺاهيندا، توهان اڃا تائين ڪا به ضمانت نه ڏني آهي ته هي مشين ساڳئي حالت ۾ آهي جيئن اها آخري تعمير دوران هئي.
اچو ته ڪو ماڻهو آيو ۽ توهان جي لاءِ DotNet کي اپڊيٽ ڪيو يا، ان جي ابتڙ، ڪنهن ڪنهن شيءِ کي ختم ڪرڻ جو فيصلو ڪيو. ۽ پوءِ توهان وٽ شعوري اختلاف آهي ته ٻه هفتا اڳ هن عزم کان اسان هڪ تعمير ٺاهي رهيا هئاسين ۽ سڀ ڪجهه ٺيڪ هو، پر هاڻي لڳي ٿو ته ساڳي مشين، ساڳيو ڪمٽ، ساڳيو ڪوڊ جيڪو اسان ٺاهڻ جي ڪوشش ڪري رهيا آهيون، پر اهو ڪم نه ڪري رهيو آهي. . توهان هڪ ڊگهي وقت تائين هن سان معاملو ڪيو ويندو ۽ اها حقيقت ناهي ته توهان ان کي سمجهندا. گهٽ ۾ گهٽ، توهان پنهنجي اعصاب کي تمام گهڻو خراب ڪنداسين.
تنهن ڪري، ريليز مئنيجمينٽ مشق هڪ اضافي تجريد متعارف ڪرائڻ جو مشورو ڏئي ٿو جنهن کي هڪ آرٽيڪل ريپوزٽري يا گيلري يا لائبريري سڏيو ويندو آهي. توهان ان کي سڏي سگهو ٿا جيڪو توهان چاهيو ٿا.
بنيادي خيال اهو آهي ته جيئن ئي اسان وٽ اتي ڪنهن قسم جو عزم آهي، چئو، هڪ برانچ ۾ جيڪو اسان پنهنجي مختلف ماحول ۾ ترتيب ڏيڻ لاء تيار آهيون، اسان هن ڪمٽ مان ايپليڪيشنون گڏ ڪريون ٿا ۽ هن ايپليڪيشن لاء هر شيء جي ضرورت آهي، اسان ان کي پيڪ ڪريون ٿا. زپ آرڪائيو ۾ ۽ ان کي محفوظ ڪريو ڪجهه قابل اعتماد اسٽوريج ۾. ۽ هن اسٽوريج مان اسان هي زپ آرڪائيو ڪنهن به وقت حاصل ڪري سگهون ٿا.
پوء اسان ان کي وٺي وٺو ۽ خودڪار طريقي سان ان کي ديو ماحول ۾ ترتيب ڏيو. اسان اتي ڊوڙون ٿا، ۽ جيڪڏهن سڀ ڪجهه سٺو آهي، ته پوء اسان اسٽيج تي پهچايو. جيڪڏهن سڀ ڪجهه ٺيڪ آهي، ته پوءِ اسان ساڳئي آرڪائيو کي پروڊڪشن تي لڳايو، ساڳيا بائنري، هڪ ڀيرو مرتب ڪيل.
اضافي طور تي، جڏهن اسان وٽ اهڙي گيلري آهي، اهو پڻ اسان جي مدد ڪري ٿي خطرن کي منهن ڏيڻ ۾ جيڪو اسان آخري سلائڊ تي خطاب ڪيو جڏهن اسان اڳئين ورزن ڏانهن رول بيڪ بابت ڳالهايو. جيڪڏهن توهان اتفاقي طور تي ڪجهه غلط ترتيب ڏني آهي، توهان هميشه هن گيلري مان ڪنهن ٻئي پوئين ورزن کي وٺي سگهو ٿا ۽ ساڳئي طريقي سان ان ماحول ۾ ان کي ختم ڪري سگهو ٿا. اهو توهان کي آساني سان پوئين ورزن ڏانهن واپس وڃڻ جي اجازت ڏئي ٿو جيڪڏهن ڪجهه غلط ٿي وڃي.
ٻيو وڏو عمل آهي. توهان ۽ مان سڀ سمجهون ٿا ته جڏهن اسان پنهنجي ايپليڪيشنن کي پوئين ورزن ڏانهن واپس آڻينداسين، ته ان جو مطلب اهو ٿي سگهي ٿو ته اسان کي به اڳئين ورزن جي انفراسٽرڪچر جي ضرورت آهي.
جڏهن اسان ورچوئل انفراسٽرڪچر جي باري ۾ ڳالهايون ٿا، ڪيترن ئي ماڻهن جو خيال آهي ته اهو ڪجهه آهي جيڪو منتظمين قائم ڪيو آهي. ۽ جيڪڏھن توھان کي ضرورت آھي، چئو، ھڪڙو نئون سرور حاصل ڪرڻ لاءِ جنھن تي توھان پنھنجي ايپليڪيشن جي نئين ورزن کي جانچڻ چاھيو ٿا، پوءِ توھان کي لازمي طور تي ايڊمن يا ڊيوپس ڏانھن ٽڪيٽ لکڻ گھرجي. ڊيوپس ان لاءِ 3 هفتا وٺندا. ۽ 3 هفتن کان پوءِ اهي توهان کي ٻڌائيندا ته اسان توهان جي لاءِ هڪ ورچوئل مشين نصب ڪئي آهي، جنهن ۾ هڪ ڪور، ٻه گيگا بائيٽ RAM ۽ هڪ ونڊوز سرور بغير DotNet جي. توهان چئو: "پر مون کي DotNet چاهيو." اهي: "ٺيڪ، 3 هفتن ۾ واپس اچو."
خيال اهو آهي ته انفراسٽرڪچر کي ڪوڊ جي مشقن طور استعمال ڪندي، توهان پنهنجي ورچوئل انفراسٽرڪچر کي صرف هڪ ٻيو وسيلو سمجهي سگهو ٿا.
ٿي سگهي ٿو، جيڪڏهن توهان مان ڪو به ڊاٽ نيٽ تي ايپليڪيشنون ڊولپمينٽ ڪري رهيو آهي، ته توهان شايد ڪنهن لائبريري بابت ٻڌو هوندو جنهن کي Entity Framework سڏيو ويندو آهي. ۽ توهان شايد اهو به ٻڌو هوندو ته اينٽيٽي فريم ورڪ انهن طريقن مان هڪ آهي جنهن کي Microsoft فعال طور تي زور ڏئي رهيو آهي. ڊيٽابيس سان ڪم ڪرڻ لاء، هي هڪ طريقو آهي جنهن کي ڪوڊ فرسٽ سڏيو ويندو آهي. اهو آهي جڏهن توهان ڪوڊ ۾ بيان ڪيو ٿا ته توهان ڪيئن چاهيو ٿا ته توهان جو ڊيٽابيس ڏسڻ لاء. ۽ پوء توهان ايپليڪيشن کي ترتيب ڏيو. اهو ڊيٽابيس سان ڳنڍيندو آهي، اهو پاڻ طئي ڪري ٿو ته ڪهڙيون ٽيبلون آهن ۽ ڪهڙيون ٽيبلون نه آهن، ۽ هر شيءِ ٺاهي ٿو جيڪا توهان کي گهربل آهي.
توهان پنهنجي زيربناء سان ساڳيو ڪم ڪري سگهو ٿا. ان وچ ۾ ڪو به فرق نه آهي ته ڇا توهان کي ڪنهن منصوبي لاءِ ڊيٽابيس جي ضرورت آهي يا ڇا توهان کي پروجيڪٽ لاءِ ونڊوز سرور جي ضرورت آهي. اهو صرف هڪ وسيلو آهي. ۽ توهان هن وسيلن جي تخليق کي خودڪار ڪري سگهو ٿا، توهان هن وسيلن جي ترتيب کي خودڪار ڪري سگهو ٿا. ان جي مطابق، هر ڀيري توهان ڪجهه نئين تصور، ڪجهه نئين طريقي جي جانچ ڪرڻ چاهيو ٿا، توهان کي ڊيوپس ڏانهن ٽڪيٽ لکڻ جي ضرورت نه هوندي، توهان صرف پنهنجي لاء هڪ الڳ انفراسٽرڪچر تيار ڪري سگهو ٿا تيار ڪيل ٽيمپليٽس مان، تيار ڪيل اسڪرپٽ مان ۽ ان کي لاڳو ڪريو. اتي توهان جا سڀئي تجربا آهن. توھان ھن کي ختم ڪري سگھو ٿا، ڪجھ نتيجا حاصل ڪريو ۽ ان بابت وڌيڪ رپورٽ ڪريو.
ايندڙ مشق، جيڪا پڻ موجود آهي ۽ پڻ اهم آهي، پر جنهن کي ڪجهه ماڻهو استعمال ڪن ٿا، اهو آهي ايپليڪيشن پرفارمنس مانيٽرنگ.
مان ايپليڪيشن پرفارمنس مانيٽرنگ بابت صرف هڪ شيءِ چوڻ چاهيان ٿو. هن مشق جي باري ۾ سڀ کان اهم ڇا آهي؟ اھو آھي جيڪو ايپليڪيشن پرفارمنس مانيٽرنگ ھڪڙي اپارٽمنٽ جي مرمت وانگر آھي. اها ڪا حتمي حالت ناهي، اهو هڪ عمل آهي. توهان کي اهو باقاعده ڪرڻو پوندو.
سٺي طريقي سان، اهو لڳ ڀڳ هر تعمير تي ايپليڪيشن پرفارمنس مانيٽرنگ ڪرڻ سٺو هوندو، جيتوڻيڪ، جيئن توهان سمجھو ٿا، اهو هميشه ممڪن ناهي. پر، گهٽ ۾ گهٽ، هر رليز لاءِ ان کي انجام ڏيڻ جي ضرورت آهي.
اهو ڇو ضروري آهي؟ ڇو ته جيڪڏهن توهان اوچتو ڪارڪردگي ۾ گهٽتائي جو تجربو ڪيو، ته توهان کي واضح طور تي سمجهڻ جي ضرورت آهي ڇو. جيڪڏهن توهان جي ٽيم وٽ آهي، چئو، ٻه هفتا اسپرنٽ، ته پوءِ گهٽ ۾ گهٽ هر ٻن هفتن ۾ هڪ ڀيرو توهان کي پنهنجي ايپليڪيشن کي ڪجهه الڳ سرور تي لڳائڻ گهرجي، جتي توهان وٽ واضح طور تي مقرر ٿيل پروسيسر، ريم، ڊسڪ وغيره آهن ۽ اهي ساڳيا ڪارڪردگي جا امتحان هلائيندا. . توھان کي نتيجو ملندو. ڏسو ته اهو ڪيئن بدلجي ويو آهي پوئين اسپرنٽ کان.
۽ جيڪڏهن توهان کي اهو معلوم ٿئي ٿو ته ڊرائوڊ تيزيءَ سان ڪنهن هنڌ هيٺ ٿي ويو، ان جو مطلب اهو ٿيندو ته اهو صرف انهن تبديلين جي ڪري هو، جيڪي گذريل ٻن هفتن ۾ ٿي رهيون آهن. اهو توهان کي وڌيڪ تيزيء سان مسئلو جي سڃاڻپ ۽ حل ڪرڻ جي اجازت ڏيندو. ۽ ٻيهر، اهي تقريبن ساڳيا ميٽرڪ آهن جن جي ذريعي توهان اندازو لڳائي سگهو ٿا ته توهان ڪيتري ڪاميابي سان ڪيو.
اسان وٽ ايندڙ مشق آهي ڪنفيگريشن مئنيجمينٽ مشق. تمام ٿورا آهن جيڪي هن کي سنجيده وٺن ٿا. پر مون کي يقين ڪر، اهو اصل ۾ هڪ تمام سنجيده شيء آهي.
تازو هڪ مزاحيه ڪهاڻي هئي. اهي ماڻهو مون وٽ آيا ۽ چيائون: ”اسان جي درخواست جو سيڪيورٽي آڊٽ ڪرائڻ ۾ مدد ڪريو. اسان ڪافي دير تائين ڪوڊ کي گڏ ڏٺو، انهن مون کي ايپليڪيشن بابت ٻڌايو، ڊراگرام ٺاهيا. ۽ پلس يا مائنس سڀ ڪجهه منطقي، سمجھڻ وارو، محفوظ هو، پر اتي ھڪڙو ھو! انهن وٽ پنهنجي ماخذ ڪنٽرول ۾ ڪنفيگريشن فائلون هيون، جن ۾ IP ڊيٽابيس جي پيداوار کان وٺي، انهن ڊيٽابيس سان ڳنڍڻ لاءِ لاگ ان ۽ پاسورڊ وغيره شامل آهن.
۽ مان چوان ٿو: ”يار، ٺيڪ آهي، توهان پنهنجي پيداوار واري ماحول کي فائر وال سان بند ڪري ڇڏيو آهي، پر حقيقت اها آهي ته توهان وٽ پروڊڪشن ڊيٽابيس لاءِ لاگ ان ۽ پاسورڊ صحيح سورس ڪنٽرول ۾ آهي ۽ ڪو به ڊولپر ان کي پڙهي سگهي ٿو اڳ ۾ ئي هڪ وڏو سيڪيورٽي خطرو آهي. . ۽ ڪابه ڳالهه نه آهي ته توهان جي ايپليڪيشن ڪوڊ جي نقطي نظر کان ڪيترو محفوظ آهي، جيڪڏهن توهان ان کي ماخذ ڪنٽرول ۾ ڇڏي ڏيو، ته پوء توهان ڪڏهن به ڪٿي به ڪنهن به آڊٽ پاس نه ڪندا." اھا ڳالھھ آھي مان ان جي باري ۾.
ترتيب ڏيڻ جو انتظام. اسان وٽ مختلف ماحول ۾ مختلف ترتيبون ٿي سگھي ٿي. مثال طور، اسان وٽ مختلف لاگ ان ۽ پاسورڊ موجود هوندا ڊيٽابيس لاءِ QA، ڊيمو، پيداواري ماحول وغيره.
هي ترتيب پڻ خودڪار ٿي سگهي ٿو. اهو هميشه ايپليڪيشن کان الڳ هجڻ گهرجي. ڇو؟ ڇو ته توهان هڪ ڀيرو ايپليڪيشن ٺاهي، ۽ پوءِ ايپليڪيشن کي پرواه ناهي ته ڇا توهان SQL سرور سان ڳنڍيندا آهيو اهڙي ۽ اهڙي IP يا اهڙي ۽ اهڙي IP ذريعي، اهو ساڳيو ڪم ڪرڻ گهرجي. تنهن ڪري، جيڪڏهن اوچتو توهان مان ڪو اڃا تائين ڪوڊ ۾ ڪنيڪشن اسٽرنگ کي هارڊ ڪوڊ ڪري رهيو آهي، پوء ياد رکو ته مان توهان کي ڳوليندس ۽ توهان کي سزا ڏيندس جيڪڏهن توهان پاڻ کي مون سان گڏ ساڳئي منصوبي تي ڳوليندا. اهو هميشه هڪ الڳ ترتيب ۾ رکيل آهي، مثال طور، web.config ۾.
۽ هي ترتيب اڳ ۾ ئي الڳ الڳ منظم ٿيل آهي، يعني اهو ئي لمحو آهي جڏهن هڪ ڊولپر ۽ منتظم اچي سگهن ٿا ۽ ساڳئي ڪمري ۾ ويٺا آهن. ۽ ڊولپر چئي سگھي ٿو: "ڏس، ھتي آھن منھنجي ايپليڪيشن جا بائنري. اهي ڪم ڪن ٿا. ايپليڪيشن کي ڪم ڪرڻ لاءِ ڊيٽابيس جي ضرورت آهي. هتي بائنري جي اڳيان هڪ فائل آهي. هن فائل ۾، هي فيلڊ لاگ ان لاء ذميوار آهي، هي پاسورڊ لاء آهي، هي IP لاء آهي. ان کي ڪٿي به لڳايو“. ۽ اھو سادو ۽ منتظم لاءِ صاف آھي. هو هن ترتيب کي منظم ڪندي واقعي ڪٿي به ترتيب ڏئي سگهي ٿو.
۽ آخري مشق جنهن بابت مان ڳالهائڻ چاهيان ٿو اهو هڪ مشق آهي جيڪو تمام گهڻو، ڪڪر سان لاڳاپيل آهي. ۽ اھو وڌ ۾ وڌ اثر آڻيندو جيڪڏھن توھان بادل ۾ ڪم ڪريو. هي توهان جي ماحول جي خودڪار هٽائڻ آهي.
مون کي خبر آهي ته هن ڪانفرنس ۾ ڪيترائي ماڻهو آهن جن ٽيمن سان آئون ڪم ڪريان ٿو. ۽ سڀني ٽيمن سان گڏ آئون ڪم ڪريان ٿو، اسان هن مشق کي استعمال ڪندا آهيون.
ڇو؟ يقينا، اهو تمام سٺو هوندو جيڪڏهن هر ڊولپر وٽ هڪ مجازي مشين هجي جيڪا 24/7 ڪم ڪندي. پر شايد اهو توهان لاءِ خبر آهي، شايد توهان ڌيان نه ڏنو، پر ڊولپر پاڻ 24/7 ڪم نٿو ڪري. هڪ ڊولپر عام طور تي ڪم ڪري ٿو 8 ڪلاڪ هڪ ڏينهن. جيتوڻيڪ هو جلدي ڪم تي اچي ٿو، هن کي هڪ وڏو لنچ آهي جنهن دوران هو جم ڏانهن ويندو آهي. اچو ته 12 ڪلاڪ هڪ ڏينهن ۾ جڏهن ڊولپر اصل ۾ اهي وسيلن کي استعمال ڪري ٿو. اسان جي قانون موجب، اسان وٽ هفتي ۾ 5 مان 7 ڏينهن آهن جيڪي ڪم ڪندڙ ڏينهن سمجهيا وڃن ٿا.
ان حساب سان، هفتي جي ڏينهن تي هن مشين کي 24 ڪلاڪ ڪم نه ڪرڻ گهرجي، پر صرف 12، ۽ هفتي جي آخر ۾ هن مشين کي ڪم نه ڪرڻ گهرجي. اهو لڳي ٿو ته هر شيء بلڪل سادو آهي، پر هتي ڇا چوڻ ضروري آهي؟ هن بنيادي شيڊول تي هن سادي عمل کي لاڳو ڪرڻ سان، اهو توهان کي انهن ماحوليات کي برقرار رکڻ جي قيمت کي 70٪ گھٽائڻ جي اجازت ڏئي ٿو، يعني توهان پنهنجي ديو، QA، ڊيمو، ماحول جي قيمت ورتي ۽ ان کي 3 ذريعي ورهايو.
سوال اهو آهي ته باقي پئسن جو ڇا ڪجي؟ مثال طور، ڊولپرز کي خريد ڪرڻ گهرجي ReSharper جيڪڏهن اهي پهريان ئي نه آهن. يا ڪاڪٽيل پارٽي ڪريو. جيڪڏهن توهان وٽ اڳ ۾ هڪ ماحول هوندو هو جنهن ۾ dev ۽ QA ٻئي چرندا هئا، ۽ اهو ئي آهي، هاڻي توهان 3 مختلف ٺاهي سگهو ٿا جيڪي الڳ ٿي ويندا، ۽ ماڻهو هڪ ٻئي سان مداخلت نه ڪندا.
مسلسل ڪارڪردگي جي ماپ سان سلائيڊ جي حوالي سان، اسان ڪيئن ڪارڪردگي جو مقابلو ڪري سگهون ٿا جيڪڏهن اسان وٽ منصوبي ۾ ڊيٽابيس ۾ 1 رڪارڊ هئا، ٻن مهينن بعد هڪ ملين آهن؟ ڪيئن سمجھجي ڇو ۽ ڪارڪردگي کي ماپڻ جو مقصد ڇا آھي؟
اهو هڪ سٺو سوال آهي، ڇو ته توهان کي هميشه ساڳئي وسيلن تي ڪارڪردگي کي ماپڻ گهرجي. اھو آھي، توھان نئون ڪوڊ ٺاھيو ٿا، توھان نئين ڪوڊ تي ڪارڪردگي کي ماپو ٿا. مثال طور، توهان کي مختلف ڪارڪردگي جي منظرنامي کي جانچڻ جي ضرورت آهي، اچو ته توهان اهو جانچڻ چاهيو ٿا ته ايپليڪيشن هلڪي لوڊ تي ڪيئن ڪم ڪري ٿي، جتي 1 استعمال ڪندڙ آهن ۽ ڊيٽابيس جي سائيز 000 گيگا بائيٽ آهي. توهان ان کي ماپ ڪيو ۽ نمبر حاصل ڪيو. اڳتي هلي اسان هڪ ٻيو منظر وٺون ٿا. مثال طور، 5 استعمال ڪندڙ، ڊيٽابيس جي سائيز 5 terabyte. اسان نتيجن کي حاصل ڪيو ۽ انهن کي ياد ڪيو.
هتي ڇا ضروري آهي؟ هتي اهم شيء اها آهي ته منظرنامي تي منحصر آهي، ڊيٽا جي مقدار، هڪ ئي وقت استعمال ڪندڙن جو تعداد، وغيره، توهان ڪجهه حدن ۾ هلائي سگهو ٿا. مثال طور، نيٽ ورڪ ڪارڊ جي حد تائين، يا هارڊ ڊرائيو جي حد تائين، يا پروسيسر جي صلاحيتن جي حد تائين. اھو اھو آھي جيڪو توھان لاءِ سمجھڻ ضروري آھي. مختلف حالتن ۾ توهان ڪجهه حدن ۾ هلندا آهيو. ۽ توهان کي انگن کي سمجهڻ جي ضرورت آهي جڏهن توهان انهن کي ماريو.
ڇا اسان خاص ٽيسٽ ماحول ۾ ڪارڪردگي کي ماپڻ بابت ڳالهائي رهيا آهيون؟ اهو آهي، هي پيداوار نه آهي؟
ها، هي پيداوار نه آهي، هي هڪ آزمائشي ماحول آهي، جيڪو هميشه ساڳيو هوندو آهي ته جيئن توهان ان کي اڳئين ماپن سان مقابلو ڪري سگهو ٿا.
سمجھي ويو مھرباني!
جيڪڏهن ڪو سوال نه آهي، منهنجو خيال آهي ته اسان ختم ڪري سگهون ٿا. تنهنجي مهرباني!
جو ذريعو: www.habr.com