Ledger Live Monorepo Project: Part 1 – Problematics (Make it Pain) | دفتر کل

در این مجموعه پست وبلاگ، والنتین دی آلمیدا، یک توسعه‌دهنده لجر لایو، با ما در مورد تکامل پایگاه کد لجر لایو در طول سال‌ها صحبت می‌کند. در این پست وبلاگ، یاد خواهید گرفت که در ابتدا مبتنی بر چند مخزن بود، مسائلی که در طول مسیر با آن مواجه شدیم و چرا باید به معماری تک مخزن تبدیل شود. در پست های بعدی وبلاگ نحوه انجام این پروژه بزرگ مهاجرت را توضیح خواهیم داد. 

کمی تاریخ 

رشد لجر در سال های 2020 و 2021 قابل توجه بود. ما به شدت استعدادهای جدید را جذب کردیم و تیم خود را از تعداد انگشت شماری به بیش از 20 توسعه دهنده افزایش دادیم. این بدان معناست که تعداد زیادی از مهندسان جدید در پروژه های موجود حضور داشتند. همانطور که تیم ما به سرعت رشد می کرد، با چالش های جدیدی روبرو شدیم که باید به سرعت آنها را برطرف می کردیم. با وجود این مشکلات جدید، ما روی هدف خود متمرکز ماندیم و به ارائه کارهای استثنایی ادامه دادیم.

ما یک گام به عقب برداشتیم و مشکلات جدیدی را بررسی کردیم که وقتی افراد بیشتری وارد پروژه شدند، به وجود آمدند. در میان آن چالش‌های جدید، می‌توانیم نیازهای زیر را فهرست کنیم:

• جریان های ساده تر
• دستورالعمل های بهتر برای مشارکت کنندگان ورودی و خارجی.
• مجموعه یکپارچه از ابزار.
• مدیریت وابستگی بهتر
• مشارکت های منبع باز متمرکز.

وضعیت هنر: قبل از مهاجرت

در ابتدا و تا سال گذشته، Ledger Live بر اساس یک معماری چند مخزن، برای هر دو قسمت جلویی موبایل و دسکتاپ و همچنین تمام منطق پشت آن بود. این یک تصمیم آگاهانه برای کار به این روش نبود، بلکه تنها نتیجه یک پروژه در حال گسترش بود که هیچ سرنخ معماری واقعی نداشت. Ledger Live پروژه‌ای است که اجزای مختلف را در یکی جمع‌آوری می‌کند تا بهترین و ایمن‌ترین برنامه را به کاربران نانو ارائه دهد و در پایگاه کد منعکس شد.

جریان هایی که ما در محل داشتیم در بهترین حالت پوسته پوسته بودند، بیشتر به دلیل این واقعیت است که ما چند سال پیش 6 یا 7 توسعه دهنده بودیم. از آنجایی که احزاب کمتری درگیر بودند، ارتباط بسیار آسان‌تر بود و ما با آن کنار آمدیم. با این حال، برخی از نکات دردناک در نحوه کار ما وجود داشت، به خصوص در مورد تجربه توسعه دهنده و فرآیند انتشار.

Dev Experience Bottlenecks

وابستگی ها

با توجه به ماهیت پروژه هایمان، ما همزمان روی چندین مخزن کار می کنیم و وابستگی هایی بین آنها وجود دارد. در اینجا یک مرور سریع وجود دارد:

کتابخانه‌های منبع باز لجر توسط منطق تجاری استفاده می‌شوند، که سپس توسط برنامه‌های دسکتاپ و موبایل استفاده می‌شود. اما آن برنامه ها همچنین از کتابخانه های منبع باز و با استفاده از دو نسخه مختلف از یک کتابخانه استفاده می کنند (مانند @ledgerhq/errors به عنوان مثال) برنامه را خراب می کند.

ما نیاز داشتیم که نسخه را از یک طرف برسانیم، سپس کتابخانه ها را منتشر کنیم (بله، به npm!!!)، سپس اگر کار نکرد دوباره امتحان کنید. ما شروع کردیم به تکیه کردن yalc به پروژه‌های Symlink، که تا زمانی که چندین لایه وابستگی نداشته باشیم (مثلاً از کتابخانه‌های منبع باز تا منطق کسب‌وکار و سپس از منطق کسب‌وکار تا برنامه‌ها) بیشتر مشکلی نداشت. ما به طور آزمایشی سعی کردیم با آن کار کنیم yarn link همچنین، اما به نظر می رسد که با React Native محکوم به فنا بود.

تست

انجام تست های یکپارچه سازی با آخرین کدهای پروژه های مختلف تقریبا غیرممکن بود. از آنجایی که ما نیاز داشتیم کتابخانه ها را در رجیستری منتشر کنیم، آزمایش همه اجزا با آخرین کد به روز یک کابوس بود.

ما همچنین مجبور بودیم چندین CI را با منطق تکراری حفظ کنیم.

تغییر زمینه

همیشه حرکت در اطراف چندین ویرایشگر کد / پروژه / دایرکتوری باعث شد که تجربه توسعه دهنده واقعا ضعیف به نظر برسد.

گلوگاه های فرآیند آزادسازی

نسخه بندی

مدیریت نسخه‌سازی پروژه‌های مختلف سخت است، به خصوص زمانی که چندین لایه وابستگی وجود دارد.

انتشار

ردیابی انتشار به دلیل تقسیم پروژه ها پیچیده بود و ما مجبور بودیم انتشار پروژه های مختلف را مدیریت کنیم.

به دلیل اینکه پروژه ها به مخازن مختلف تقسیم شده بودند، خودکار کردن فرآیند انتشار غیرممکن بود.

و البته، تحویل مداوم در این مرحله غیرقابل تصور بود.

راه حل ممکن ؟

با نگاهی به اطراف برای الهام گرفتن، به نظر می رسد یک معماری مخزن تک قطعه مرکزی است که ما از دست داده بودیم. روند توسعه بسیار بهتری را امکان پذیر می کند. ابزارهایی پیرامون این معماری ساخته شده اند که به ما کمک می کنند تا به بخش های گمشده دست یابیم (انتشار، اتوماسیون، نسخه سازی...).

اما، مخزن مونو چیست؟

در هسته خود، یک مخزن مونو پروژه ای است که تمام پروژه های مرتبط دیگر (برنامه ها، کتابخانه ها، ابزارها) را در یک پروژه پوشه / git محصور می کند. این اجازه می دهد تا مدیریت وابستگی بهتر، یکسان سازی ابزارها (مانند سبک های کد و پیکربندی های تایپ اسکریپ)، یکپارچه سازی پیوسته متمرکز، آزمایش یکپارچه سازی، نسخه یکنواخت بسته بندی استفاده شده (مثلاً واکنش نشان دهید)…

از آنجایی که این یک سیستم بسیار آگنوستیک است، برخی از ویژگی‌ها برای کشف و پیاده‌سازی برای ما باقی مانده است. امیدواریم ابزارهای انجمنی عالی وجود داشته باشند که می‌توانند به ما کمک کنند ارکستراسیون را به بیلدها اضافه کنیم (ساخت‌های متوالی، مفید برای CI)، نسخه‌سازی، تولید تغییرات... که آنچه را که در فرآیند انتشار از دست داده بودیم کامل می‌کند.

منفی

مخازن مونو در شرایطی که چندین توسعه‌دهنده یا تیمی از توسعه‌دهندگان به طور همزمان روی چندین پروژه کار می‌کنند و وابستگی‌هایی بین آنها وجود دارد، معنا پیدا می‌کند. با این حال، در مرحله راه‌اندازی لایه‌ای از پیچیدگی اضافه می‌کند (مخصوصاً با پروژه‌های در حال اجرا و در حال اجرا که دارای 4 سال سابقه و توسعه فعال هستند). شایان ذکر است، پروژه از نظر فضای دیسک بسیار بزرگتر می شود (مانند بسیار بزرگتر). همه پروژه ها اکنون در یک پوشه و همه وابستگی ها هستند. کدام آزمایش اجباری است؟ چه زمانی آنها را تحریک کنیم؟

مزایا

پس از ارزیابی زمان، هزینه و امکان‌سنجی جاه‌طلبی‌های ما، در اینجا برخی از مزایای مورد انتظار این انتقال وجود دارد:

• بهبود مدیریت وابستگی: با monorepo، مدیریت وابستگی ها بین پروژه های مختلف آسان تر است، زیرا همه آنها در یک مخزن ذخیره می شوند. این می تواند نیاز به راه حل هایی مانند پیوند نخ یا yalc، و اطمینان از اینکه همه پروژه ها از نسخه های صحیح وابستگی ها استفاده می کنند را آسان تر می کند.
• سازماندهی کد بهتر: یک monorepo می تواند سازماندهی کد را آسان تر کند، زیرا همه پروژه ها و وابستگی های آنها در یک مخزن ذخیره می شوند. درک اینکه چگونه پروژه های مختلف با هم هماهنگ می شوند و چگونه به یکدیگر بستگی دارند آسان تر است.
• تجربه توسعه‌دهنده بهبودیافته: یک monorepo می‌تواند کار توسعه‌دهندگان را بر روی چندین پروژه آسان‌تر کند، زیرا آنها نیازی به جابجایی بین پایگاه‌های کد یا مخازن مختلف ندارند. همچنین می‌تواند اجرای تست‌های یکپارچه‌سازی را آسان‌تر کند، زیرا تمام کدها در یک مخزن ذخیره می‌شوند.
• اتوماسیون پیشرفته و تحویل مداوم: با monorepo، خودکار کردن کارهایی مانند ساخت، آزمایش، و انتشار کد آسان‌تر است. این می تواند به ساده سازی فرآیند انتشار کمک کند و اجرای تحویل مداوم را آسان تر کند.
• افزایش سرعت توسعه از آنجایی که تیم‌های مختلف در یک مخزن کار می‌کنند، لازم نیست تا زمان انتشار منتظر بمانند تا نتیجه را تأیید کنند و ادغام را تسریع کنند.

نتیجه

به طور کلی، اجرای یک ساختار monorepo می‌تواند به بهبود فرآیند توسعه، ساده‌سازی فرآیند انتشار و افزایش تجربه توسعه‌دهنده کمک کند.

در پست‌های وبلاگ بعدی این مجموعه، شما را با نحوه انجام این پروژه مهاجرتی بزرگ، ابزارهایی که استفاده کردیم، انتخاب‌هایی که انجام دادیم، نتیجه و موارد دیگر آشنا خواهیم کرد. با قسمت دوم همراه باشید: ابزارها!

---

والنتین دی آلمیدا
تجربه توسعه‌دهنده و فناوری هسته - Ledger Live

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain