كيفية هيكلة مستودعات الأكواد: متعددة أو أحادية أو عضوية؟

الصورة من قبل يورين على Unsplash

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

إن فكرة وجود عدة مستودعات صغيرة هي أن الشفرة الخاصة بكل خدمة من تطبيقاتك الصغيرة يتم الاحتفاظ بها في مستودع خاص بها. من خلال الريبو الأحادي ، يمكنك الاحتفاظ بكود الشفرة في مستودع واحد ونشر الرمز كخدمات مصغرة.

إذن ما الذي يجب أن تستخدمه؟ يمكن أن يؤدي التصلب الشديد بشأن أي نهج واحد - دون النظر إلى الغرض من كل نهج واستخداماته - إلى نتائج سلبية على المدى الطويل. إذا كنت على دراية بموعد استخدام كل منها ، فبإمكانها زيادة إنتاجيتك وتحسين مشروعك.

لثني القواعد ، نحتاج أولاً أن نفهم سبب وجودها.

التوصية الشائعة هي أن يكون لديك مستودع مستقل لكل تطبيق / خدمة. لكن لماذا؟ نظرًا لوجود مستودع واحد لكل خدمة صغيرة ، فإننا نكتسب:

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

ولكن لماذا نشأت الحاجة إلى إعادة تركيب أحادية؟

من الواضح أن مقاربة الريبو المتعددة لها فوائدها. لكنه يأتي أيضًا مع التحديات الخاصة به ، خاصةً في المشاريع التي تحتوي على عدد كبير من الخدمات المصغرة التي تستخدم نفس الأطر واللغات والمجموعات التقنية وغيرها

بعض هذه التحديات هي:

  • فرض المعايير وأفضل الممارسات في جميع المستودعات. مع الريبو المتعدد ، تحتاج التغييرات في معايير الكود وأفضل الممارسات إلى تكرارها عبر المستودعات. من خلال الريبو الأحادي ، يمكن إجراء جميع التغييرات في مكان واحد.
  • جهد الحفاظ على المكونات المشتركة أو المشتركة. تتضمن تصحيحات الأمان وترقيات الإصدار وإصلاحات الأخطاء التأكد من إجراء هذه التغييرات في جميع المستودعات وأنها تعمل بسلاسة في كل مكان. (في ملاحظة جانبية ، الكود المتكرر في كل خدمة ينتفخ حجمه أيضًا.)
  • اختبار شامل من جانب إلى آخر مع خدمات مرتبطة أو وثيقة الصلة مباشرة من جهاز المطور. من خلال وجود كل الشفرة في مكان واحد ، نسهل عملية بدء تشغيل جميع الخدمات ذات الصلة وإجراء اختبارات شاملة.
  • عمليات نشر التعليمات البرمجية داخل المنشآت للشركات الأخرى. من خلال نشر الريبو الأحادي كخدمات ميكروية ، فإننا نوفر الوقت ونقلل من الجهد المتكرر المتمثل في تمهيد كل مستودع.

من الواضح أن هناك مزايا وعيوب لكلا النهجين ، وسيكون لكل نهج فوائده الخاصة في ظل ظروف مختلفة.

لذلك ، اعتمدنا نهج الحفاظ على المرونة واستخدام كل من repos و mono repos ، ولكن فقط بعد أن نفهم تمامًا لماذا اخترنا استخدام كل منها لكل خدمة. وقد أدى بنا ذلك إلى امتلاك عدة مستندات تحتوي على العديد من الخدمات المصغرة ، يتم فصلها بطريقة جعلت:

  • الصيانة والتحديثات سهلة وسريعة.
  • تحديد موقع رمز لتصحيح أو تغيير أكثر تنظيما.
  • على متن الزملاء الجدد أسهل.

كيف نقرر أي نوع من مستودع للاستخدام

لقد ساعدتنا الاعتبارات التالية في تحديد متى نستخدم re-monposes مقابل multi repos.

1. فكر في الكود الذي سيكون بمثابة أساس الخدمة.

ابدأ بتحديد أي أوجه تشابه في التعليمات البرمجية والصيانة والتحديثات. إذا كانت هناك عدة مستودعات تحتوي على كود مطابق ، فمن الأفضل ضمها في مستودع واحد.

تعد حرية كتابة التعليمات البرمجية بشكل مختلف ومستقل في إحدى الخدمات أحد مزايا المستودعات الصغيرة المتعددة. ولكن في كثير من الأحيان سيكون للخدمات عدد كبير من السقالات المتماثلة إذا كانت تستخدم نفس اللغة ، والإطار ، والتسجيل ، والبرامج النصية التمهيد ، والأدوات المتوسطة ، وما إلى ذلك. إعادة استخدام هذه السقالات المشتركة يوفر الوقت.

على سبيل المثال ، لدى Collect - أداة جمع البيانات الأساسية الخاصة بنا - خدمات مصغرة متعددة مبنية على إطار مماثل. هذه الخدمات مبنية على Node.js و Express و Parse Server. وهي تشترك في الكثير من المكتبات مثل Winston و Mongoose وغيرها من عمليات تكامل الجهات الخارجية. في وقت سابق ، عندما يكون لدى كل من هذه الخدمات مستودع خاص بها ، فإن تحديث أو إصلاح الخلل في أي من هذه الوحدات المشتركة يعني تحديث واختبار كل مستودع على حدة. كان هذا بطيئًا ومرهقًا.

ومع ذلك ، عندما تضربنا معًا في عملية إعادة أحادية ، أصبح اختبار الوحدات المشتركة وتحديثها أسهل وأسرع. أصبح تطبيق تصحيحات الأمان وفرض المعايير أمرًا سهلاً لأن المطورين يمكنهم القيام بجميع التغييرات في مكان واحد.

يتمثل الخطر المحتمل في إعادة الشراء الأحادي في أنه يمكن للمطور إعادة استخدام التعليمات البرمجية المكتوبة في الأصل لوحدة نمطية غير مرتبطة. عندما تشترك الوحدتان في الكود ، فإن التغيير في هذا الكود الشائع يمكن أن يؤدي إلى الأخطاء. إذا لم يتم التحقق من هذه الأخطاء ، يمكن أن تؤثر على خطوط الأنابيب CI / CD (التكامل المستمر والتسليم) من الخدمات الصغيرة غير ذات صلة. لتجنب مثل هذه المشكلات ، من المهم وجود مجموعة اختبار قوية في مكانها.

2. تحقق ما إذا كان لديك أي وحدات متميزة جدا عن بقية.

هل تقوم بتطوير وحدة تتطلب تقنية أو لغة أو إطار عمل أو ثبات مختلف تمامًا؟ ثم تقسيمه إلى مستودع منفصل سيكون أفضل.

في التجميع ، هناك خدمات تعالج معالجة الأحداث بكميات كبيرة. يحافظون على قوائم الانتظار وتنفيذ البرامج النصية المخصصة ولديهم آلية مختلفة تمامًا لمعالجة الأخطاء. تتم كتابة هذه الخدمات في Python ، وغالبًا ما تحتاج إلى القيام بمهام كثيفة وحدة المعالجة المركزية.

لذلك عندما كنا نفكر في إعادة هيكلة رمز التجميع ، أصبح الاحتفاظ بهذه الخدمات في إعادة تحديد منفصلة أمرًا بديهيًا. كانت هذه الخدمات مختلفة تمامًا عن المستودع الرئيسي لـ Collect (الموضح أعلاه). بينما كان المستودع الرئيسي للطلبات التي تواجه المستخدم ، فإن هذا الريبو كان يدور حول مهام الخلفية وعمليات الإعدام. أيضًا ، كانت إدارة التغيير في هذه الخدمات مختلفة ومعزولة عن المستودع الرئيسي.

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

3. النظر في عدم اليقين ، وبالتالي تواتر التغييرات التي قد تمر بها الخدمة.

عندما تبدأ العمل على شيء غير مؤكد إلى حد كبير (سواء فيما يتعلق بنطاق المشكلة أو التنفيذ نفسه) ، فإن امتلاك مستودع مختلف يمكن أن يمنحك السرعة والحرية اللذين تحتاجهما لاختبار الأشياء.

على سبيل المثال ، قل أنك تريد اختبار طريقة جديدة لمعالجة الصور لتحديد الكائنات. كنت ترغب في الانخراط في التعلم الآلي ، لكنك لا تزال غير متأكد من كيفية تطوره أو إذا كان بيان المشكلة سيتغير بشكل كبير. في هذه الحالة ، سيكون من الأفضل أن يكون لديك مستودع منفصل ومن ثم الوصول إلى حد اليقين. على العكس من ذلك ، إذا كنت تعتقد أن واجهة برمجة التطبيقات قد وصلت إلى الاستقرار وستبقى على حالها لفترة طويلة ، يمكنك إجراء مكالمة لدمجها مع أحد مستودعاتك الرئيسية.

تم نشر المدونة في الأصل على blog.socialcops.com. ما سبق هو كيفية تعاملنا مع قرارات مستودعنا. آمل أن يساعدك ذلك في التفكير من المبادئ الأولى إذا تعاملت مع هذه المشكلة. اشترك في نشرتنا الإخبارية لمزيد من التحديثات من SocialCops Engineering و Data Science Team.