🛌🏼 🧖 🤝 जेनकिंस सीआई - चीजें मुझे याद आती हैं 🌮 ☝🏾 🐱

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

समस्या कथन के चरण

और इसलिए, प्रारंभिक कार्य सिस्टम को केवल वेब-सर्वर लॉन्च करने, रिपॉजिटरी में परिवर्तन को ट्रैक करने और जेयूनिट, टेस्टएनजी और सेलेनियम परीक्षणों को चलाने के लिए सिखाना था। समय के साथ, यह कार्य छोटी चीज़ों के एक समूह के साथ आगे बढ़ गया है, जिस पर बाद में चर्चा की जाएगी। यह मुश्किल नहीं लगता है, लेकिन, जैसा कि यह निकला, पहली राय गलत है। स्पष्ट विवेक के साथ, मैंने मुझे प्रदान की गई वर्चुअल मशीन पर सेंटोस 6 x64 स्थापित किया, और कुछ आंदोलनों में सीआई को स्थापित किया:

sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key sudo yum install jenkins

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

त्रुटियों

जब मैं सेट कर रहा था, मैंने कई गलतियाँ कीं, इसलिए मैं ऐसे लोगों के लिए एक छोटी सूची प्रस्तुत करता हूं जो अपना समय बचाना पसंद करते हैं:

प्रोजेक्ट पदानुक्रम: यदि आपके पास जटिल पदानुक्रमिक निर्भरताएं हैं, तो एक पत्ता लेने के लिए बहुत आलसी मत बनो और इस पर सोचें कि क्या निर्भर करता है और, आदर्श रूप से, यह होना चाहिए।
एक बार में सभी परियोजनाओं को स्थापित करने का प्रयास न करें। प्रत्येक प्रोजेक्ट को एक कामकाजी, मध्यवर्ती राज्य में लाने की कोशिश करें, और अगले पर जाएं। आपके पास हमेशा एक मार्फ़ेट बनाने का समय होता है।
सभी आश्रित परियोजनाओं के मध्यवर्ती विन्यास के अंत तक परियोजना के विन्यास को न चाटें। यह संभव है कि जिस कार्यक्षमता को आप कार्यान्वित करने का निर्णय लेते हैं, वह इस समय बिल्कुल या तो समय लेने वाली होगी या कार्य नहीं होगी। अपने प्लगइन लेखन हमेशा एक उचित गतिविधि नहीं है।
परियोजनाओं के नाम। कुछ स्थितियों में, किसी प्रोजेक्ट का नाम बदलना महंगा हो सकता है। और अगर यह अचानक स्पष्ट हो गया कि आपको नामों में किसी संरचना के बिना 130 परियोजनाओं का नाम बदलने की आवश्यकता है? इसलिए आप अपने घुटने पर एक स्क्रिप्ट नहीं लिख सकते हैं, और इसे अपने हाथों से नाम बदल सकते हैं - टॉड क्रश। सरल युक्तियों से नामों तक: यह बहुत लंबा नहीं होना चाहिए, और उपयोगी जानकारी ले जानी चाहिए। उदाहरण के लिए, यदि आपके पास अलग-अलग बंदरगाहों पर एक ही उत्पाद के कई संस्करण हैं, तो उन्हें "ProjectAbbr9587" की भावना में नाम क्यों नहीं दिया जाए, जहां 9587 बंदरगाह संख्या है। यह नामकरण नीति आपको जल्दी से समझने की अनुमति देती है और जो कहा जा रहा है उसे भ्रमित करने का मौका कम कर देता है।
यदि आपके पास ओएस का विकल्प है जिस पर आप जेनकिंस सीआई को चलाने की योजना बनाते हैं, तो जब आप एक आश्वस्त / उन्नत उपयोगकर्ता होते हैं तो यूनिक्स चुनें। मुझे उपयोगकर्ता के एक्सेस अधिकारों के साथ अधिकांश समस्याएं हैं जो जेनकिंस और अन्य एप्लिकेशन चला रहे हैं। यदि यह मुश्किल नहीं है, तो एक उपयोगकर्ता की ओर से सब कुछ चलाने का प्रयास करें।
याद रखें, जेनकिंस, हीडगर से अधिक संस्थाओं का उत्पादन करना पसंद करते हैं। इसलिए, अग्रिम में, उपयोगकर्ता जेनकींस की ओर से लॉन्च किए गए थ्रेड और प्रक्रियाओं की अधिकतम संख्या बढ़ाएं। खासकर यदि आपके पास भारी भरकम CI सर्वर है
आपको अपने द्वारा देखे गए सभी प्लगइन्स को स्थापित नहीं करना चाहिए। अक्सर, "एक-बार उपयोग" के लिए एक प्लगइन की आवश्यकता होती है और इस तरह के प्लगइन को प्राथमिक स्क्रिप्ट के साथ बदला जा सकता है। वे उपयोगी कुछ भी नहीं कर सकते हैं, लेकिन अतिरिक्त संसाधनों को खा सकते हैं (यह ChuckNorris Plugin पर लागू नहीं होता है)।
अग्रिम में संसाधन की तीव्रता का अनुमान लगाएं। इस बारे में सोचें कि यह कितने विधानसभाओं में संग्रहित करता है। वास्तव में कितनी कलाकृतियों की जरूरत है। यदि सर्वर का प्रदर्शन कम है, तो विधानसभा अनुसूची पर विचार करें, ताकि एक ही समय में कई संसाधन-गहन असेंबलियों को लॉन्च न किया जाए, और यदि आप उपयोग किए गए संसाधनों की संख्या की निगरानी नहीं करना चाहते हैं, तो सुनिश्चित करें कि प्रारंभ की गई विधानसभाओं की अधिकतम संख्या अधिक है, या कम से कम संख्या के समान है। परियोजनाओं।
ज्यूनिट, टेस्टएनजी आदि की सूचना यदि आप 5,000 से अधिक यूनिट परीक्षण चलाते हैं जो विशेष रूप से समूहीकृत नहीं हैं, तो जेनकींस की तरह एक सुंदर निष्कर्ष भी हमेशा जानकारीपूर्ण नहीं हो पाता है। शायद यह अलग-अलग रिपोर्टों पर परीक्षणों को पुनर्व्यवस्थित और वितरित करने के लिए समझ में आता है?
सुरक्षा। उसके बारे में मत भूलना। पासवर्ड के उपयोग पर स्विच करने से न केवल तोड़फोड़ करने वाले लोगों के तर्क को सीमित किया जाएगा, बल्कि सिर के "आगमन" के मामले में भी "आप हमारे लिए सब कुछ तोड़ दिया", "यह मुझे नहीं था" तर्क का खंडन करते हुए प्रलेखित साक्ष्य होंगे।
यह मत भूलो कि जेनकिंस सीआई डेवलपर के लिए एक सहायक उपकरण है, और यदि आप कुछ नहीं कर सकते हैं, तो आपको इसमें चक्र में नहीं जाना चाहिए। शायद एक शानदार निर्णय एक सप्ताह में आपके सिर पर आ जाएगा, या शायद एक ही सप्ताह में यह एहसास होगा कि यह सुविधा इतनी आवश्यक नहीं है। कभी-कभी इस ज्ञान को परियोजना प्रबंधक को समझाया जाना चाहिए, उनकी इच्छा कि सब कुछ सुंदर था हमेशा उचित नहीं है।

मुझे लगता है कि इस सूची में सभी को जोड़ने के लिए कुछ है। लेकिन, ऐसा लगता है, सबसे महत्वपूर्ण बात, मैंने ध्यान दिया। और मुझे वास्तव में उम्मीद है कि यह छोटी सूची कई लोगों के लिए समय बचाएगी।

पहले प्रयास

स्वाभाविक रूप से, पहले लॉन्च के बाद, नीले रंग की मंडलियों को देखना मेरे लिए असामान्य था, लेकिन उनका रंग तुरंत नहीं बदला गया था। मैंने SVN और Git की स्थापना की, परियोजना पदानुक्रम वितरित की और सब कुछ काम करने लगा। अगले दिन, एक कार्य पर 4 योजनाबद्ध विधानसभाएं थीं, और लॉन्च किया गया लगभग 9 घंटे तक चला। यह पता चला कि यह इस दिन था कि एक "बुरा" प्रतिबद्ध किया गया था, जिसने यूनिट परीक्षण को अनंत प्रतीक्षा में जाने के लिए मजबूर किया था। बिल्ड-टाइमआउट प्लगइन बचाव के लिए आया था। दूसरी ओर, मेरे पास ऐसी परियोजनाएं थीं जो एक "अंतहीन विधानसभा" में होनी चाहिए। चींटी कार्य जो वेब सर्वर चलाते हैं और एक्शन लॉग को असेंबली में आउटपुट करते हैं, जो बहुत सुविधाजनक था। स्वाभाविक रूप से, ये सर्वर कई दिनों के लिए चालू स्थिति में हो सकते हैं, और अनावश्यक रूप से उन्हें रोकने की आवश्यकता के बिना इसका कोई मतलब नहीं है, क्योंकि वे काम कर सकते हैं, ग्राहकों को परिणाम दिखा सकते हैं और बहुत कुछ। यह एक परियोजना बनाने का निर्णय लिया गया था कि दिन के एक निश्चित समय पर जाँच करता है कि क्या कोई शाखा अद्यतन है, और यदि ऐसा है, तो अद्यतन डाउनलोड करें और विधानसभा को पुनरारंभ करें। उन प्रबंधकों की प्रतिक्रिया जिन्होंने सवाल पूछा कि सभी मारे गए: “प्रोजेक्ट असेंबली की पट्टी लाल क्यों है? "ठीक है, शायद, क्योंकि यह सुबह 10 बजे है और विधानसभा ने पिछले 6 घंटों से लॉग के लिए कुछ भी नहीं लिखा है।" मुझे अब तक स्ट्रिप्स को फिर से हटाने का कोई हल नहीं मिला है (पैराग्राफ 11 देखें), लेकिन मुझे लगता है कि यह मुश्किल नहीं है। गैर-पूर्ण विधानसभा के साथ अन्य समस्याएं थीं: एक अलग सर्वर पर 2 परियोजनाएं बनाए बिना इकाई परीक्षण कैसे चलाएं? दरअसल, इसे लागू करने के लिए, आपको 2 चींटी टास्क 'ए:' स्टार्ट-सर्वर 'और' जूनिट 'को चलाने की जरूरत है, जिनमें से पहला खत्म नहीं होता है। एक अलग सर्वर पर आप क्यों पूछते हैं: क्योंकि परीक्षण के साथ मुख्य वेब सर्वर का परीक्षण करना अच्छा नहीं है। इसके अलावा, परीक्षणों के लिए वेब सर्वर को आवश्यकतानुसार लॉन्च किया जाना चाहिए और केवल यूनिट परीक्षणों की अवधि के लिए, ताकि अतिरिक्त संसाधनों को बर्बाद न करें। चींटी की सभी संभावनाओं को याद करते हुए, ऐसा कुछ करने का निर्णय लिया गया:

 <target name="start-server-with-units"> <parallel> <daemons> <antcall target="start-server"> </antcall> </daemons> <sequential> <waitfor maxwait="10" maxwaitunit="minute"> <socket server="localhost" port="${port}" /> </waitfor> <antcall target="junit"> </antcall> </sequential> </parallel> </target>

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

शाखाओं

मेरी राय में, जेनकिंस में खराब तरीके से समर्थन को लागू किया गया है। "Svn: //svn.adress: port / $ {branchName}", जहां शाखानाम एक पर्यावरण चर है, अक्सर समस्या का समाधान नहीं करता है। सबसे पहले, ऐसी विधानसभाओं को केवल हाथ से, या डिफ़ॉल्ट विकल्प के साथ शुरू किया जा सकता है, लेकिन पाल SCM का उपयोग करके विधानसभा शुरू करना पहले से ही स्पष्ट रूप से असंभव है। अगर किसी को इस तरह की कार्यक्षमता की आवश्यकता होती है (जैसा कि मुझे पता चला कि मुझे अभी भी इसकी आवश्यकता नहीं है), तो एक स्पष्ट विवेक के साथ, वह एक ग्रूवी स्क्रिप्ट लिख सकता है कि स्टार्टअप में ब्रांचनाम का डिफ़ॉल्ट मान बदल जाएगा जो स्टार्टअप पर सेट किया गया था और फिर प्रोजेक्ट शुरू करें सामान्य शेड्यूल, और यदि आवश्यक हो, तो संस्करण नियंत्रण प्रणाली में अपडेट के लिए एक चेक जोड़ें। इस दृष्टिकोण का नुकसान यह है कि अनावश्यक असेंबली की एक श्रृंखला में, कुछ उपयोगी खोजना मुश्किल है। लेकिन यह भी कोई फर्क नहीं पड़ता, उसी पोस्टबिल्ड ग्रूवी स्क्रिप्ट में आप "पैडल" को जकड़ सकते हैं जो "निष्क्रिय" असेंबली को हटा देगा। क्या यह इस ग्रूवी स्क्रिप्ट चमत्कार के साथ आने के लिए लायक है यदि आप एक और प्रोजेक्ट बना सकते हैं जो अपडेट के लिए जांच करेगा?
निष्कर्ष: कभी-कभी किसी अन्य बाइक को लिखने की तुलना में यह एक परियोजना बनाने के लायक है।
साथ ही स्ट्रगल करने की समस्या के लिए, मैं बिल्ड नेम सेटर प्लगिन शामिल करूंगा। बिल्ड नंबर के बजाय ब्रांड नाम को देखना बहुत अच्छा है, लेकिन यहां भी यह इतना सरल नहीं है। क्योंकि सभी चर की लंबाई की विशेषता नहीं होती है (उदाहरण के लिए, पर्यावरण चर) जिसका उपयोग किसी स्ट्रिंग की अधिकतम लंबाई को ट्रिम करने के लिए किया जा सकता है। सहमत हूं, यह लुक बहुत प्रेरक नहीं है, लेकिन क्या होगा यदि लंबाई 30 नहीं है, लेकिन 255 अक्षर हैं?

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

साइकिलें

हम सभी लोग हैं, और हम सभी चाहते हैं कि किसी तरह का आराम मिले। मैं अपना प्लग-इन लिखना नहीं चाहता था; कोई भी समझौता करने वाला नहीं था, लेकिन मैं परिणाम प्राप्त करना चाहता था। इस कारण मैं यहां उन सभी साइकिलों का वर्णन करूंगा, जिन्होंने किसी भी तरह से मेरे लिए जीवन आसान बना दिया है।

 if(manager.build.result == hudson.model.Result.ABORTED){ manager.build.@result = hudson.model.Result.SUCCESS }

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

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

 item = hudson.model.Hudson.instance.getItem("jUnitJobName") def build = item.getLastBuild() if(build.getResult() == null){ build = build.getPreviousCompletedBuild() } def result = build.getResult() if(result == hudson.model.Result.SUCCESS){ manager.addBadge("star-gold.gif", "Success Unit Tests") } else { manager.addBadge("warning.gif", "Unit Tests Failure") }

लड़ाई मैनुअल परीक्षण
ऐसा हुआ कि परीक्षक अलग हैं। और यह बहुत निराशाजनक है जब वे जानते हैं कि कुछ सही काम क्यों नहीं कर रहा है, लेकिन वे पहले से जिम्मेदारी से धक्का देने की कोशिश करते हैं, यह तर्क देते हुए कि "मैंने सब कुछ अच्छा किया, लेकिन यह टूट गया, आपको दोष देना है, आप ठीक कर रहे हैं"। ऐसे मामलों के लिए, AnsiColor प्लगइन बहुत अच्छी तरह से मदद करता है। यदि यह काम नहीं करता है, तो मैं दृढ़ता से और अधिक आक्रामक उपायों का उपयोग करने की सलाह देता हूं: उपयोगकर्ता Vars Plugin बनाएँ - व्यक्तिगत उपचार आपके कार्यों को अधिक शर्मनाक बनाता है (मशीन ने मेरे नाम को कैसे पहचाना?)। मुख्य बात यह ज़्यादा नहीं है, ऐसी स्थिति संभव है जब स्क्रिप्ट सही ढंग से काम नहीं करती है, और परीक्षक 3 दिनों के लिए पूछने से डरते थे, क्योंकि उन्होंने कंसोल में लिखा था: "क्या आपने अभी सब कुछ ठीक किया है?" इस मामले में, सभी पत्थर आप में उड़ जाएंगे। किसी को भी मूर्ख की तरह दिखना पसंद नहीं है। लेकिन अगर आपने इसे खराब कर दिया - कुछ ऐसा प्राप्त करें ( ! लाल रंग का उपयोग किया जाना चाहिए ):

मुझे अच्छा लगेगा

खैर, निष्कर्ष में, मैं चीजें लिखूंगा - जो मैं वास्तव में पसंद करूंगा, लेकिन मैं प्लगइन्स नहीं लिखूंगा। शायद वे लागू हो गए, लेकिन मैंने उन्हें नहीं पाया। सुझावों के लिए - मैं आभारी रहूंगा।
ऑटो स्टार्ट स्टार्टअप पर बनाता है । उदाहरण के लिए, पावर सर्ज / प्रकाश की कमी के कारण सर्वर रिबूट हो गया था। जेनकिंससी ने इस पर काम शुरू किया, लेकिन लगातार चलने वाली परियोजनाएं शुरू नहीं हुईं? हर बार जब आप पेन चलाते हैं - यह मूर्खतापूर्ण है। इसलिए, मुझे वास्तव में एक चेक मार्क चाहिए: "क्या मुझे रिबूट के बाद यह प्रोजेक्ट शुरू करना है?"
SVN \ Git कस्टम शाखा + पैच , यदि उपरोक्त छवियों के साथ अद्यतन किया जाता है, तो यह सभी मौजूदा स्थानीय परिवर्तनों को अधिलेखित कर देता है। यह पैच को बहुत असुविधाजनक बनाता है। मुझे वास्तव में मेरी स्क्रिप्ट्स पसंद नहीं हैं जो पैच को रद्द करती हैं, वांछित शाखा को विचलित करती हैं और पैच को वापस लागू करती हैं।
सिस्टम संदेश यह कि 'जेनकिन्स \ कॉन्फ़िगरेशन \ सिस्टम संदेश' के प्रदर्शन का परिणाम सभी पृष्ठों पर प्रदर्शित किया गया था, न कि केवल देखने के लिए। सामान्य तौर पर, मैं उपस्थिति बदलने के लिए अधिक प्लगइन्स चाहूंगा। क्योंकि सबसे पहले, यह प्रबंधकों के काम की सुविधा देता है, और संचालन पर कम सवाल, विकास के लिए अधिक समय बचा है।
प्लगइन का पुनर्निर्माण करें। मैं चाहता हूं कि पिछले निर्माण को कैसे रोका जाए, यह जानने के लिए मैं फिर से तैयार करता हूं, अन्यथा मैंने पुनर्निर्माण बटन पर क्लिक किया, और उसने केवल एक और निर्माण की योजना बनाई।
पीएस मुझे पता है कि जो चीजें मैं चाहता हूं, वे आवश्यकताओं से बहुत दूर हैं, लेकिन ये चीजें हैं जो मेरे पास पूरी खुशी के लिए पर्याप्त नहीं हैं। मुझे उम्मीद है कि यह लेख किसी के लिए उपयोगी होगा।