مستودع واحد مقابل مستودعات متعددة

المحتويات:

• الملخص
  • المسألة
  • القرار
  • الحالة
• التفاصيل
  • الافتراضات
  • القيود
  • المواقف
  • الحجة
  • التبعات
• ذو صلة
  • قرارات ذات صلة
  • متطلبات ذات صلة
  • نواتج ذات صلة
  • مبادئ ذات صلة
• ملاحظات

الملخص

المسألة

يتضمن مشروعنا تطوير ثلاث فئات رئيسية من البرمجيات:

• واجهات المستخدم الرسومية (GUI) الأمامية
• خدمات الوسيط (middleware)
• الخوادم الخلفية

عندما نطوّر، يكون نظام التحكم في الإصدارات (VCS) الخاص بإدارة الشيفرة المصدرية (SCM) لدينا هو git.

نحتاج إلى اختيار كيفية استخدام git لتنظيم شيفرتنا.

الخيار الأعلى مستوى هو التنظيم بوصفه «monorepo» أو «polyrepo» أو «هجين»:

• Monorepo يعني أننا نضع كل القطع في مستودع كبير واحد
• Polyrepo يعني أننا نضع كل قطعة في مستودعها الخاص
• الهجين يعني مزيجًا من monorepo وpolyrepo

لمزيد من المعلومات راجع https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

القرار

Monorepo عندما تكون المؤسسة/الفريق/المشروع صغيرًا نسبيًا، وتكون أولوية التكرار السريع أعلى من الحفاظ على الاستقرار.

Polyrepo عندما تكون المؤسسة/الفريق/المشروع كبيرًا نسبيًا، وتكون أولوية الحفاظ على الاستقرار أعلى من التكرار السريع.

الحالة

تم القرار. ونحن منفتحون على إعادة النظر إذا/عندما تتوفر أدوات جديدة لإدارة مستودعات monorepo و/أو polyrepo.

التفاصيل

الافتراضات

كل الشيفرة التي نطورها مخصصة لعروض مؤسسة واحدة وليست للجمهور العام. أي أن شركة الوساطة (Broker-Dealer) لا تهدف إلى وجود ما يشبه المطورين المتطوعين من الجمهور العام.

القيود

القيود موثقة جيدًا في https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

المواقف

نظرنا في مستودعات monorepo على طريقة Google وFacebook وغيرهما. ونعتقد أن أي مشكلات توسع في monorepo بعيدة جدًا في المستقبل، بحيث سنتمكن عند حاجتنا إليها من الاستفادة من الممارسات نفسها التي تستخدمها Google وFacebook.

ونظرنا في مستودعات polyrepo على طريقة مشاريع Git المفتوحة المصدر النموذجية، مثل Google Android وFacebook React وغيرهما. ونعتقد أنها الخيار الأفضل لمشاركة الجمهور العام (مثل أن يستطيع أي شخص في العالم العمل على الشيفرة) والتوافر الفردي (مثل أن يُستخدم المشروع وحده، دون أي قطع أخرى).

الحجة

عندما تكون المؤسسة/الفريق/المشروع صغيرًا نسبيًا، نختار monorepo، لأن أولوية التكرار السريع أعلى بكثير من الحفاظ على الاستقرار.

وعندما تكون المؤسسة/الفريق/المشروع كبيرًا نسبيًا، نختار polyrepo، لأن أولوية الحفاظ على الاستقرار أعلى بكثير من التكرار السريع.

التبعات

إذا كان هناك خط CI+CD قائم، فقد نحتاج إلى تعديله لاختبار عدة مشاريع داخل مستودع واحد.

قد يستغرق CI+CD وقتًا أطول في بناء كامل لمستودع monorepo، لأن CI+CD قد يبني كل المشاريع في مستودع monorepo.

إذا نمت المؤسسة/الفريق/المشروع، فستظهر لدى monorepo مشكلات في التوسع.

وقد تجعل مشكلات التوسع في monorepo الانتقال إلى polyrepo ذا قيمة متزايدة.

والانتقال من monorepo إلى polyrepo مهمة devops كبيرة، وستحتاج إلى تخطيط وإدارة وبرمجة.

ذو صلة

قرارات ذات صلة

سننشئ قرارات للأدوات ذات الصلة لإدارة مستودعات monorepo (مثل Google Bazel) وpolyrepo (مثل Lyft Refactorator).

متطلبات ذات صلة

نحتاج إلى تطوير خط CI+CD ليعمل جيدًا مع git.

نواتج ذات صلة

نتوقع أن يكون لتنظيم المستودع نواتج ذات صلة بالتهيئة وإدارة الإعدادات والاختبار ومجالات devops المماثلة.

مبادئ ذات صلة

سهل التراجع عنه. إذا لم ينجح monorepo في الممارسة، أو لم تُرده الإدارة، فمن السهل التحول إلى polyrepo.

هوس العميل. نقدّر وضع المشروع بين أيدي العملاء، ونعتقد أن monorepo يمكن أن يوصلنا إلى ذلك أسرع من polyrepo، ويساعدنا أيضًا على التكرار بسرعة أكبر.

التفكير الكبير. تدافع Google وFacebook بقوة شديدة عن monorepo على حساب polyrepo، لأن جميع العروض الأساسية يمكن تطويرها واختبارها ونشرها بتناسق.

ملاحظات

أضف أي ملاحظات هنا.