لیجر لائیو مونوریپو پروجیکٹ: حصہ 1 - مسائل (اسے درد بنائیں) | لیجر

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

تھوڑی بہت تاریخ 

2020 اور 2021 میں لیجر کی نمو نمایاں تھی۔ ہم نے جارحانہ انداز میں نئے ٹیلنٹ کو بھرتی کیا، اپنی ٹیم کو صرف مٹھی بھر سے 20 سے زیادہ ڈویلپرز تک بڑھا دیا۔ اس کا مطلب ہے کہ موجودہ پروجیکٹس پر بہت سارے نئے انجینئرز کو شامل کیا گیا تھا۔ جیسے جیسے ہماری ٹیم تیزی سے ترقی کرتی گئی، ہمیں نئے چیلنجوں کا سامنا کرنا پڑا جن سے ہمیں فوری طور پر نمٹنا تھا۔ ان نئی مشکلات کے باوجود، ہم نے اپنے مقصد پر توجہ مرکوز رکھی اور غیر معمولی کام کو جاری رکھا۔

ہم نے ایک قدم پیچھے ہٹ کر ان نئی پریشانیوں کا جائزہ لیا جو اس وقت پیدا ہوتی ہیں جب زیادہ سے زیادہ لوگ اس پروجیکٹ میں شامل ہوتے ہیں۔ ان نئے چیلنجوں میں، ہم درج ذیل ضروریات کو درج کر سکتے ہیں:

• آسان بہاؤ۔
• آنے والے اور بیرونی تعاون کنندگان کے لیے بہتر رہنما خطوط۔
• ٹولز کا ایک متحد سیٹ۔
• انحصار کا بہتر انتظام۔
• سنٹرلائزڈ اوپن سورس شراکتیں۔

اسٹیٹ آف دی آرٹ: ہجرت سے پہلے

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

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

Dev Experience Bottlenecks

انحصار

ہمارے پروجیکٹس کی نوعیت کی وجہ سے، ہم ایک ہی وقت میں متعدد ریپوزٹریز پر کام کرتے ہیں، ان کے درمیان انحصار کے ساتھ۔ یہاں ایک فوری جائزہ ہے:

لیجر اوپن سورس لائبریریوں کو کاروباری منطق کے ذریعہ استعمال کیا جاتا ہے، جو پھر ڈیسک ٹاپ اور موبائل ایپس دونوں کے ذریعہ استعمال ہوتا ہے۔ لیکن وہ ایپس اوپن سورس لائبریریوں کو بھی استعمال کرتی ہیں، اور ایک ہی لائبریری کے دو مختلف ورژن استعمال کرتی ہیں (جیسے @ledgerhq/errors مثال کے طور پر) ایپ کو توڑ دے گا۔

ہمیں ورژن کو ایک طرف سے ٹکرانے کی ضرورت تھی، پھر لائبریریوں کو شائع کریں (ہاں، npm!!!)، پھر دوبارہ کوشش کریں اگر یہ کام نہیں کرتا ہے۔ ہم پر بھروسہ کرنے لگے yalc symlink پروجیکٹس کے لیے، جو زیادہ تر اس وقت تک ٹھیک تھا جب تک کہ ہمارے پاس انحصار کی کئی پرتیں نہ ہوں (مثال کے طور پر، اوپن سورس لائبریریوں سے لے کر بزنس لاجک تک، اور پھر بزنس لاجک سے ایپس تک)۔ ہم نے عارضی طور پر کام کرنے کی کوشش کی۔ yarn link اس کے ساتھ ساتھ، لیکن ایسا لگتا ہے کہ یہ React Native کے ساتھ برباد ہو گیا تھا۔

ٹیسٹنگ

مختلف پروجیکٹس کے تمام تازہ ترین کوڈ کے ساتھ انضمام کے ٹیسٹ کرنا قریب قریب ناممکن تھا۔ چونکہ ہمیں لائبریریوں کو رجسٹری میں شائع کرنے کی ضرورت تھی، اس لیے تازہ ترین اپ ٹو ڈیٹ کوڈ کے ساتھ تمام اجزاء کی جانچ کرنا ایک ڈراؤنا خواب تھا۔

ہمیں نقل شدہ منطق کے ساتھ کئی CI کو بھی برقرار رکھنا پڑا۔

سیاق و سباق سوئچنگ

ہمیشہ متعدد کوڈ ایڈیٹرز / پروجیکٹس / ڈائریکٹریوں کے گرد گھومنے سے دیو کا تجربہ واقعی کمزور نظر آتا ہے۔

رہائی کے عمل کی رکاوٹیں

نسخہ

مختلف پروجیکٹس کے ورژن کو سنبھالنا مشکل ہے، خاص طور پر جب انحصار کی کئی پرتیں ہوں۔

جاری

ریلیز ٹریکنگ اس حقیقت کی وجہ سے پیچیدہ تھی کہ پروجیکٹس تقسیم ہوگئے تھے، اور ہمیں مختلف پروجیکٹس کی ریلیز کا انتظام کرنا پڑا

ریلیز کے عمل کو خود کار بنانا ناممکن تھا، اس حقیقت کی وجہ سے کہ پروجیکٹس کو مختلف ذخیروں میں تقسیم کیا گیا تھا۔

اور ظاہر ہے، مسلسل ترسیل اس وقت ناقابل تصور تھی۔

ممکنہ حل؟

الہام کے لیے ارد گرد تلاش کرتے ہوئے، ایسا لگتا ہے کہ ایک مونو ریپوزٹری فن تعمیر مرکزی ٹکڑا ہے جسے ہم غائب کر رہے تھے۔ یہ بہت بہتر ترقی کے عمل کو قابل بنائے گا۔ اس فن تعمیر کے ارد گرد ایسے ٹولز بنائے گئے ہیں جو گمشدہ حصوں (ریلیز، آٹومیشن، ورژننگ…) کو حاصل کرنے میں ہماری مدد کریں گے۔

لیکن، ایک مونو ذخیرہ کیا ہے؟

اس کے مرکز میں، ایک مونو ریپوزٹری ایک ایسا پروجیکٹ ہے جو ایک فولڈر/گٹ پروجیکٹ کے تحت دیگر تمام متعلقہ پروجیکٹس (ایپلی کیشنز، لائبریریز، ٹولز) کو سمیٹتا ہے۔ یہ بہتر انحصاری انتظام، ٹولز کی یکسانیت (جیسے کوڈ اسٹائلز اور ٹائپ اسکرپٹ کنفیگریشنز)، سنٹرلائزڈ کنٹینیوئس انٹیگریشن، انٹیگریشن ٹیسٹنگ، استعمال شدہ پیکڈ کا یکساں ورژن (مثال کے طور پر رد عمل) کی اجازت دیتا ہے۔

چونکہ یہ ایک خوبصورت اجناسٹک نظام ہے، اس لیے کچھ خصوصیات ہمارے لیے دریافت کرنے اور نافذ کرنے کے لیے چھوڑ دی گئیں۔ امید ہے کہ، کچھ عظیم کمیونٹی ٹولز موجود ہیں جو ہمیں تعمیرات میں آرکیسٹریشن شامل کرنے میں مدد کر سکتے ہیں (سیکوینشل بلڈز، CI کے لیے مددگار)، ورژننگ، چینج لاگ جنریشن۔

خامیاں

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

پیشہ

وقت، لاگت، اور ہمارے عزائم کی فزیبلٹی کا جائزہ لینے کے بعد، اس منتقلی کے کچھ متوقع فوائد یہ ہیں:

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

نتیجہ

مجموعی طور پر، ایک monorepo ڈھانچے کے نفاذ سے ترقی کے عمل کو بہتر بنانے، رہائی کے عمل کو ہموار کرنے، اور ڈویلپر کے تجربے کو بڑھانے میں مدد مل سکتی ہے۔

اس سیریز کی اگلی بلاگ پوسٹس میں، ہم آپ کو بتائیں گے کہ اس بڑے ہجرت کے منصوبے کو کیسے انجام دیا گیا، ہم نے کون سے ٹولز استعمال کیے، ہمارے کیے گئے انتخاب، نتیجہ اور بہت کچھ۔ حصہ 2 کے لیے دیکھتے رہیں: ٹولز!

---

ویلنٹائن ڈی المیڈا
ڈویلپر کا تجربہ اور بنیادی ٹیک - لیجر لائیو

• SEO سے چلنے والا مواد اور PR کی تقسیم۔ آج ہی بڑھا دیں۔
• پلیٹو ڈیٹا ڈاٹ نیٹ ورک ورٹیکل جنریٹو اے آئی۔ اپنے آپ کو بااختیار بنائیں۔ یہاں تک رسائی حاصل کریں۔
• پلیٹوآئ اسٹریم۔ ویب 3 انٹیلی جنس۔ علم میں اضافہ۔ یہاں تک رسائی حاصل کریں۔
• پلیٹو ای ایس جی۔ کاربن، کلین ٹیک، توانائی ، ماحولیات، شمسی، ویسٹ مینجمنٹ یہاں تک رسائی حاصل کریں۔
• پلیٹو ہیلتھ۔ بائیوٹیک اینڈ کلینیکل ٹرائلز انٹیلی جنس۔ یہاں تک رسائی حاصل کریں۔
• ماخذ: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain