مونوریپو یا مولتی‌ریپو

فهرست مطالب:

• خلاصه
  • مسئله
  • تصمیم
  • وضعیت
• جزئیات
  • مفروضات
  • قیود
  • مواضع
  • استدلال
  • پیامدها
• مرتبط
  • تصمیمات مرتبط
  • الزامات مرتبط
  • مصنوعات مرتبط
  • اصول مرتبط
• توضیحات

خلاصه

مسئله

پروژهٔ ما شامل توسعهٔ سه دستهٔ اصلی نرم‌افزار است:

• رابط‌های گرافیکی فرانت‌اند
• سرویس‌های میان‌افزار
• سرورهای بک‌اند

هنگام توسعه، سیستم کنترل نسخه (VCS) مدیریت کد منبع (SCM) ما git است.

باید انتخاب کنیم که چگونه از git برای سازمان‌دهی کد خود استفاده می‌کنیم.

انتخاب سطح بالا این است که به‌صورت «مونوریپو» یا «پلی‌ریپو» یا «ترکیبی» سازمان‌دهی کنیم:

• مونوریپو یعنی همهٔ بخش‌ها را در یک مخزن بزرگ قرار می‌دهیم
• پلی‌ریپو یعنی هر بخش را در مخزن خودش قرار می‌دهیم
• ترکیبی یعنی آمیزه‌ای از مونوریپو و پلی‌ریپو

برای اطلاعات بیشتر لطفاً https://github.com/joelparkerhenderson/monorepo-vs-polyrepo را ببینید

تصمیم

مونوریپو وقتی که یک سازمان/تیم/پروژه نسبتاً کوچک است و تکرار سریع اولویت بالاتری از حفظ پایداری دارد.

پلی‌ریپو وقتی که یک سازمان/تیم/پروژه نسبتاً بزرگ است و حفظ پایداری اولویت بالاتری از تکرار سریع دارد.

وضعیت

تصمیم گرفته شد. اگر/وقتی ابزارهای جدیدی برای مدیریت مونوریپوها و/یا پلی‌ریپوها در دسترس قرار گیرند، برای بازنگری آماده‌ایم.

جزئیات

مفروضات

همهٔ کدی که توسعه می‌دهیم برای محصولات یک سازمان است و برای عموم مردم نیست. یعنی کارگزار-معاملهگر (Broker-Dealer) هدفی مانند داشتن توسعه‌دهندگان داوطلب از عموم مردم ندارد.

قیود

قیود در 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 مدافعان بسیار قدرتمند مونوریپو در برابر پلی‌ریپو هستند، زیرا همهٔ محصولات اصلی را می‌توان هماهنگ توسعه/آزمون/استقرار داد.

توضیحات

هر توضیحی را اینجا اضافه کنید.