کورس کے طلباء کے لیے تیار کردہ مضمون کا ترجمہ "DevOps طریقوں اور اوزار" OTUS تعلیمی منصوبے میں۔

آپ کو ایک monorepository کا انتخاب کرنا چاہئے کیونکہ یہ آپ کی ٹیموں میں جس طرز عمل کو فروغ دیتا ہے وہ شفافیت اور مشترکہ ذمہ داری ہے، خاص طور پر جب ٹیمیں بڑھتی ہیں۔ کسی بھی طرح سے، آپ کو ٹولنگ میں سرمایہ کاری کرنا پڑے گی، لیکن یہ ہمیشہ بہتر ہے اگر پہلے سے طے شدہ رویہ وہی ہو جو آپ اپنے حکموں میں چاہتے ہیں۔

ہم اس کے بارے میں کیوں بات کر رہے ہیں؟

میٹ کلین نے مضمون لکھا "Monorepos: براہ مہربانی مت کرو!"  (مترجم کا نوٹ: Habré پر ترجمہ "Monorepositories: براہ کرم ایسا نہ کریں")۔ مجھے میٹ پسند ہے، مجھے لگتا ہے کہ وہ بہت ہوشیار ہے اور آپ کو اس کا نقطہ نظر پڑھنا چاہیے۔ اس نے اصل میں ٹویٹر پر پول پوسٹ کیا:

ترجمہ:
اس نئے سال کے دن، میں اس بارے میں بحث کرنے جا رہا ہوں کہ monorepositories کتنی مضحکہ خیز ہیں۔ 2019 کا آغاز خاموشی سے ہوا۔ اس کی روح میں، میں آپ کو ایک سروے پیش کرتا ہوں۔ بڑے جنونی کون ہیں؟ حامی:
- مونورپو
- مورچا
- غلط رائے شماری / دونوں

میرا جواب تھا، "میں لفظی طور پر ان دونوں لوگوں میں سے ہوں۔" اس کے بارے میں بات کرنے کے بجائے کہ زنگ ایک منشیات کیسے ہے، آئیے دیکھتے ہیں کہ مجھے کیوں لگتا ہے کہ وہ monorepositories کے بارے میں غلط ہے۔ اپنے بارے میں تھوڑا سا۔ میں شیف سافٹ ویئر کا CTO ہوں۔ ہمارے پاس تقریباً 100 انجینئرز ہیں، ایک کوڈ بیس تقریباً 11-12 سال پرانا ہے، اور 4 اہم مصنوعات ہیں۔ اس میں سے کچھ کوڈ پولی ریپوزٹری (میری ابتدائی پوزیشن) میں ہے، کچھ مونورپوزٹری (میری موجودہ پوزیشن) میں ہے۔

اس سے پہلے کہ میں شروع کروں: میں یہاں جو بھی دلیل پیش کرتا ہوں اس کا اطلاق دونوں قسم کے ذخیروں پر ہوگا۔ میری رائے میں، کوئی تکنیکی وجہ نہیں ہے کہ آپ کو ایک قسم کے ذخیرے کو دوسری پر کیوں منتخب کرنا چاہیے۔ آپ کسی بھی نقطہ نظر کو کام کر سکتے ہیں. میں اس کے بارے میں بات کرنے میں خوش ہوں، لیکن مجھے مصنوعی تکنیکی وجوہات میں دلچسپی نہیں ہے کہ ایک دوسرے سے برتر کیوں ہے۔

میں میٹ کے پوائنٹ کے پہلے حصے سے متفق ہوں:

کیونکہ پیمانے پر، ایک monorepository ان تمام مسائل کو حل کرے گی جو ایک polyrepository حل کرتی ہے، لیکن ایک ہی وقت میں آپ کو اپنے کوڈ کو مضبوطی سے جوڑنے پر مجبور کرتی ہے اور آپ کے ورژن کنٹرول سسٹم کی توسیع پذیری کو بڑھانے کے لیے ناقابل یقین کوششوں کی ضرورت ہوتی ہے۔

آپ کو انہی مسائل کو حل کرنا پڑے گا قطع نظر اس کے کہ آپ ایک monorepository یا polyrepository کا انتخاب کرتے ہیں۔ آپ ریلیز کیسے جاری کرتے ہیں؟ اپ ڈیٹس کے لیے آپ کا نقطہ نظر کیا ہے؟ پسماندہ مطابقت؟ کراس پروجیکٹ انحصار؟ کون سے تعمیراتی انداز قابل قبول ہیں؟ آپ اپنی تعمیر اور جانچ کے بنیادی ڈھانچے کا انتظام کیسے کرتے ہیں؟ فہرست لامتناہی ہے۔ اور جیسے جیسے آپ بڑھیں گے آپ ان سب کو حل کریں گے۔ کوئی مفت پنیر نہیں ہے۔

میرے خیال میں میٹ کی دلیل بہت سے انجینئرز (اور مینیجرز) کے اشتراک کردہ خیالات سے ملتی جلتی ہے جن کا میں احترام کرتا ہوں۔ یہ جزو پر کام کرنے والے انجینئر یا جزو پر کام کرنے والی ٹیم کے نقطہ نظر سے ہوتا ہے۔ آپ ایسی چیزیں سنتے ہیں جیسے:

• کوڈ بیس بہت بڑا ہے - مجھے اس سب فضول کی ضرورت نہیں ہے۔
• اس کی جانچ کرنا مشکل ہے کیونکہ مجھے اس تمام فضول کی جانچ کرنی ہے جس کی مجھے ضرورت نہیں ہے۔
• بیرونی انحصار کے ساتھ کام کرنا زیادہ مشکل ہے۔
• مجھے اپنے ورچوئل ورژن کنٹرول سسٹمز کی ضرورت ہے۔

یقیناً یہ تمام نکات جائز ہیں۔ یہ دونوں ہی صورتوں میں ہوتا ہے - پولی ریپوزٹری میں میرے پاس اپنا ردی ہے، اس کے علاوہ تعمیر کے لیے ضروری ہے... مجھے دوسرے ردی کی بھی ضرورت پڑ سکتی ہے۔ لہذا میں "صرف" ٹولز بناتا ہوں جو پورے پروجیکٹ کو چیک کرتے ہیں۔ یا میں ذیلی ماڈلز کے ساتھ ایک جعلی مونورپوزٹری بناتا ہوں۔ ہم سارا دن اس کے ارد گرد چل سکتے ہیں. لیکن مجھے لگتا ہے کہ میٹ کی دلیل بنیادی وجہ سے محروم ہے، جسے میں نے monorepository کے حق میں کافی حد تک پلٹایا:

یہ مواصلات کو بھڑکاتا ہے اور مسائل کو ظاہر کرتا ہے۔

جب ہم ذخیرہ خانوں کو الگ کرتے ہیں تو ہم ہم آہنگی اور شفافیت کا اصل مسئلہ پیدا کرتے ہیں۔ یہ ٹیموں کے بارے میں ہمارے سوچنے کے انداز سے مطابقت رکھتا ہے (خاص طور پر جس طرح سے انفرادی ممبران ان کے بارے میں سوچتے ہیں): ہم ایک خاص جزو کے ذمہ دار ہیں۔ ہم رشتہ دار تنہائی میں کام کرتے ہیں۔ میری ٹیم اور جن اجزاء پر ہم کام کر رہے ہیں ان پر حدود طے شدہ ہیں۔

جیسا کہ فن تعمیر زیادہ پیچیدہ ہو جاتا ہے، ایک ٹیم اب اسے اکیلے منظم نہیں کر سکتی۔ بہت کم انجینئرز کے پاس پورا نظام ہوتا ہے۔ ہم کہتے ہیں کہ آپ ایک مشترکہ جزو A کا نظم کرتے ہیں جو ٹیم B، C، اور D کے ذریعے استعمال کیا جاتا ہے۔ ٹیم A ری فیکٹرنگ کر رہی ہے، API کو بہتر بنا رہی ہے، اور اندرونی نفاذ کو بھی تبدیل کر رہی ہے۔ نتیجے کے طور پر، تبدیلیاں پیچھے کی طرف مطابقت نہیں رکھتی ہیں۔ آپ کو کیا مشورہ ہے؟

• وہ تمام جگہیں تلاش کریں جہاں پرانا API استعمال ہوتا ہے۔
• کیا ایسی جگہیں ہیں جہاں نیا API استعمال نہیں کیا جا سکتا؟
• کیا آپ اس بات کو یقینی بنانے کے لیے دوسرے اجزاء کو ٹھیک اور جانچ سکتے ہیں کہ وہ ٹوٹ نہ جائیں؟
• کیا یہ ٹیمیں ابھی آپ کی تبدیلیوں کی جانچ کر سکتی ہیں؟

براہ کرم نوٹ کریں کہ یہ سوالات مخزن کی قسم سے آزاد ہیں۔ آپ کو ٹیمیں B، C اور D تلاش کرنے کی ضرورت ہوگی۔ آپ کو ان سے بات کرنے، وقت معلوم کرنے، ان کی ترجیحات کو سمجھنے کی ضرورت ہوگی۔ کم از کم ہمیں امید ہے کہ آپ کریں گے۔

کوئی بھی واقعی ایسا نہیں کرنا چاہتا۔ یہ صرف لات API کو ٹھیک کرنے کے مقابلے میں بہت کم مزہ ہے۔ یہ سب انسانی اور گندا ہے۔ پولی ریپوزٹری میں، آپ آسانی سے تبدیلیاں کر سکتے ہیں، اسے اس جز پر کام کرنے والے لوگوں کو دے سکتے ہیں (شاید B، C یا D نہیں) جائزہ کے لیے، اور آگے بڑھیں۔ ٹیمیں B، C اور D ابھی اپنے موجودہ ورژن کے ساتھ رہ سکتی ہیں۔ وہ تجدید ہو جائیں گے جب وہ آپ کی ذہانت کا احساس کریں گے!

ایک monorepository میں، ذمہ داری کو بطور ڈیفالٹ منتقل کیا جاتا ہے۔ ٹیم A اپنا جزو تبدیل کر لیتی ہے اور اگر احتیاط نہ کی گئی تو فوراً B، C اور D کو توڑ دیتی ہے۔ اس کی وجہ سے B، C اور D A کے دروازے پر ظاہر ہوتے ہیں، حیران ہوتے ہیں کہ ٹیم A نے اسمبلی کو کیوں توڑا۔ یہ A کو سکھاتا ہے کہ وہ اوپر میری فہرست کو نہیں چھوڑ سکتے۔ انہیں اس بارے میں بات کرنی چاہیے کہ وہ کیا کرنے جا رہے ہیں۔ کیا B، C اور D منتقل ہو سکتے ہیں؟ کیا ہوگا اگر B اور C کر سکتے ہیں، لیکن D کا پرانے الگورتھم کے رویے کے ضمنی اثر سے گہرا تعلق تھا؟

پھر ہمیں بات کرنی ہے کہ ہم اس صورتحال سے کیسے نکلیں گے:

1. متعدد اندرونی APIs کے لیے سپورٹ، اور پرانے الگورتھم کو فرسودہ کے بطور نشان زد کرے گا جب تک کہ D اسے استعمال کرنا بند نہ کر دے۔
2. ایک سے زیادہ ریلیز ورژن کے لیے سپورٹ، ایک پرانے انٹرفیس کے ساتھ، ایک نئے کے ساتھ۔
3. A کی تبدیلیوں کے اجراء میں اس وقت تک تاخیر کریں جب تک کہ B، C، اور D اسے بیک وقت قبول نہ کر لیں۔

ہم کہتے ہیں کہ ہم نے 1، کئی APIs کا انتخاب کیا ہے۔ اس صورت میں ہمارے پاس کوڈ کے دو ٹکڑے ہیں۔ پرانا اور نیا۔ کچھ حالات میں کافی آسان۔ ہم پرانے کوڈ کو دوبارہ چیک کرتے ہیں، اسے فرسودہ کے بطور نشان زد کرتے ہیں، اور ڈی ٹیم کے ساتھ ہٹانے کے شیڈول پر متفق ہیں۔ پولی اور مونو ریپوزٹریز کے لیے بنیادی طور پر ایک جیسے ہیں۔

متعدد ورژن جاری کرنے کے لیے، ہمیں ایک شاخ کی ضرورت ہے۔ اب ہمارے پاس دو اجزاء ہیں - A1 اور A2۔ ٹیمیں B اور C A2 استعمال کرتی ہیں اور D A1 استعمال کرتی ہیں۔ ہمیں ریلیز کے لیے تیار رہنے کے لیے ہر جزو کی ضرورت ہے کیونکہ ڈی کے آگے بڑھنے سے پہلے سیکیورٹی اپ ڈیٹس اور دیگر بگ فکسز کی ضرورت پڑ سکتی ہے۔ ایک پولی ریپوزٹری میں، ہم اسے ایک طویل عرصے تک رہنے والی شاخ میں چھپا سکتے ہیں جو اچھا لگتا ہے۔ ایک monorepository میں، ہم کوڈ کو ایک نئے ماڈیول میں بنانے پر مجبور کرتے ہیں۔ ٹیم ڈی کو اب بھی "پرانے" جزو میں تبدیلیاں کرنا ہوں گی۔ ہر کوئی اس قیمت کو دیکھ سکتا ہے جو ہم یہاں ادا کر رہے ہیں - اب ہمارے پاس دو گنا زیادہ کوڈ ہے، اور A1 اور A2 پر لاگو ہونے والی کوئی بھی بگ فکسز ان دونوں پر لاگو ہونی چاہئیں۔ پولی ریپوزٹری میں برانچنگ اپروچ کے ساتھ، یہ چیری پک کے پیچھے چھپا ہوا ہے۔ ہم قیمت کو کم سمجھتے ہیں کیونکہ کوئی نقل نہیں ہے۔ عملی نقطہ نظر سے، لاگت ایک جیسی ہے: آپ دو بڑے پیمانے پر ایک جیسے کوڈ بیسز بنائیں گے، جاری کریں گے اور برقرار رکھیں گے جب تک کہ آپ ان میں سے کسی ایک کو حذف نہ کر دیں۔ فرق یہ ہے کہ monorepository کے ساتھ یہ درد براہ راست اور نظر آتا ہے۔ یہ اور بھی برا ہے، اور یہ اچھا ہے۔

آخر میں، ہم تیسرے نقطہ پر پہنچ گئے. رہائی میں تاخیر۔ یہ ممکن ہے کہ A کی طرف سے کی گئی تبدیلیاں ٹیم A کی زندگیوں میں بہتری لائیں گی۔ اہم، لیکن فوری نہیں۔ کیا ہم صرف تاخیر کر سکتے ہیں؟ ایک پولی ریپوزٹری میں، ہم اسے آرٹفیکٹ کو پن کرنے کے لیے دباتے ہیں۔ یقیناً ہم یہ ٹیم ڈی کو بتا رہے ہیں۔ بس پرانے ورژن پر ہی رہیں جب تک کہ آپ اسے نہیں پکڑ لیتے! یہ آپ کو بزدلانہ کھیلنے کے لیے تیار کرتا ہے۔ ٹیم A اس حقیقت کو نظر انداز کرتے ہوئے اپنے اجزاء پر کام جاری رکھے ہوئے ہے کہ ٹیم D تیزی سے پرانا ورژن استعمال کر رہی ہے (یہ ٹیم D کا مسئلہ ہے، وہ احمق ہیں)۔ دریں اثنا، ٹیم ڈی کوڈ کے استحکام کے بارے میں ٹیم A کے لاپرواہ رویہ کے بارے میں خراب بات کرتا ہے، اگر وہ اس کے بارے میں بالکل بھی بات کرتے ہیں۔ مہینے گزر جاتے ہیں۔ آخر میں، ٹیم ڈی اپ ڈیٹ کرنے کے امکان کو دیکھنے کا فیصلہ کرتی ہے، لیکن A میں صرف مزید تبدیلیاں ہیں۔ ٹیم A کو بمشکل یاد ہے کہ انہوں نے D کب اور کیسے توڑا۔ اپ گریڈ زیادہ تکلیف دہ ہے اور اس میں زیادہ وقت لگے گا۔ جو اسے ترجیحی اسٹیک میں مزید نیچے بھیجتا ہے۔ اس دن تک جب تک کہ ہمیں اے میں سیکیورٹی کا مسئلہ درپیش ہے جو ہمیں برانچ بنانے پر مجبور کرتا ہے۔ ٹیم A کو وقت پر واپس جانا چاہیے، ایک نقطہ تلاش کریں جب D مستحکم ہو، مسئلہ کو وہیں حل کریں، اور اسے رہائی کے لیے تیار کریں۔ یہ ڈی فیکٹو انتخاب ہے جو لوگ کرتے ہیں، اور یہ اب تک کا سب سے برا ہے۔ یہ ٹیم اے اور ٹیم ڈی دونوں کے لیے اچھا لگتا ہے جب تک کہ ہم ایک دوسرے کو نظر انداز کر سکتے ہیں۔

ایک monorepository میں، تیسرا واقعی کوئی آپشن نہیں ہے۔ آپ دو طریقوں میں سے کسی ایک طریقے سے صورتحال سے نمٹنے پر مجبور ہیں۔ آپ کو دو ریلیز برانچز رکھنے کے اخراجات دیکھنے کی ضرورت ہے۔ اپنے آپ کو ان اپ ڈیٹس سے بچانا سیکھیں جو پسماندہ مطابقت کو توڑ دیتے ہیں۔ لیکن سب سے اہم: آپ مشکل گفتگو سے بچ نہیں سکتے۔

میرے تجربے میں، جب ٹیمیں بڑی ہو جاتی ہیں، تو پورے نظام کو ذہن میں رکھنا اب ممکن نہیں رہتا، اور یہی سب سے اہم حصہ ہے۔ آپ کو سسٹم میں اختلاف کی مرئیت کو بہتر بنانا ہوگا۔ ٹیموں کو ان کے اجزاء سے دور دیکھنے اور دوسری ٹیموں اور صارفین کے کام کو دیکھنے کے لیے آپ کو فعال طور پر کام کرنا چاہیے۔

ہاں، آپ ایسے ٹولز بنا سکتے ہیں جو پولی ریپوزٹری کے مسئلے کو حل کرنے کی کوشش کرتے ہیں۔ لیکن بڑے اداروں میں مسلسل ڈیلیوری اور آٹومیشن سکھانے کا میرا تجربہ مجھے یہ بتاتا ہے: اضافی ٹولز کے استعمال کے بغیر طے شدہ رویہ وہ رویہ ہے جس کی آپ توقع کرتے ہیں۔ پولی ریپوزٹری کا پہلے سے طے شدہ سلوک تنہائی ہے ، یہی پوری بات ہے۔ ایک monorepository کا پہلے سے طے شدہ سلوک مشترکہ ذمہ داری اور شفافیت ہے، یہ پوری بات ہے۔ دونوں صورتوں میں، میں ایک ٹول بنانے جا رہا ہوں جو کھردرے کناروں کو ہموار کر دے گا۔ ایک لیڈر کے طور پر، میں ہر بار ایک monorepository کا انتخاب کروں گا کیونکہ ٹولز کو اس ثقافت کو تقویت دینے کی ضرورت ہے جو میں چاہتا ہوں، اور ثقافت چھوٹے فیصلوں اور ٹیم کے روزمرہ کے کام سے آتی ہے۔

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

سب سے بڑے جنونی کون ہیں؟ حامی:

• مونورپو

• مورچا

• غلط رائے شماری / دونوں

33 صارفین نے ووٹ دیا۔ 13 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com