مونوریپو یا ملٹی ریپو
فہرست:
خلاصہ
مسئلہ
ہمارے منصوبے میں سافٹ ویئر کی تین بڑی اقسام کی ڈویلپمنٹ شامل ہے:
- فرنٹ اینڈ GUIs
- مڈل ویئر سروسز
- بیک اینڈ سرورز
جب ہم ڈویلپ کرتے ہیں تو ہمارا سورس کوڈ مینجمنٹ (SCM) ورژن کنٹرول سسٹم (VCS) git ہے۔
ہمیں فیصلہ کرنا ہے کہ اپنا کوڈ منظم کرنے کے لیے git کیسے استعمال کریں۔
اعلیٰ سطح کا انتخاب یہ ہے کہ “مونوریپو” یا “پولی ریپو” یا “ہائبرڈ” کے طور پر منظم کریں:
- مونوریپو کا مطلب ہے کہ ہم تمام حصے ایک بڑی ریپو میں رکھتے ہیں
- پولی ریپو کا مطلب ہے کہ ہم ہر حصہ اس کی اپنی ریپو میں رکھتے ہیں
- ہائبرڈ کا مطلب ہے مونوریپو اور پولی ریپو کا کچھ ملاپ
مزید کے لیے دیکھیں https://github.com/joelparkerhenderson/monorepo-vs-polyrepo
فیصلہ
مونوریپو جب کوئی تنظیم/ٹیم/منصوبہ نسبتاً چھوٹا ہو، اور تیز تکرار استحکام برقرار رکھنے سے زیادہ ترجیح رکھتی ہو۔
پولی ریپو جب کوئی تنظیم/ٹیم/منصوبہ نسبتاً بڑا ہو، اور استحکام برقرار رکھنا تیز تکرار سے زیادہ ترجیح رکھتا ہو۔
حالت
فیصلہ ہو گیا۔ مونوریپوز اور/یا پولی ریپوز کے انتظام کے لیے نئی ٹولنگ دستیاب ہونے پر دوبارہ غور کے لیے کھلے ہیں۔
تفصیلات
مفروضات
وہ تمام کوڈ جو ہم ڈویلپ کر رہے ہیں ایک تنظیم کی پیشکشوں کے لیے ہے، عوام کے لیے نہیں۔ یعنی بروکر-ڈیلر کا ہدف عوام کے رضاکار ڈویلپرز جیسی کوئی چیز رکھنا نہیں۔
پابندیاں
پابندیاں https://github.com/joelparkerhenderson/monorepo-vs-polyrepo پر اچھی طرح دستاویزی ہیں
مؤقف
ہم نے Google، Facebook وغیرہ کے انداز کے مونوریپوز پر غور کیا۔ ہمارا خیال ہے کہ مونوریپو کی وسعت پذیری کے کوئی بھی مسائل اتنے مستقبل میں ہیں کہ جب ہمیں ان کی ضرورت ہوگی تو ہم Google اور Facebook جیسی ہی مشقوں سے فائدہ اٹھا سکیں گے۔
ہم نے عام Git اوپن سورس منصوبوں کے انداز کے پولی ریپوز پر غور کیا، جیسے Google Android، Facebook React وغیرہ۔ ہمارا خیال ہے کہ یہ عوام کی شرکت (مثلاً دنیا میں کوئی بھی کوڈ پر کام کر سکتا ہے) اور انفرادی دستیابی (مثلاً منصوبہ کسی دوسرے حصے کے بغیر خود استعمال ہوتا ہے) کے لیے بہترین انتخاب ہیں۔
دلیل
جب کوئی تنظیم/ٹیم/منصوبہ نسبتاً چھوٹا ہو تو ہم مونوریپو چنتے ہیں، کیونکہ تیز تکرار استحکام برقرار رکھنے سے نمایاں طور پر زیادہ ترجیح رکھتی ہے
جب کوئی تنظیم/ٹیم/منصوبہ نسبتاً بڑا ہو تو ہم پولی ریپو چنتے ہیں، کیونکہ استحکام برقرار رکھنا تیز تکرار سے نمایاں طور پر زیادہ ترجیح رکھتا ہے۔
مضمرات
اگر CI+CD کے لیے کوئی موجودہ پائپ لائن ہو تو ہمیں اسے ایک ریپو کے اندر متعدد منصوبوں کی جانچ کے لیے ایڈجسٹ کرنا پڑ سکتا ہے۔
مونوریپو کے مکمل بلڈ کے لیے CI+CD میں زیادہ وقت لگ سکتا ہے، کیونکہ CI+CD مونوریپو کے تمام منصوبے بلڈ کر سکتا ہے۔
اگر کوئی تنظیم/ٹیم/منصوبہ بڑھے تو مونوریپو میں وسعت پذیری کے مسائل آئیں گے۔
مونوریپو کی وسعت پذیری کے مسائل پولی ریپو پر منتقلی کو بڑھتی ہوئی قدر دے سکتے ہیں۔
مونوریپو سے پولی ریپو پر منتقلی ایک اہم devops کام ہے، اور اس کی منصوبہ بندی، انتظام اور پروگرامنگ کرنی ہوگی۔
متعلقہ
متعلقہ فیصلے
ہم مونوریپوز (مثلاً Google Bazel) اور پولی ریپوز (مثلاً Lyft Refactorator) کے انتظام کے متعلقہ ٹولنگ کے لیے فیصلے بنائیں گے۔
متعلقہ تقاضے
ہمیں CI+CD پائپ لائن اس طرح ڈویلپ کرنی ہے کہ وہ git کے ساتھ اچھی طرح کام کرے۔
متعلقہ آرٹیفیکٹس
ہم توقع کرتے ہیں کہ ریپو کی تنظیم کے پاس پروویژننگ، کنفیگریشن مینجمنٹ، ٹیسٹنگ اور اسی طرح کے devops شعبوں کے متعلقہ آرٹیفیکٹس ہوں گے۔
متعلقہ اصول
آسانی سے واپس لیا جا سکتا ہے۔ اگر مونوریپو عملاً کام نہ کرے، یا قیادت نہ چاہے، تو پولی ریپو میں بدلنا آسان ہے۔
صارف کا جنون۔ ہم منصوبہ صارفین کے ہاتھوں میں پہنچانے کی قدر کرتے ہیں، اور ہمیں یقین ہے کہ مونوریپو ہمیں پولی ریپو سے زیادہ تیزی سے وہاں پہنچا سکتا ہے، اور تیز تکرار میں بھی مدد دے سکتا ہے۔
بڑا سوچیں۔ Google اور Facebook پولی ریپوز کے مقابلے میں مونوریپوز کے بہت مضبوط حامی ہیں، کیونکہ تمام بنیادی پیشکشیں ایک ساتھ ڈویلپ/ٹیسٹ/ڈپلائے کی جا سکتی ہیں۔
نوٹس
یہاں کوئی بھی نوٹس شامل کریں۔