مدينة الحندية

التحول إلى هندسة Monorepo

November 10, 2022

دقيقة

جدول المحتوى

مثال H2

المؤلف: روهان لوثرا
المحرر: بينيلا سوزان جاكوب

عقبة

بدأنا مشروعًا جديدًا قبل عام في CloudSek، وقمنا بتغيير بنيتنا من هندسة متجانسة وموجهة نحو الخدمة إلى بنية Microservice المناسبة. مع الخدمات المصغرة، كان لكل خدمة مستودعها الخاص وخط أنابيب CI CD المتصل بشبكة خدمة Kubernetes الخاصة بنا.

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

الحل

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

أشياء في السوق

نظرًا لأن المجموعة التقنية هي TS، سواء الواجهة الأمامية أو الخلفية، كان هناك إطاران للنظر فيهما. فيما يلي الأطر التي قمنا فيها بإجراء POC قبل المضي قدمًا:

توربو ريبو
ليرنا
نكسس

لقد اخترنا Nx، نظرًا لأنه يتمتع بقدرات جاهزة تدعم ReactJS و NestJS. بالإضافة إلى أنها تتمتع ببعض المزايا مقارنة بالحلول الأخرى، خاصة مع أوامر التعليمات البرمجية «المتأثرة».

إعداد NX

مع Nx، الأمر بسيط للغاية، ما عليك سوى تثبيت nx-cli عالميًا والبدء في إضافة التطبيقات.

$ npx create-nx-workspace - pm pnpm - خطأ تفاعلي - القاعدة الرئيسية الافتراضية - اسم my-workspace

نظرًا لأننا نستخدم NestJS، فلنقم بإنشاء تطبيقين و 2 libs

# قم بتثبيت البرنامج المساعد NestJS
تثبيت $ pnpm -D @nrwl /nest # التطبيقات
$ pnx g @nrwl /nest: اختبار التطبيق 1
$ pnx g @nrwl /nest: اختبار التطبيق #1 libs
$ pnx g @nrwl /nest:lib lib1
$ pnx g @nrwl /nest: lib lib2 # ابدأ تشغيل التطبيقات
بداية تشغيل $ pnpm: الكل

يجب أن تبدو بنية المجلد كما يلي:

مزايا استخدام Nx

نظرًا لأن الحفاظ على monorepo يمثل الكثير من المتاعب بسبب وجود الكثير من التعليمات البرمجية، فإن Nx يوفر طريقة للحصول على التغييرات فقط: متأثر

نوضح بمثال كيف تم استخدامه لمصلحتنا. في الإعداد، قمنا بإنشاء تطبيقين و 2 libs واستوردنا المكتبات في هذه التطبيقات. دعونا نرى الرسم البياني العام:

الرسم البياني بالدولار الأمريكي

Now if changes are made to only lib2: — الآن إذا تم إجراء تغييرات على lib2 فقط:

تأثر $ pnx: الرسم البياني - القاعدة = الرئيسي

As expected it only showed changes to test1 app. Similarly, if changes are made to lib2: — كما هو متوقع، أظهر فقط التغييرات على تطبيق test1. وبالمثل، إذا تم إجراء تغييرات على lib2:

تأثر $ pnx: الرسم البياني - القاعدة = الرئيسي

أوامر مع متأثر

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

الكرز على القمة

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

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

بناء Nx —

بناء NestJS -

الخاتمة

لا أحد يستطيع أن يعرف كل شيء، فنحن جميعًا نتعلم فقط من أخطائنا. وتعد Nx واحدة من أفضل أطر monorepo المتوفرة لـ TS/JS. في هذه المدونة، أوضحت كيف ساعدتنا Nx في إنشاء هيكل أفضل للحفاظ على الكود الخاص بنا وتعزيز خط الأنابيب الخاص بنا. بعض الفوائد الرئيسية التي حصلنا عليها من التحول إلى Nx -