ڪورس جي شاگردن لاءِ تيار ڪيل مضمون جو ترجمو "DevOps طريقا ۽ اوزار" OTUS تعليمي منصوبي ۾.

توهان کي هڪ monorepository چونڊڻ گهرجي ڇو ته اهو رويو جيڪو توهان جي ٽيمن ۾ فروغ ڏئي ٿو شفافيت ۽ گڏيل ذميواري آهي، خاص طور تي جيئن ٽيمون وڌنديون آهن. ڪنهن به صورت ۾، توهان کي ٽولنگ ۾ سيڙپڪاري ڪرڻو پوندو، پر اهو هميشه بهتر آهي جيڪڏهن ڊفالٽ رويي اهو آهي جيڪو توهان پنهنجي حڪمن ۾ چاهيو ٿا.

اسان هن بابت ڇو ڳالهائي رهيا آهيون؟

Matt Klein مضمون لکيو "Monorepos: مهرباني ڪري نه ڪريو!"  (مترجم جو نوٽ: ترجمي تي Habré "مونورپوزٽريز: مهرباني ڪري نه ڪريو"). مون کي Matt پسند آهي، مان سمجهان ٿو ته هو تمام هوشيار آهي ۽ توهان کي سندس نقطه نظر پڙهڻ گهرجي. هن اصل ۾ Twitter تي پول پوسٽ ڪيو:

ترجمو:
هي نئون سال جو ڏينهن، مان بحث ڪرڻ وارو آهيان ته ڪيئن مضحکہ خیز monorepositories آهن. 2019 خاموشي سان شروع ٿيو. انهي جي روح ۾، مان توهان کي هڪ سروي پيش ڪريان ٿو. ڪير آهن وڏا پرستار؟ حمايتي:
- مونورپو
- زنگ
- غلط راءِ / ٻئي

منهنجو جواب هو، "مان لفظي طور تي اهي ٻئي ماڻهو آهيان." ان جي باري ۾ ڳالهائڻ جي بدران ته ڪيئن مورچا هڪ دوا آهي، اچو ته ڏسو ته ڇو مون سوچيو ته هو مونورپوزيٽريز بابت غلط آهي. پنهنجي باري ۾ ٿورڙو. مان شيف سافٽ ويئر جو CTO آهيان. اسان وٽ اٽڪل 100 انجنيئر آهن، هڪ ڪوڊ جو بنياد 11-12 سالن جي باري ۾، ۽ 4 مکيه پراڊڪٽس. ھن ڪوڊ مان ڪجھ ھڪڙو پولي ريپوزٽوري ۾ آھي (منھنجي شروعاتي پوزيشن)، ڪجھ ھڪڙي monorepository ۾ آھي (منھنجي موجوده پوزيشن).

ان کان اڳ جو آئون شروع ڪريان: هر دليل جيڪو آئون هتي ڏيان ٿو ٻنهي قسمن جي مخزن تي لاڳو ٿيندو. منهنجي خيال ۾، ڪو به ٽيڪنيڪل سبب ناهي ته توهان کي هڪ قسم جي مخزن کي ٻئي مٿان چونڊڻ گهرجي. توهان ڪنهن به طريقي سان ڪم ڪري سگهو ٿا. مان ان بابت ڳالهائڻ ۾ خوش آهيان، پر مون کي مصنوعي فني سببن ۾ دلچسپي نه آهي ڇو ته هڪ ٻئي کان اعلي آهي.

مان Matt جي نقطي جي پهرين حصي سان متفق آهيان:

ڇاڪاڻ ته پيماني تي، هڪ monorepository اهي سڀئي مسئلا حل ڪندي جيڪي هڪ polyrepository حل ڪري ٿي، پر ساڳئي وقت توهان کي توهان جي ڪوڊ کي مضبوط ڪرڻ لاء مجبور ڪرڻ ۽ توهان جي ورزن ڪنٽرول سسٽم جي اسپيبلبل کي وڌائڻ لاء ناقابل اعتماد ڪوششن جي ضرورت آهي.

توهان کي ساڳيا مسئلا حل ڪرڻا پوندا قطع نظر ته توهان هڪ monorepository يا هڪ polyrepository چونڊيو. توهان ڪيئن رليز جاري ڪندا؟ تازه ڪاري لاء توهان جو ڪهڙو طريقو آهي؟ پسمانده مطابقت؟ ڪراس پروجيڪٽ انحصار؟ ڪهڙا تعميراتي انداز قابل قبول آهن؟ توهان پنهنجي تعمير ۽ ٽيسٽ انفراسٽرڪچر کي ڪيئن منظم ڪندا آهيو؟ فهرست لامحدود آهي. ۽ توھان انھن سڀني کي حل ڪنداسين جيئن توھان وڌو. ڪو به مفت پنير ناهي.

منهنجو خيال آهي ته Matt جو دليل ڪيترن ئي انجنيئرن (۽ مئنيجرن) پاران حصيداري ڪيل خيالن سان ملندڙ جلندڙ آهي جنهن جو آئون احترام ڪريان ٿو. اهو انجينيئر جي نقطه نظر کان ٿئي ٿو جيڪو جزو تي ڪم ڪري رهيو آهي يا جزو تي ڪم ڪندڙ ٽيم. توهان اهڙيون شيون ٻڌو ٿا:

• ڪوڊ بيس وڏو آهي - مون کي اهو سڀ فضول ضرورت ناهي.
• اهو امتحان ڪرڻ ڏکيو آهي ڇو ته مون کي اهو سڀ فضول جانچڻو آهي جنهن جي مون کي ضرورت ناهي.
• بيروني انحصار سان ڪم ڪرڻ وڌيڪ ڏکيو آهي.
• مون کي پنهنجي ورچوئل ورچوئل ڪنٽرول سسٽم جي ضرورت آهي.

يقينن، اهي سڀئي نقطا جائز آهن. اهو ٻنهي صورتن ۾ ٿئي ٿو - پولي ريپوزٽري ۾ مون وٽ پنهنجو پنهنجو فضول آهي، ان کان علاوه جيڪو بلڊنگ لاءِ گهربل آهي... شايد مون کي ٻين فضول جي به ضرورت هجي. تنهن ڪري مان "بس" اوزار ٺاهي ٿو جيڪي پوري منصوبي کي چيڪ ڪن ٿا. يا مان ٺاهيان ٿو جعلي monorepository submodules سان. اسان سڄو ڏينهن ان جي چوڌاري گھمندا هئاسين. پر مان سمجهان ٿو ته ميٽ جي دليل کي بنيادي سبب ياد اچي ٿو، جنهن مان مونورپوزٽوري جي حق ۾ تمام گهڻو ڦيرايو ويو آهي:

اهو رابطو پيدا ڪري ٿو ۽ مسئلا ڏيکاري ٿو

جڏهن اسان ذخيرا الڳ ڪريون ٿا، اسان هڪ حقيقي مسئلو پيدا ڪريون ٿا ڪوآرڊينيشن ۽ شفافيت. اهو انهي طريقي سان ملندو آهي جنهن سان اسان ٽيمن بابت سوچيو ٿا (خاص طور تي انفرادي ميمبر انهن بابت سوچين ٿا): اسان هڪ خاص جزو جا ذميوار آهيون. اسان تعلقي اڪيلائي ۾ ڪم ڪريون ٿا. حدون مقرر ٿيل آهن منهنجي ٽيم ۽ جز(جنهن) تي جن تي اسان ڪم ڪري رهيا آهيون.

جيئن ته فن تعمير وڌيڪ پيچيده ٿي ويندو آهي، هڪ ٽيم هاڻي ان کي اڪيلو منظم نٿو ڪري سگهي. تمام ٿورا انجنيئرن وٽ سمورو نظام سندن سر ۾ آھي. اچو ته چئو ته توهان هڪ گڏيل جزو A جو انتظام ڪريو جيڪو ٽيم B، C، ۽ D پاران استعمال ڪيو ويندو آهي. ٽيم A کي ريفيڪٽر ڪري رهيو آهي، API کي بهتر ڪري رهيو آهي، ۽ اندروني عمل درآمد کي پڻ تبديل ڪري رهيو آهي. نتيجي طور، تبديليون پوئتي موٽڻ سان مطابقت نه آهن. توهان کي ڪهڙي صلاح آهي؟

• سڀ جڳھون ڳولھيو جتي پراڻي API استعمال ٿيل آھي.
• ڇا اھي جڳھون آھن جتي نئون API استعمال نٿو ڪري سگھجي؟
• ڇا توھان درست ڪري سگھوٿا ۽ جانچ ڪري سگھوٿا ٻين اجزاء کي يقيني بڻائڻ لاءِ ته اھي ٽوڙي نه سگھندا؟
• ڇا اهي ٽيمون توهان جي تبديلين جي جانچ ڪري سگهن ٿيون؟

مهرباني ڪري نوٽ ڪريو ته اهي سوال مخزن جي قسم کان آزاد آهن. توهان کي B، C ۽ D ٽيمون ڳولڻ جي ضرورت پوندي. توهان کي انهن سان ڳالهائڻو پوندو، وقت معلوم ڪرڻ، انهن جي ترجيحن کي سمجهڻ جي ضرورت پوندي. گهٽ ۾ گهٽ اسان کي اميد آهي ته توهان ڪندا.

ڪو به واقعي اهو ڪرڻ نٿو چاهي. اهو تمام گهٽ مزو آهي صرف لات API کي درست ڪرڻ کان. اهو سڀ انسان ۽ گندو آهي. هڪ polyrepository ۾، توهان آساني سان تبديليون ڪري سگهو ٿا، انهن ماڻهن کي ڏيو جيڪي ان جزو تي ڪم ڪري رهيا آهن (شايد نه B، C يا D) جائزو وٺڻ لاء، ۽ اڳتي وڌو. ٽيمون بي، سي ۽ ڊي صرف ھاڻي پنھنجي موجوده ورزن سان رھي سگھن ٿيون. اهي تجديد ڪيا ويندا جڏهن اهي توهان جي باصلاحيت کي محسوس ڪندا!

هڪ monorepository ۾، ذميواري ڊفالٽ طور تي منتقل ڪيو ويو آهي. ٽيم A پنهنجو حصو تبديل ڪري ٿي ۽، جيڪڏهن محتاط نه هجي ته، فوري طور تي B، C ۽ D کي ٽوڙي ڇڏيندي آهي. اهو B، C ۽ D A جي دروازي تي ڏيکاريندو آهي، حيران ٿي ويندو آهي ته ٽيم A اسيمبلي کي ڇو ٽوڙيو. هي A سيکاري ٿو ته اهي مٿي ڏنل منهنجي فهرست کي ڇڏي نٿا سگهن. انهن کي ڳالهائڻ گهرجي ته اهي ڇا ڪرڻ وارا آهن. ڇا B، C ۽ D منتقل ٿي سگھي ٿو؟ ڇا ٿي سگھي ٿو B ۽ C ڪري سگھي ٿو، پر ڊي پراڻي الگورتھم جي رويي جي ھڪڙي پاسي واري اثر سان ويجھي سان لاڳاپيل ھو؟

پوءِ اسان کي ڳالهائڻو پوندو ته اسان هن صورتحال مان ڪيئن نڪرنداسين:

1. گھڻن اندروني APIs لاءِ سپورٽ، ۽ پراڻي الگورٿم کي ختم ٿيل طور نشان لڳايو جيستائين D ان کي استعمال ڪرڻ بند ڪري.
2. گھڻن رليز ورزن لاءِ سپورٽ، ھڪڙي پراڻي انٽرفيس سان، ھڪڙي نئين سان.
3. A جي تبديلين کي جاري ڪرڻ ۾ دير ڪريو جيستائين B، C ۽ D ان کي هڪ ئي وقت قبول ڪري سگھن.

اچو ته چئو ته اسان چونڊيو آهي 1، ڪيترائي APIs. انهي حالت ۾ اسان وٽ ڪوڊ جا ٻه ٽڪرا آهن. پراڻي ۽ نئين. ڪجهه حالتن ۾ ڪافي آسان. اسان پراڻي ڪوڊ کي واپس چيڪ ڪريون ٿا، ان کي ختم ڪرڻ جي طور تي نشان لڳايو، ۽ D ٽيم سان لازمي طور تي پولي ۽ مونو ريپوزٽريز لاءِ هڪجهڙائي تي متفق آهيون.

ڪيترن ئي نسخن کي ڇڏڻ لاء، اسان کي هڪ شاخ جي ضرورت آهي. هاڻي اسان وٽ ٻه حصا آهن - A1 ۽ A2. ٽيمون B ۽ C A2 استعمال ڪن ٿيون ۽ D A1 استعمال ڪن ٿيون. اسان کي هر جزو کي ڇڏڻ جي لاءِ تيار ٿيڻ جي ضرورت آهي ڇو ته سيڪيورٽي اپڊيٽس ۽ ٻيون بگ فيڪس گهربل هوندا ان کان اڳ جو D اڳتي هلي سگهي. هڪ polyrepository ۾، اسان هن کي لڪائي سگهون ٿا هڪ ڊگهي برانچ ۾ جيڪو سٺو محسوس ٿئي ٿو. هڪ monorepository ۾، اسان ڪوڊ کي مجبور ڪريون ٿا نئين ماڊل ۾ ٺاهيو وڃي. ٽيم ڊي کي اڃا تائين "پراڻي" جزو ۾ تبديليون ڪرڻيون پونديون. هر ڪو ڏسي سگهي ٿو قيمت جيڪا اسان ادا ڪري رهيا آهيون هتي - اسان وٽ هاڻي ٻه ڀيرا وڌيڪ ڪوڊ آهي، ۽ ڪو به بگ فيڪس جيڪي A1 ۽ A2 تي لاڳو ٿين ٿا انهن ٻنهي تي لاڳو ٿيڻ گهرجن. هڪ polyrepository ۾ برانچنگ جي طريقي سان، هي چيري-چونڊ جي پويان لڪيل آهي. اسان قيمت کي گهٽ سمجهون ٿا ڇاڪاڻ ته ڪو به نقل نه آهي. عملي نقطي نظر کان، قيمت ساڳي آهي: توهان ٺاهيندا، جاري ڪندا، ۽ برقرار رکندا ٻه وڏا هڪجهڙا ڪوڊ بيس جيستائين توهان انهن مان هڪ کي حذف نه ڪري سگهو. فرق اهو آهي ته هڪ monorepository سان اهو درد سڌو ۽ ظاهر آهي. اهو اڃا به خراب آهي، ۽ اهو سٺو آهي.

آخرڪار، اسان ٽئين نقطي تي پهچي ويا. ڇڏڻ ۾ دير. اهو ممڪن آهي ته A پاران ڪيل تبديليون ٽيم A جي زندگين کي بهتر بڻائي سگهندي. اهم، پر تڪڙو نه. ڇا اسان صرف دير ڪري سگهون ٿا؟ هڪ polyrepository ۾، اسان هن کي ڇڪيندا آهيون آرٽيڪل کي پن ڪرڻ لاءِ. يقيناً اسان ٽيم ڊي کي اهو ٻڌائي رهيا آهيون. بس پراڻي ورزن تي رهو جيستائين توهان پڪڙي نه وڃو! هي توهان کي بزدل کيڏڻ لاءِ سيٽ ڪري ٿو. ٽيم A پنهنجي جزو تي ڪم ڪرڻ جاري رکي، حقيقت کي نظر انداز ڪندي ته ٽيم ڊي استعمال ڪري رهي آهي هڪ پراڻو نسخو (جيڪو ٽيم ڊي جو مسئلو آهي، اهي بيوقوف آهن). ان کان علاوه، ٽيم ڊي ٽيم A جي بي پرواهه رويي بابت ڪوڊ جي استحڪام بابت خراب ڳالهائيندو آهي، جيڪڏهن اهي ان بابت ڳالهائي رهيا آهن. مهينا گذري ويا. آخرڪار، ٽيم ڊي کي اپڊيٽ ڪرڻ جي امڪان کي ڏسڻ جو فيصلو ڪيو، پر A ۾ صرف وڌيڪ تبديليون آهن. ٽيم A کي مشڪل سان ياد آهي جڏهن يا ڪيئن انهن ڊي کي ٽوڙيو. اپ گريڊ وڌيڪ ڏکوئيندڙ آهي ۽ وڌيڪ وقت وٺندو. جيڪو ان کي ترجيحي اسٽيڪ کي وڌيڪ ھيٺ موڪلي ٿو. ايستائين جو اسان وٽ اي ۾ سيڪيورٽي جو مسئلو آهي جيڪو اسان کي برانچ ٺاهڻ تي مجبور ڪري ٿو. ٽيم A کي وقت ۾ واپس وڃڻ گهرجي، هڪ نقطو ڳوليو جڏهن D مستحڪم هجي، اتي مسئلو حل ڪريو، ۽ ان کي ڇڏڻ لاءِ تيار ڪريو. هي حقيقي انتخاب آهي جيڪو ماڻهو ٺاهيندا آهن، ۽ اهو تمام گهڻو بدترين آهي. اهو لڳي ٿو ته ٽيم اي ۽ ٽيم ڊي ٻنهي لاء سٺو آهي جيستائين اسان هڪ ٻئي کي نظر انداز ڪري سگهون ٿا.

هڪ monorepository ۾، ٽيون واقعي هڪ اختيار نه آهي. توھان مجبور آھيو صورتحال کي ٻن طريقن مان ھڪڙي سان ڊيل ڪرڻ لاءِ. توھان کي ڏسڻ جي ضرورت آھي ٻن رليز شاخن جا خرچ. سکو پاڻ کي اپ ڊيٽ کان بچائڻ لاءِ جيڪي پسمانده مطابقت کي ٽوڙيو. پر سڀ کان اهم: توهان ڏکيو گفتگو ڪرڻ کان پاسو نٿا ڪري سگهو.

منهنجي تجربي ۾، جڏهن ٽيمون وڏيون ٿي وينديون آهن، اهو هاڻي ممڪن ناهي ته سڄي سسٽم کي ذهن ۾ رکڻ لاء، ۽ اهو سڀ کان اهم حصو آهي. توهان کي سسٽم ۾ تڪرار جي نمائش کي بهتر بڻائڻ گهرجي. توھان کي فعال طور تي ڪم ڪرڻ گھرجي ٽيمن کي انھن جي اجزاء کان پري ڏسڻ ۽ ٻين ٽيمن ۽ صارفين جي ڪم کي ڏسڻ لاءِ.

ها، توهان اوزار ٺاهي سگهو ٿا جيڪي حل ڪرڻ جي ڪوشش ڪن ٿا polyrepository مسئلو. پر منهنجو تجربو وڏين ادارن ۾ مسلسل ترسيل ۽ آٽوميشن سيکارڻ مون کي ٻڌائي ٿو: اضافي اوزارن جي استعمال کان سواءِ ڊفالٽ رويو اهو آهي جيڪو توهان ڏسڻ جي توقع ڪندا. هڪ polyrepository جو ڊفالٽ رويي اڪيلائي آهي، اهو سڄو نقطو آهي. هڪ monorepository جو ڊفالٽ رويو گڏيل ذميواري ۽ شفافيت آهي، اهو سڄو نقطو آهي. ٻنهي صورتن ۾، مان هڪ اوزار ٺاهڻ وارو آهيان جيڪو ٿلهي ڪنڊن کي هموار ڪندو. هڪ ليڊر جي حيثيت ۾، مان هر ڀيري هڪ monorepository چونڊيندس ڇو ته اوزارن کي ضرورت آهي ته ان ڪلچر کي مضبوط ڪرڻ لاءِ جنهن کي مان چاهيان ٿو، ۽ ثقافت ننڍڙن فيصلن ۽ ٽيم جي روزاني ڪم مان ايندي آهي.

صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. سائن ان ڪريو، توهان جي مهرباني.

سڀ کان وڏو پرستار ڪير آهن؟ حمايتي:

• مونورپو

• زنگ

• غلط راءِ / ٻئي

33 صارفين ووٽ ڏنو. 13 استعمال ڪندڙن کي روڪيو ويو.

جو ذريعو: www.habr.com