اختبار Node.js المشاريع. الجزء 2. اختبار تقييم الأداء ، والتكامل المستمر وتحليل جودة الرمز

→ اختبار Node.js المشاريع. الجزء 1. اختبار تشريح وأنواع الاختبار

اليوم ، في الجزء الثاني من ترجمة المواد المخصصة لاختبار مشاريع Node.js ، سنتحدث عن تقييم فعالية الاختبارات وتحليل جودة الشفرة.

القسم 3. تقييم فعالية الاختبارات

19. تحقيق مستوى عالٍ بدرجة كافية من تغطية الشفرة مع الاختبارات من أجل اكتساب الثقة في التشغيل الصحيح. عادة ما تكون تغطية حوالي 80 ٪ تعطي نتائج جيدة.

توصيات

الغرض من الاختبار هو التأكد من أن المبرمج يمكنه مواصلة العمل بشكل منتج في المشروع ، والتأكد من أن ما تم فعله صحيح. من الواضح أنه كلما زاد حجم الشفرة المختبرة ، زادت الثقة في أن كل شيء يعمل كما ينبغي. يشير مؤشر تغطية الشفرة عن طريق الاختبارات إلى عدد الخطوط (الفروع ، الأوامر) التي تم فحصها بواسطة الاختبارات. ما ينبغي أن يكون هذا المؤشر؟ من الواضح أن ما بين 10 إلى 30٪ قليل للغاية لإعطاء الثقة بأن المشروع سيعمل دون أخطاء. من ناحية أخرى ، فإن الرغبة في تغطية الشفرة بنسبة 100٪ يمكن أن تكون باهظة الثمن للغاية ويمكنها صرف انتباه المطور عن أهم أجزاء البرنامج ، مما يجبره على البحث في الكود عن تلك الأماكن التي لا تصل إليها الاختبارات الحالية. إذا أعطيت إجابة أكثر اكتمالا على السؤال المتعلق بما ينبغي أن تكون عليه تغطية الشفرة عن طريق الاختبارات ، فيمكننا القول إن المؤشر الذي يجب أن نسعى جاهدين إليه يعتمد على التطبيق الذي يتم تطويره. على سبيل المثال ، إذا كنت تكتب برنامجًا للجيل القادم من Airbus A380 ، فإن 100٪ يعد مؤشرًا لم تتم مناقشته حتى. ولكن إذا قمت بإنشاء موقع على شبكة الإنترنت يتم عرض معارض كاريكاتورية به ، فمن المحتمل أن 50٪ من ذلك المبلغ سيكون بالفعل كثيرًا. على الرغم من أن خبراء الاختبار يقولون إن مستوى تغطية الشفرة مع الاختبارات التي يجب أن تهدف إليها يعتمد على المشروع ، إلا أن العديد منهم يذكرون رقم 80٪ ، وهو على الأرجح مناسب لمعظم التطبيقات. على سبيل المثال ، نحن هنا نتحدث عن شيء ما في المنطقة من 80 إلى 90٪ ، ووفقًا لمؤلف هذه المادة ، فإن تغطية 100٪ من الشفرة مع الاختبارات تجعله مشبوهًا ، حيث قد يشير إلى أن المبرمج يكتب الاختبارات فقط للحصول على رقم جميل في التقرير.

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

عواقب الانحراف عن التوصيات

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

مثال

إليك ما يبدو عليه تقرير تغطية الاختبار النموذجي.


تقرير تغطية الاختبار التي تم إنشاؤها بواسطة اسطنبول

النهج الصحيح

فيما يلي مثال لتعيين المستوى المرغوب فيه لتغطية اختبار كود المكون والمستوى العام لهذا المؤشر في Jest.


تحديد المستوى المطلوب من تغطية الشفرة مع اختبارات للمشروع بأكمله ولمكون محدد

20. فحص تقارير حول تغطية التعليمات البرمجية مع اختبارات لتحديد أجزاء غير محمية من التعليمات البرمجية وغيرها من الحالات الشاذة

توصيات

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

عواقب الانحراف عن التوصيات

إذا كنت لا تعرف أي أجزاء من التعليمات البرمجية لا تزال غير مختبرة ، فأنت لا تعرف من أين يمكن أن تتوقع المشاكل.

نهج خاطئ

انظر إلى التقرير التالي وفكر فيما يبدو غير عادي فيه.


تقرير يشير إلى سلوك غير عادي للنظام

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

21. قياس تغطية الرمز المنطقي مع الاختبارات باستخدام اختبار الطفرة

توصيات

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

هنا ، يمكن أن تأتي اختبارات التحوُّل في عوننا ، مما يسمح لنا بمعرفة مقدار الشفرة التي تم اختبارها بالفعل ، وليس فقط من قِبل نظام الاختبار. للاختبار التحولي ، يمكنك استخدام مكتبة Stryker JS. فيما يلي المبادئ التي تعمل بها:

1. هي تغيّر الكود عن قصد ، مما يخلق أخطاء فيه. على سبيل المثال ، newOrder.price===0 الرمز newOrder.price===0 إلى newOrder.price!=0 . وتسمى هذه "الأخطاء" الطفرات.
2. انها تدير الاختبارات. إذا تبين أنها مرت ، عندئذٍ لدينا مشاكل ، لأن الاختبارات لا تفي بمهمتها المتمثلة في اكتشاف الأخطاء ، و "المسوخ" ، كما يقولون ، "البقاء". إذا كانت الاختبارات تشير إلى وجود أخطاء في الكود ، فسيتم كل شيء بالترتيب - "المسوخ" "يموت".

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

عواقب الانحراف عن التوصيات

إذا كان المؤشر التقليدي لتغطية الشفرة عن طريق الاختبارات يشير إلى أن 85٪ من الشفرة مغطاة بالاختبارات ، فإن هذا لا يعني أن الاختبارات قادرة على اكتشاف الأخطاء في هذا الرمز.

نهج خاطئ

فيما يلي مثال على تغطية 100٪ من الشفرة مع الاختبارات ، والتي لم يتم اختبار الشفرة فيها بالكامل.

 function addNewOrder(newOrder) {   logger.log(`Adding new order ${newOrder}`);   DB.save(newOrder);   Mailer.sendMail(newOrder.assignee, `A new order was places ${newOrder}`);   return {approved: true}; } it("Test addNewOrder, don't use such test names", () => {   addNewOrder({asignee: "John@mailer.com",price: 120}); });//    100%, ,   ,     

النهج الصحيح

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


تقرير Stryker

تسمح نتائج هذا التقرير بمزيد من الثقة عن المؤشرات المعتادة للتغطية البرمجية مع الاختبارات للقول إن الاختبارات تعمل كما هو متوقع.

• الطفرة هي رمز تم تعديله عن عمد بواسطة مكتبة Stryker لاختبار فعالية الاختبار.
• يوضح عدد "المسوخ" "المسوخ" (المقتول) عدد عيوب الكود المنشأة عمداً ("المسوخ") التي تم تحديدها أثناء الاختبار.
• يتيح لك عدد "المسوخ" الناجحة (الناجحة) معرفة عدد اختبارات عيوب الكود التي لم يتم العثور عليها.

القسم 4. التكامل المستمر ، مؤشرات جودة الكود الأخرى

22. استفد من إمكانات linter وقاطع عملية إنشاء المشروع عندما يكتشف المشاكل التي يبلغون عنها

توصيات

اليوم ، تعتبر الأدوات اللينة من الأدوات القوية التي يمكنها تحديد مشكلات التعليمات البرمجية الخطيرة. يوصى ، بالإضافة إلى بعض قواعد الفحص الأساسية (مثل تلك التي يتم تنفيذها بواسطة الإضافات القياسية eslint-plugins و eslint-config-airbnb ) ، باستخدام قواعد متخصصة. على سبيل المثال ، هذه هي القواعد التي يتم تنفيذها عن طريق البرنامج المساعد eslint-plugin-chai-تتوقع للتحقق من صحة كود الاختبار ، وهذه هي القواعد من البرنامج المساعد eslint-plugin-وعد التي تتحكم في العمل مع الوعود ، وهذه هي القواعد من eslint-plugin-security التي تتحقق من التواجد أنه يحتوي على تعبيرات عادية خطيرة. هنا يمكنك أيضًا الإشارة إلى تسطير البرنامج المساعد eslint-plugin-you-dont-need-lodash-الشرطة ، والذي يسمح لك بالعثور على الكود في استخدام الأساليب من المكتبات الخارجية التي لها نظائرها في جافا سكريبت خالص.

عواقب الانحراف عن التوصيات

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

نهج خاطئ

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


ESLint يساعدك في العثور على خطأ في التعليمات البرمجية الخاصة بك

23. ردود فعل أسرع مع المطورين باستخدام التكامل المستمر المحلي

توصيات

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

يتيح لك بعض موفري حلول CI (دعنا نقول أن هذا ينطبق على CircleCI ) تشغيل خط أنابيب CI محليًا. يمكن لبعض الأدوات المدفوعة ، مثل Wallaby.js (يلاحظ المؤلف أنه غير متصل بهذا المشروع) ، الحصول بسرعة على معلومات قيمة حول جودة الشفرة. بالإضافة إلى ذلك ، يمكن للمطور ببساطة إضافة البرنامج النصي npm المناسب إلى package.json ، الذي يقوم بإجراء اختبارات جودة الكود (اختبارات ، تحليلات باستخدام linter ، يبحث عن الثغرات) ، ويستخدم الحزمة المتزامنة لتسريع عمليات الفحص. الآن ، من أجل التحقق الشامل من الشفرة ، سيكون من الكافي تنفيذ أمر واحد ، مثل npm run quality ، والحصول على تقرير على الفور. بالإضافة إلى ذلك ، إذا كانت اختبارات الشفرة تشير إلى وجود مشكلات ، فيمكنك إلغاء التعيينات باستخدام خطافات git (يمكن أن تكون مكتبة husky مفيدة لحل هذه المشكلة).

عواقب الانحراف عن التوصيات

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

النهج الصحيح

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

 "scripts": {   "inspect:sanity-testing": "mocha **/**--test.js --grep \"sanity\"",   "inspect:lint": "eslint .",   "inspect:vulnerabilities": "npm audit",   "inspect:license": "license-checker --failOn GPLv2",   "inspect:complexity": "plato .",     "inspect:all": "concurrently -c \"bgBlue.bold,bgMagenta.bold,yellow\" \"npm:inspect:quick-testing\" \"npm:inspect:lint\" \"npm:inspect:vulnerabilities\" \"npm:inspect:license\"" }, "husky": {   "hooks": {     "precommit": "npm run inspect:all",     "prepush": "npm run inspect:all"   } } 

24. إجراء اختبار نهاية إلى نهاية على مرآة بيئة الإنتاج واقعية

توصيات

في نظام Kubernetes الواسع ، لا يزال هناك إجماع على استخدام الأدوات المناسبة لنشر البيئات المحلية ، على الرغم من ظهور هذه الأدوات في كثير من الأحيان. تتمثل إحدى الطرق الممكنة هنا في تشغيل Kubernet "المصغّر" باستخدام أدوات مثل Minikube أو MicroK8s ، والتي تتيح لك إنشاء بيئات خفيفة الوزن تشبه البيئات الحقيقية. هناك طريقة أخرى تتمثل في اختبار المشروعات في بيئة Kubernetes "الحقيقية" البعيدة. يتيح بعض مزودي CI (مثل Codefresh ) التفاعل مع البيئات المدمجة في Kubernetes ، مما يبسط عمل خطوط أنابيب CI عند اختبار مشاريع العالم الحقيقي. البعض الآخر يسمح لك بالعمل مع بيئات Kubernetes البعيدة.

عواقب الانحراف عن التوصيات

يتطلب استخدام التقنيات المختلفة في الإنتاج والاختبار دعم نموذجين للتطوير ويؤدي إلى فصل فرق المبرمجين والمتخصصين في DevOps.

النهج الصحيح

فيما يلي مثال على سلسلة CI ، والتي ، كما يقولون ، أثناء إنشاء مجموعة Kubernetes (هذا مأخوذ من هنا ).

 deploy: stage: deploy image: registry.gitlab.com/gitlab-examples/kubernetes-deploy script: - ./configureCluster.sh $KUBE_CA_PEM_FILE $KUBE_URL $KUBE_TOKEN - kubectl create ns $NAMESPACE - kubectl create secret -n $NAMESPACE docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_REGISTRY_USER" --docker-password="$CI_REGISTRY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" - mkdir .generated - echo "$CI_BUILD_REF_NAME-$CI_BUILD_REF" - sed -e "s/TAG/$CI_BUILD_REF_NAME-$CI_BUILD_REF/g" templates/deals.yaml | tee ".generated/deals.yaml" - kubectl apply --namespace $NAMESPACE -f .generated/deals.yaml - kubectl apply --namespace $NAMESPACE -f templates/my-sock-shop.yaml environment: name: test-for-ci 

25. نسعى جاهدين لموازنة تنفيذ الاختبار

توصيات

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

عواقب الانحراف عن التوصيات

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

النهج الصحيح

بفضل التنفيذ المتوازي للاختبارات ، تتخطى مكتبة اختبار المخزن الموازي وإطار Jest بسهولة Mocha ( هذا هو مصدر هذه المعلومات).


اختبار أدوات اختبار الأداء

26. احم نفسك من المشكلات القانونية باستخدام التحقق من الترخيص والتحقق من كود الانتحال

توصيات

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

عواقب الانحراف عن التوصيات

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

النهج الصحيح

قم بتثبيت حزمة مدقق الترخيص محليًا أو في بيئة CI:

 npm install -g license-checker 

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

 license-checker --summary --failOn BSD 

فحص الترخيص

27. تحقق باستمرار من المشروع للتبعيات الضعيفة

توصيات

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

عواقب الانحراف عن التوصيات

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

النهج الصحيح

فيما يلي نتائج التحقق من المشروع باستخدام NPM Audit.


تقرير الضعف فحص حزمة

28. أتمتة تحديثات التبعية

توصيات

الطريق إلى الجحيم مرصوف بالنوايا الحسنة. هذه الفكرة قابلة للتطبيق بالكامل على package-lock.json ، والذي يستخدم بشكل افتراضي بحظر تحديثات الحزمة. يحدث هذا حتى في الحالات التي يتم فيها نقل المشروعات إلى حالة صحية بواسطة npm install npm update و npm update . هذا يؤدي ، في أحسن الأحوال ، إلى استخدام حزم قديمة أو ، في أسوأ الأحوال ، إلى ظهور رمز عرضة للخطر في المشروع. نتيجة لذلك ، تعتمد فرق التطوير إما على التحديث اليدوي للمعلومات حول الإصدارات المناسبة من الحزم ، أو على الأدوات المساعدة مثل ncu ، والتي يتم إطلاقها يدويًا مرة أخرى. تتم عملية تحديث التبعيات بشكل أفضل ، مع التركيز على استخدام الإصدارات الأكثر موثوقية من الحزم المستخدمة في المشروع. ليس هذا هو الحل الصحيح الوحيد ، ومع ذلك ، في أتمتة تحديثات الحزمة ، هناك بضعة أساليب جديرة بالملاحظة. الأول هو حقن شيء ما مثل فحص الحزم باستخدام تحديثات npm قديمة أو npm-check (ncu) في خط أنابيب CI. سيساعد ذلك في تحديد الحزم القديمة وتشجيع المطورين على ترقيتها. تتمثل الطريقة الثانية في استخدام الأدوات التجارية التي تتحقق من الرمز وتقدم طلبات السحب تلقائيًا بهدف تحديث التبعيات. في مجال تحديث التبعية التلقائي ، نواجه سؤالًا مثيرًا آخر يتعلق بسياسة التحديث. إذا تم تحديثه مع كل تصحيح جديد ، فقد يضع التحديث ضغطًا كبيرًا على النظام. إذا قمت بالتحديث فور إصدار الإصدار الرئيسي التالي من الحزمة ، فقد يؤدي ذلك إلى استخدام حلول غير مستقرة في المشروع (توجد ثغرات أمنية في العديد من الحزم في الأيام الأولى بعد الإصدار ، اقرأ عن الحادث باستخدام eslint-range). « », , . , 1.3.1, 1.3.2, 1.3.8.

, , , .

ncu , , , .


ncu

▍29. , Node.js

, Node.js-, , Node.js .

1. . — , , , Jenkins .
2. , Docker.
3. . , , . (, ), , , , .
4. , , , . — , , , .
5. , . , feature, — master, , ( ).
6. . , .
7. .
8. (, Docker) .
9. , , , . , node_modules .

, , .

▍30.

, . , , , Node.js , . CI-, , « ». , , , . , , mySQL, — Postgres. , Node.js, — 8, 9 10. , . CI-.

, , , . , , .

CI- Travis Node.js.

 language: node_js node_js: - "7" - "6" - "5" - "4" install: - npm install script: - npm run test 

ملخص

, , . , , .

أعزائي القراء! ?