Node.js परियोजनाओं का परीक्षण। भाग 2. परीक्षण प्रदर्शन मूल्यांकन, निरंतर एकीकरण और कोड गुणवत्ता विश्लेषण

→ Node.js परियोजनाओं का परीक्षण। भाग 1. परीक्षण शरीर रचना और परीक्षण प्रकार

आज, Node.js परियोजनाओं के परीक्षण के लिए समर्पित सामग्री के अनुवाद के दूसरे भाग में, हम परीक्षणों की प्रभावशीलता का मूल्यांकन करने और कोड की गुणवत्ता का विश्लेषण करने के बारे में बात करेंगे।

खंड 3. परीक्षणों की प्रभावशीलता का मूल्यांकन

▍19। अपने सही संचालन में विश्वास हासिल करने के लिए परीक्षणों के साथ पर्याप्त रूप से उच्च स्तरीय कोड कवरेज प्राप्त करें। आमतौर पर लगभग 80% कवरेज अच्छे परिणाम देता है।

सिफारिशें

परीक्षण का उद्देश्य यह सुनिश्चित करना है कि प्रोग्रामर परियोजना पर उत्पादक रूप से काम करना जारी रख सकता है, यह सुनिश्चित करता है कि जो पहले से किया गया है वह सही है। जाहिर है, परीक्षण किए गए कोड की मात्रा जितनी अधिक होगी, आत्मविश्वास उतना ही मजबूत होगा कि सब कुछ उसी तरह काम करता है जैसा कि उसे करना चाहिए। परीक्षणों द्वारा कोड कवरेज का संकेतक इंगित करता है कि परीक्षणों द्वारा कितनी लाइनें (शाखाएं, कमांड) जांची गई थीं। यह संकेतक क्या होना चाहिए? यह स्पष्ट है कि 10-30% यह विश्वास देने के लिए बहुत कम है कि परियोजना त्रुटियों के बिना काम करेगी। दूसरी ओर, परीक्षणों के साथ कोड की 100% कवरेज की इच्छा बहुत महंगी हो सकती है और सबसे महत्वपूर्ण कार्यक्रम के टुकड़ों से डेवलपर को विचलित कर सकती है, जिससे वह उन स्थानों पर कोड देखने के लिए मजबूर हो जाता है जो मौजूदा परीक्षण तक नहीं पहुंचते हैं। यदि आप इस सवाल का अधिक पूर्ण उत्तर देते हैं कि परीक्षणों के साथ कोड का कवरेज क्या होना चाहिए, तो हम कह सकते हैं कि जिस संकेतक के लिए हमें प्रयास करना चाहिए वह विकसित होने वाले अनुप्रयोग पर निर्भर करता है। उदाहरण के लिए, यदि आप अगली पीढ़ी के एयरबस ए 380 के लिए सॉफ्टवेयर लिख रहे हैं, तो 100% एक संकेतक है जिस पर चर्चा भी नहीं की जाती है। लेकिन यदि आप एक वेबसाइट बनाते हैं जिस पर कैरिकेचर गैलरी प्रदर्शित की जाएंगी, तो शायद 50% पहले से ही बहुत कुछ है। हालांकि परीक्षण विशेषज्ञों का कहना है कि परीक्षण के साथ कोड कवरेज का स्तर जिसे आपको लक्ष्य करना चाहिए, परियोजना पर निर्भर करता है, उनमें से कई 80% के आंकड़े का उल्लेख करते हैं, जो संभवतः अधिकांश अनुप्रयोगों के लिए उपयुक्त है। उदाहरण के लिए, यहां हम 80-90% के क्षेत्र में कुछ के बारे में बात कर रहे हैं, और, इस सामग्री के लेखक के अनुसार, परीक्षणों के साथ कोड का 100% कवरेज उसे संदिग्ध बनाता है, क्योंकि यह संकेत दे सकता है कि प्रोग्रामर केवल पाने के लिए परीक्षण लिखता है रिपोर्ट में सुंदर संख्या।

कोड कवरेज परीक्षणों के संकेतकों का उपयोग करने के लिए, आपको निरंतर एकीकरण (CI, सतत एकीकरण) के लिए अपने सिस्टम को ठीक से कॉन्फ़िगर करने की आवश्यकता होगी। यह अनुमति देगा, यदि संबंधित संकेतक परियोजना की विधानसभा को रोकने के लिए एक निश्चित सीमा तक नहीं पहुंचता है। परीक्षण कवरेज जानकारी एकत्र करने के लिए जेस्ट को कॉन्फ़िगर करने का तरीका यहां दिया गया है। इसके अलावा, आप कवरेज थ्रेसहोल्ड को पूरे कोड के लिए कॉन्फ़िगर नहीं कर सकते हैं, लेकिन व्यक्तिगत घटकों पर ध्यान केंद्रित कर सकते हैं। इसके अलावा, परीक्षण कवरेज में कमी का पता लगाने पर विचार करें। यह तब होता है, उदाहरण के लिए, जब किसी प्रोजेक्ट में नया कोड जोड़ते हैं। इस सूचक का नियंत्रण डेवलपर्स को परीक्षण किए गए कोड की मात्रा बढ़ाने या कम से कम मौजूदा स्तर पर इस मात्रा को बनाए रखने के लिए प्रोत्साहित करेगा। पूर्वगामी के मद्देनजर, परीक्षणों द्वारा कोड का कवरेज केवल एक संकेतक है, जो कि निर्धारित है, जो परीक्षणों की विश्वसनीयता का पूरी तरह से मूल्यांकन करने के लिए पर्याप्त नहीं है। इसके अलावा, जैसा कि नीचे दिखाया गया है, इसके उच्च स्तरों का अभी तक यह मतलब नहीं है कि कोड "परीक्षणों से ढका हुआ" वास्तव में जाँच की गई है।

सिफारिशों से विचलन का परिणाम

कोड की उच्च गुणवत्ता और परीक्षण से संबंधित संकेतक संबंधित हाथ पर हाथ में प्रोग्रामर का आत्मविश्वास। एक प्रोग्रामर मदद नहीं कर सकता, लेकिन त्रुटियों से डर सकता है यदि उसे नहीं पता है कि उसकी परियोजना के लिए अधिकांश कोड परीक्षणों द्वारा कवर किया गया है। ये चिंताएँ आपके प्रोजेक्ट को धीमा कर सकती हैं।

उदाहरण

यहां एक विशिष्ट परीक्षण कवरेज रिपोर्ट दिखती है।


इस्तांबुल द्वारा बनाई गई टेस्ट कवरेज रिपोर्ट

सही दृष्टिकोण

जेस्ट में घटक कोड के परीक्षण कवरेज के वांछित स्तर और इस सूचक के सामान्य स्तर को स्थापित करने का एक उदाहरण यहां दिया गया है।


संपूर्ण परियोजना के लिए और एक विशिष्ट घटक के लिए कोड कवरेज के वांछित स्तर को निर्धारित करना

▍20। कोड और अन्य विसंगतियों के असुरक्षित भागों की पहचान करने के लिए परीक्षणों के साथ कोड कवरेज पर रिपोर्ट की जाँच करें

सिफारिशें

कुछ समस्याएं विभिन्न प्रकार की त्रुटि पहचान प्रणालियों के माध्यम से खिसक जाती हैं। पारंपरिक उपकरणों का उपयोग करके ऐसी चीजों का पता लगाना मुश्किल हो सकता है। शायद यह वास्तविक त्रुटियों पर लागू नहीं होता है। बल्कि, हम अप्रत्याशित अनुप्रयोग व्यवहार के बारे में बात कर रहे हैं, जिसके विनाशकारी परिणाम हो सकते हैं। उदाहरण के लिए, यह अक्सर ऐसा होता है कि कोड के कुछ टुकड़े या तो कभी उपयोग नहीं किए जाते हैं या शायद ही कभी कहा जाता है। उदाहरण के लिए, आपको लगता है कि PricingCalculator वर्ग के तंत्र का उपयोग हमेशा किसी उत्पाद की कीमत निर्धारित करने के लिए किया जाता है, लेकिन वास्तव में यह पता चलता है कि इस वर्ग का उपयोग बिल्कुल नहीं किया जाता है, और डेटाबेस में 10,000 उत्पादों के रिकॉर्ड हैं, और ऑनलाइन स्टोर में जहां सिस्टम का उपयोग किया जाता है। बहुत सारी बिक्री ... परीक्षणों के साथ कोड कवरेज के बारे में रिपोर्ट डेवलपर को यह समझने में मदद करती है कि क्या आवेदन उस तरह काम करता है जैसे उसे काम करना चाहिए। इसके अलावा, रिपोर्टों से आप यह पता लगा सकते हैं कि कौन से प्रोजेक्ट कोड का परीक्षण नहीं किया गया है। यदि आप एक सामान्य संकेतक पर ध्यान केंद्रित करते हैं जो इंगित करता है कि परीक्षण 80% कोड को कवर करते हैं, तो आपको यह पता नहीं चल सकता है कि क्या आवेदन के महत्वपूर्ण भागों का परीक्षण किया जा रहा है। इस तरह की रिपोर्ट उत्पन्न करने के लिए, परीक्षण को चलाने के लिए आपके द्वारा उपयोग किए जाने वाले टूल को ठीक से कॉन्फ़िगर करने के लिए पर्याप्त है। ऐसी रिपोर्ट आमतौर पर बहुत सुंदर लगती हैं, और उनका विश्लेषण, जिसमें अधिक समय नहीं लगता है, आपको हर तरह के आश्चर्य का पता लगाने की अनुमति देता है।

सिफारिशों से विचलन के परिणाम

यदि आपको पता नहीं है कि आपके कोड के कौन से हिस्से अप्रयुक्त हैं, तो आप यह नहीं जानते हैं कि आप कहाँ समस्याओं की उम्मीद कर सकते हैं।

गलत दृष्टिकोण

अगली रिपोर्ट को देखें और सोचें कि इसमें क्या असामान्य है।


असामान्य प्रणाली व्यवहार का संकेत देने वाली रिपोर्ट

रिपोर्ट एक वास्तविक एप्लिकेशन उपयोग परिदृश्य पर आधारित है और आपको सिस्टम पर लॉग इन करने वाले उपयोगकर्ताओं के साथ जुड़े असामान्य प्रोग्राम व्यवहार को देखने की अनुमति देती है। अर्थात्, सिस्टम में प्रवेश करने के लिए अप्रत्याशित रूप से बड़ी संख्या में असफल प्रयास सफल लोगों की तुलना में आपकी आंख को पकड़ते हैं। परियोजना का विश्लेषण करने के बाद, यह पता चला कि इसका कारण फ्रंटएंड में त्रुटि थी, जिसके कारण परियोजना के इंटरफ़ेस भाग ने सिस्टम में प्रवेश करने के लिए सर्वर एपीआई को लगातार अनुरोध भेजे।

▍21। म्यूटेशन परीक्षण का उपयोग करके परीक्षणों के साथ तार्किक कोड कवरेज को मापें

सिफारिशें

पारंपरिक बेंचमार्किंग मेट्रिक्स अविश्वसनीय हो सकते हैं। इसलिए, रिपोर्ट में 100% का आंकड़ा हो सकता है, लेकिन साथ ही, परियोजना के सभी कार्य गलत मानों को वापस कर देंगे। यह कैसे समझा जाए? तथ्य यह है कि परीक्षणों द्वारा कोड कवरेज का संकेतक केवल यह बताता है कि परीक्षण प्रणाली के नियंत्रण के तहत कोड की कौन सी पंक्तियों को निष्पादित किया गया था, लेकिन यह इस बात पर निर्भर नहीं करता है कि क्या कुछ सही मायने में सत्यापित किया गया है, यानी कि परीक्षण के बयान क्या थे कोड के परिणामों की शुद्धता की जाँच करना। यह एक ऐसे व्यक्ति से मिलता-जुलता है, जो विदेश में व्यापार यात्रा से लौट रहा है, अपने पासपोर्ट में टिकट दिखाता है। स्टैम्प्स साबित करते हैं कि वह कहीं चला गया, लेकिन वे इस बारे में कुछ नहीं कहते कि क्या वह एक व्यापार यात्रा पर गया था।

यहां, उत्परिवर्तन परीक्षण हमारी सहायता के लिए आ सकते हैं, जो हमें यह पता लगाने की अनुमति देते हैं कि वास्तव में कितना कोड का परीक्षण किया गया था, और न केवल परीक्षण प्रणाली द्वारा दौरा किया गया था। म्यूटेशनल टेस्टिंग के लिए, आप स्ट्राइकर जेएस लाइब्रेरी का उपयोग कर सकते हैं। यहां वे सिद्धांत हैं जिनके द्वारा यह काम करता है:

1. वह जानबूझकर कोड बदलता है, उसमें त्रुटियां पैदा करता है। उदाहरण के लिए, कोड 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%, ,   ,     

सही दृष्टिकोण

यहाँ स्ट्राइकर लाइब्रेरी द्वारा उत्परिवर्तन परीक्षण रिपोर्ट प्रस्तुत की गई है। यह आपको यह पता लगाने की अनुमति देता है कि कितना कोड परीक्षण नहीं किया गया है (यह "जीवित" "म्यूटेंट" की संख्या से संकेत मिलता है)।


स्ट्राइकर रिपोर्ट

इस रिपोर्ट के परिणाम परीक्षणों के साथ कोड कवरेज के सामान्य संकेतकों की तुलना में अधिक आत्मविश्वास के साथ यह कहने की अनुमति देते हैं कि परीक्षण अपेक्षित रूप से काम करते हैं।

• एक म्यूटेशन कोड है जिसे स्ट्रीकर लाइब्रेरी द्वारा जानबूझकर संशोधित किया गया है ताकि परीक्षण की प्रभावशीलता का परीक्षण किया जा सके।
• "मारे गए" "म्यूटेंट" (मारे गए) की संख्या जानबूझकर बनाए गए कोड दोषों ("म्यूटेंट") की संख्या दर्शाती है जिन्हें परीक्षण के दौरान पहचाना गया था।
• "जीवित" "म्यूटेंट" (जीवित) की संख्या आपको यह पता लगाने की अनुमति देती है कि कितने कोड दोष परीक्षण नहीं मिले हैं।

खंड 4. निरंतर एकीकरण, अन्य कोड गुणवत्ता संकेतक

▍ 22। लिंटर की क्षमताओं का लाभ उठाएं और परियोजना की निर्माण प्रक्रिया को बाधित करें जब यह उन समस्याओं का पता लगाता है जो वे रिपोर्ट करते हैं

सिफारिशें

आज, लिंटर शक्तिशाली उपकरण हैं जो गंभीर कोड समस्याओं की पहचान कर सकते हैं। यह अनुशंसा की जाती है, कुछ बुनियादी लाइनिंग नियमों के अलावा (जैसे कि एस्लिंट-प्लगइन-मानक और एस्लिंट-कॉन्फिग-एयरबीएनबी प्लगइन्स द्वारा कार्यान्वित), विशेष नियमों का उपयोग करें। उदाहरण के लिए, ये टेस्ट कोड की शुद्धता को सत्यापित करने के लिए eslint-plugin-chai-उम्मीद प्लगइन के माध्यम से लागू किए गए नियम हैं, ये eslint-plugin-वादा प्लगइन से नियम हैं जो वादों के साथ काम को नियंत्रित करते हैं, ये eslint-plugin-security से नियम हैं जो उपस्थिति के लिए कोड की जांच करते हैं इसमें खतरनाक नियमित अभिव्यक्ति शामिल हैं। यहां आप एस्लिंट-प्लगइन-यू-नॉट-नीड-लॉज-अंडरस्कोर प्लग-इन का भी उल्लेख कर सकते हैं, जो आपको बाहरी पुस्तकालयों से विधियों का उपयोग कोड में खोजने की अनुमति देता है, जिसमें शुद्ध जावास्क्रिप्ट में एनालॉग होते हैं।

सिफारिशों से विचलन के परिणाम

एक बरसात का दिन आ गया है, परियोजना उत्पादन में लगातार विफलताएं देती है, और लॉग में त्रुटि ढेर के बारे में कोई जानकारी नहीं है। क्या हुआ? जैसा कि यह निकला, एक अपवाद के रूप में कोड क्या फेंकता है, वास्तव में त्रुटि की वस्तु नहीं है। नतीजतन, स्टैक के बारे में जानकारी लॉग में नहीं मिलती है। तथ्य की बात के रूप में, ऐसी स्थिति में, प्रोग्रामर या तो दीवार के खिलाफ मार सकता है या, बहुत बेहतर, लिंटर को स्थापित करने में 5 मिनट खर्च कर सकता है, जो आसानी से समस्या का पता लगाएगा और भविष्य में उत्पन्न होने वाली समान परेशानियों से परियोजना का बीमा कर सकता है।

गलत दृष्टिकोण

यहाँ वह कोड है, जो अनजाने में, एक साधारण वस्तु को एक अपवाद के रूप में फेंक देता है, जबकि यहाँ आपको एक प्रकार की Error । अन्यथा, स्टैक के बारे में डेटा लॉग में नहीं मिलेगा। ESLint इन समस्याओं से बचने में मदद करके उत्पादन समस्याओं का कारण बन सकता है।


ESLint आपको अपने कोड में एक बग ढूंढने में मदद करता है

▍23। स्थानीय निरंतर एकीकरण का उपयोग कर डेवलपर्स के साथ तेज़ प्रतिक्रिया

सिफारिशें

निरंतर एकीकरण की एक केंद्रीकृत प्रणाली का उपयोग करना, जो कोड की गुणवत्ता को नियंत्रित करने में मदद करता है, इसका परीक्षण करता है, लिंटर का उपयोग करके, कमजोरियों के लिए इसकी जांच करता है? यदि हां, तो सुनिश्चित करें कि डेवलपर्स इस प्रणाली को स्थानीय रूप से चला सकते हैं। यह उन्हें तुरंत अपने कोड की जांच करने की अनुमति देगा, जो प्रतिक्रिया को गति देता है और परियोजना के विकास के समय को कम करता है। ऐसा क्यों है? एक प्रभावी विकास और परीक्षण प्रक्रिया में कई चक्रीय रूप से दोहराए जाने वाले ऑपरेशन शामिल हैं। कोड का परीक्षण किया जाता है, फिर डेवलपर एक रिपोर्ट प्राप्त करता है, फिर, यदि आवश्यक हो, तो कोड को फिर से चालू किया जाता है, जिसके बाद सब कुछ दोहराया जाता है। जितनी तेजी से फीडबैक लूप काम करता है, उतनी ही तेजी से डेवलपर्स को कोड परीक्षण पर रिपोर्ट प्राप्त होती है, इस कोड के सुधार के अधिक पुनरावृत्तियों वे प्रदर्शन कर सकते हैं। यदि परीक्षण रिपोर्ट प्राप्त करने में बहुत समय लगता है, तो इससे खराब गुणवत्ता हो सकती है। मान लीजिए कि कोई किसी मॉड्यूल पर काम कर रहा था, तो किसी और चीज़ पर काम करना शुरू कर दिया, फिर मॉड्यूल पर एक रिपोर्ट प्राप्त की, जो इंगित करता है कि मॉड्यूल को सुधारने की आवश्यकता है। हालांकि, पहले से ही पूरी तरह से अलग-अलग मामलों पर कब्जा कर लिया गया है, डेवलपर समस्या मॉड्यूल पर पर्याप्त ध्यान नहीं देगा।

कुछ CI समाधान प्रदाता ( मान लें कि यह CircleCI पर लागू होता है) आपको स्थानीय स्तर पर CI पाइपलाइन चलाने देता है। कुछ भुगतान किए गए उपकरण, जैसे Wallaby.js (लेखक ने नोट किया कि वह इस परियोजना से जुड़ा नहीं है), जल्दी से कोड की गुणवत्ता के बारे में बहुमूल्य जानकारी प्राप्त कर सकते हैं। इसके अलावा, डेवलपर package.json में उचित npm स्क्रिप्ट जोड़ सकता है। Json, जो कोड गुणवत्ता जांच (परीक्षण, एक लाइनर के साथ विश्लेषण, कमजोरियों की तलाश करता है) करता है, और यहां तक ​​कि चेक को गति देने के लिए समवर्ती पैकेज का उपयोग करता है। अब, कोड की व्यापक रूप से जांच करने के लिए, यह एक कमांड को निष्पादित करने के लिए पर्याप्त होगा, जैसे npm run quality , और तुरंत एक रिपोर्ट प्राप्त करना। इसके अलावा, यदि कोड परीक्षणों से पता चलता है कि इसमें समस्याएं हैं, तो आप गिट हुक (इस समस्या को हल करने के लिए हस्की लाइब्रेरी उपयोगी हो सकती है) का उपयोग कर रद्द कर सकते हैं।

सिफारिशों से विचलन के परिणाम

यदि कोई डेवलपर इस कोड को लिखने के एक दिन बाद कोड की गुणवत्ता पर एक रिपोर्ट प्राप्त करता है, तो इस तरह की रिपोर्ट औपचारिक दस्तावेज की तरह कुछ में बदल जाती है, और कोड परीक्षण काम से अलग हो जाएगा, न कि इसका प्राकृतिक हिस्सा बन जाएगा।

सही दृष्टिकोण

यहां एक एनपीएम स्क्रिप्ट है जो कोड की गुणवत्ता की जांच करती है। जाँच करना समानांतर है। रिपॉजिटरी में नया कोड भेजने की कोशिश करने पर स्क्रिप्ट निष्पादित होती है। इसके अलावा, डेवलपर इसे अपनी पहल पर लॉन्च कर सकता है।

 "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। यथार्थवादी उत्पादन पर्यावरण दर्पण पर एंड-टू-एंड परीक्षण करें

सिफारिशें

विशाल कुबेरनेट्स पारिस्थितिकी तंत्र में, अभी भी ऐसे उपकरणों का उपयोग करने के लिए आम सहमति है जो स्थानीय वातावरण को तैनात करने के लिए उपयुक्त हैं, हालांकि ऐसे उपकरण अक्सर दिखाई देते हैं। यहां एक संभावित दृष्टिकोण मिनिक्यूब या माइक्रोके 8 जैसे उपकरणों का उपयोग करके "कम से कम" कुबेरनेट को चलाने के लिए है, जो आपको वास्तविक वातावरण के समान हल्के वातावरण बनाने की अनुमति देता है। एक अन्य दृष्टिकोण दूर-दराज के "वास्तविक" कुबेरनेट्स वातावरण में परियोजनाओं का परीक्षण करना है। कुछ CI प्रदाता (जैसे कोडफ्रेश ) अंतर्निर्मित कुबेरनेट्स के साथ बातचीत करना संभव बनाते हैं, जो वास्तविक दुनिया की परियोजनाओं का परीक्षण करते समय CI पाइपलाइनों के काम को सरल बनाता है। अन्य आपको दूरस्थ कुबेरनेट्स वातावरण के साथ काम करने की अनुमति देते हैं।

सिफारिशों से विचलन के परिणाम

उत्पादन और परीक्षण में विभिन्न तकनीकों के उपयोग के लिए दो विकास मॉडल के समर्थन की आवश्यकता होती है और प्रोग्रामर और डेओप्स विशेषज्ञों की टीमों के अलगाव की ओर जाता है।

सही दृष्टिकोण

यहाँ एक CI श्रृंखला का एक उदाहरण है, जो, जैसा कि वे कहते हैं, मक्खी पर एक कुबेरनेट क्लस्टर बनाता है (यह यहां से लिया गया है )।

 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 यूनिट परीक्षणों में चल रहा है जो प्रोसेसर का गहनता से उपयोग करते हैं, बहुत अधिक समय लगता है। और ऐसे परीक्षणों को अक्सर प्रदर्शन करने की आवश्यकता होती है। सौभाग्य से, परीक्षण चलाने के लिए आधुनिक उपकरण ( जेस्ट , एवीए , मोचा के लिए एक विस्तार ) और सीआई प्लेटफॉर्म कई प्रक्रियाओं का उपयोग करके समानांतर में परीक्षण चला सकते हैं, जो परीक्षण रिपोर्ट प्राप्त करने की गति में काफी सुधार कर सकते हैं। कुछ CI प्लेटफॉर्म भी जानते हैं कि कंटेनरों के बीच परीक्षणों को कैसे समानांतर किया जाए, जो फीडबैक लूप को और बेहतर बनाता है। परीक्षण, स्थानीय या दूरस्थ के निष्पादन को सफलतापूर्वक समानांतर करने के लिए, परीक्षणों को एक दूसरे पर निर्भर नहीं होना चाहिए। स्टैंडअलोन परीक्षण समस्याओं के बिना विभिन्न प्रक्रियाओं में चलाया जा सकता है।

सिफारिशों से विचलन के परिणाम

नई परियोजना सुविधाओं पर काम करते समय रिपॉजिटरी में कोड भेजने के एक घंटे बाद परीक्षा परिणाम प्राप्त करना परीक्षा परिणामों की उपयोगिता को कम करने का एक शानदार तरीका है।

सही दृष्टिकोण

परीक्षणों के समानांतर निष्पादन के लिए धन्यवाद, मोचा-समानांतर-परीक्षण पुस्तकालय और जेस्ट फ्रेमवर्क आसानी से मोचा को बायपास करता है ( यह इस जानकारी का स्रोत है)।


परीक्षण प्रदर्शन परीक्षण उपकरण

▍26। लाइसेंस सत्यापन और साहित्यिक चोरी कोड सत्यापन का उपयोग करके अपने आप को कानूनी मुद्दों से बचाएं

सिफारिशें

शायद अब आप विशेष रूप से कानून और साहित्यिक चोरी की समस्याओं से चिंतित नहीं हैं। हालांकि, समान समस्याओं के लिए अपने प्रोजेक्ट की जांच क्यों नहीं की गई? ऐसे निरीक्षणों को व्यवस्थित करने के लिए कई उपकरण उपलब्ध हैं। उदाहरण के लिए, ये लाइसेंस-चेकर और साहित्यिक चोरी-चेकर हैं (यह एक वाणिज्यिक पैकेज है, लेकिन इसके मुफ्त उपयोग की संभावना है)। इस तरह के चेक को सीआई पाइपलाइन में एकीकृत करना और परियोजना की जांच करना आसान है, उदाहरण के लिए, सीमित लाइसेंस के साथ निर्भरता की उपस्थिति के लिए, या स्टैकऑवरफ्लो से कॉपी किए गए कोड की उपस्थिति के लिए और शायद किसी और के कॉपीराइट का उल्लंघन।

सिफारिशों से विचलन के परिणाम

डेवलपर, अनजाने में, एक लाइसेंस के साथ पैकेज का उपयोग कर सकता है जो उसकी परियोजना के लिए उपयुक्त नहीं है, या वाणिज्यिक कोड की प्रतिलिपि बना सकता है, जिससे कानूनी समस्याएं हो सकती हैं।

सही दृष्टिकोण

स्थानीय स्तर पर या CI वातावरण में लाइसेंस-चेकर पैकेज स्थापित करें:

 npm install -g license-checker 

हम इसके साथ लाइसेंस की जाँच करेंगे, और यदि वह कुछ ऐसा पाता है जो हमें सूट नहीं करता है, तो हम चेक को असफल मान लेंगे। सीआई प्रणाली, यह पता लगाने पर कि लाइसेंस की जाँच करते समय कुछ गलत हो गया है, परियोजना विधानसभा को रोक देगा।

 license-checker --summary --failOn BSD 

लाइसेंस की जाँच

▍27। कमजोर निर्भरता के लिए परियोजना की लगातार जांच करें

सिफारिशें

यहां तक ​​कि अत्यधिक सम्मानित और विश्वसनीय पैकेज, जैसे एक्सप्रेस, में कमजोरियां हैं। ऐसी कमजोरियों की पहचान करने के लिए, आप विशेष उपकरणों का उपयोग कर सकते हैं - जैसे npm संकुल के ऑडिटिंग के लिए मानक उपकरण या व्यावसायिक snyk प्रोजेक्ट, जिसका एक नि: शुल्क संस्करण है। इन जाँचों को, दूसरों के साथ, CI पाइपलाइन का हिस्सा बनाया जा सकता है।

सिफारिशों से विचलन के परिणाम

विशेष साधनों का उपयोग किए बिना अपनी परियोजना को उसकी निर्भरता की कमजोरियों से बचाने के लिए, आपको ऐसी कमजोरियों के बारे में लगातार प्रकाशनों की निगरानी करनी होगी। यह बहुत समय लेने वाला कार्य है।

सही दृष्टिकोण

एनपीएम ऑडिट का उपयोग करके परियोजना सत्यापन के परिणाम यहां दिए गए हैं।


भेद्यता जाँच पैकेज रिपोर्ट

▍28। स्वचालित निर्भरता अद्यतन

सिफारिशें

अच्छे इरादों के साथ नरक की राह प्रशस्त होती है। यह विचार पूरी तरह से package-lock.json लागू होता है, जिसका उपयोग, डिफ़ॉल्ट रूप से, पैकेज अपडेट को ब्लॉक करता है। यह उन मामलों में भी होता है जब परियोजनाओं को npm install और npm update कमांड द्वारा एक स्वस्थ राज्य में लाया जाता है। यह या तो, सबसे अच्छे, पुराने पैकेज के उपयोग के लिए, या सबसे खराब, परियोजना में असुरक्षित कोड की उपस्थिति की ओर जाता है। इसके परिणामस्वरूप, विकास दल, पैकेजों के उपयुक्त संस्करणों के बारे में जानकारी के मैन्युअल अद्यतन पर निर्भर करते हैं, या ncu जैसी उपयोगिताओं पर, जो, फिर से, मैन्युअल रूप से लॉन्च किए जाते हैं। निर्भरता को अद्यतन करने की प्रक्रिया सबसे अच्छी स्वचालित है, जो परियोजना में उपयोग किए जाने वाले संकुल के सबसे विश्वसनीय संस्करणों के उपयोग पर ध्यान केंद्रित करती है। यह एकमात्र सही समाधान नहीं है, हालांकि, पैकेज अपडेट को स्वचालित करने में, कुछ उल्लेखनीय दृष्टिकोण हैं। पहला तरीका है कि एनआईएम- आउटडेटेड या एनपीएम-चेक-अपडेट (एनसीयू) का उपयोग करके कुछ पाइपों की जांच करना। यह अप्रचलित पैकेजों की पहचान करने और डेवलपर्स को उन्हें अपग्रेड करने के लिए प्रोत्साहित करने में मदद करेगा। दूसरा तरीका वाणिज्यिक उपकरणों का उपयोग करना है जो कोड की जांच करते हैं और स्वचालित रूप से निर्भरता को अद्यतन करने के उद्देश्य से पुल अनुरोध करते हैं। स्वचालित निर्भरता अद्यतन करने के क्षेत्र में, हम अद्यतन नीति के संबंध में एक और दिलचस्प सवाल का सामना कर रहे हैं। यदि प्रत्येक नए पैच के साथ अपडेट किया जाता है, तो अपडेट सिस्टम पर बहुत अधिक तनाव डाल सकता है। यदि आप पैकेज के अगले प्रमुख संस्करण के जारी होने के तुरंत बाद अपडेट करते हैं, तो इससे परियोजना में अस्थिर समाधानों का उपयोग हो सकता है (रिलीज के बाद पहले कई दिनों में कई पैकेजों में कमजोरियां पाई जाती हैं, एस्लेंट-स्कोप वाली घटना के बारे में पढ़ें )। « », , . , 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 

परिणाम

, , . , , .

प्रिय पाठकों! ?