😬 👹 🆒 हडसन निरंतर एकता 🏉 🐻 🆙

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

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

निरंतर विधानसभा प्रक्रिया के स्वचालन के लिए, तैयार किए गए समाधान ( हडसन , क्रूज़कंट्रोल ) हैं, जिनमें से एक (हडसन) का एकीकरण मैं इस लेख में वर्णन करूंगा।

कार्य

और इसलिए, मान लें कि हमारे पास दो परियोजनाएँ हैं: एक जावा सेवा (अपने स्वयं के डेटाबेस के साथ), और इसके लिए एक PHP क्लाइंट (अपने स्वयं के डेटाबेस के साथ)। दोनों प्रोजेक्ट्स को डिबेट पैकेज के रूप में वितरित किया जाता है। इन परियोजनाओं के निरंतर एकीकरण के लिए बुनियादी ढांचे को स्थापित करना आवश्यक है।

कार्यान्वयन

अंत में हम क्या हासिल करना चाहते हैं, इसका अंदाजा लगाने के लिए, हम अंत से शुरू करेंगे: उस योजना पर विचार करें जिसे हम लागू करना चाहते हैं:

प्रोग्रामर की वर्किंग मशीन - राइटिंग कोड,
SVN सर्वर - कोड संग्रहण,
मंचन सर्वर - संकलित परियोजनाओं की स्थापना और परीक्षण,
सेलेनियम सर्वर - वेब-इंटरफ़ेस परीक्षण,
रेपो सर्वर - एकत्रित पैकेज का भंडारण,
CI सर्वर - एक पूरे में सभी सिस्टम नोड्स का कनेक्शन।

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

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

मुकाबला सर्वर के लिए रिपॉजिटरी के लिए प्रोजेक्ट पैकेज का अपलोड मैन्युअल रूप से डेवलपर द्वारा रिलीज के समय किया जाता है।

हडसन

हमारे सिस्टम में मुख्य और सबसे दिलचस्प नोड CI सर्वर है। इस मामले में, यह हडसन सबसे लोकप्रिय और आम मुफ्त समाधानों में से एक होगा।

सबसे पहले, इसे स्थापित करें। हडसन एक पैकेज के रूप में उपलब्ध है, इसलिए इसे स्थापित करना काफी सरल है। इसके अलावा, हडसन अपना संपूर्ण कॉन्फ़िगरेशन फ़ाइलों ( / var / lib / hudson ) में संग्रहीत करता है, जिसे किसी भी डेटाबेस के साथ एकीकरण की आवश्यकता नहीं होती है।

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

प्लगइन्स को कई सशर्त समूहों में विभाजित किया जा सकता है जो परियोजना के निर्माण चक्र का निर्माण करते हैं, जिसे "पाइपलाइन" के रूप में भी जाना जाता है (परियोजना प्लगइन्स का कॉन्फ़िगरेशन प्रोजेक्ट सेटिंग्स मेनू के माध्यम से उपलब्ध है):

स्रोत कोड प्रबंधन (भंडार से परियोजना कोड प्राप्त करना / अपडेट करना),
असेंबली ट्रिगर्स (प्रोजेक्ट असेंबली के लिए ऑटोस्टार्ट समय सेट करना),
बिल्ड एनवायरनमेंट (प्रोजेक्ट का बिल्ड एनवायरमेंट: JVM संस्करण),
असेंबली (मुख्य चरण: असेंबली, एकीकरण और परीक्षण के तर्क को लागू करने वाले प्लगइन्स लॉन्च करना),
असेंबली ऑपरेशन (रिपोर्ट, अधिसूचना का निर्माण / प्रकाशन)।

दुर्भाग्य से, हडसन आपको असेंबली समूह में शामिल प्लगइन्स के केवल निष्पादन आदेश को बदलने की अनुमति देता है (इसके समूह के भीतर शेष प्लगइन्स का निष्पादन क्रम प्लगइन्स के @Execution एनोटेशन कोड के मूल्यों के आधार पर निर्धारित किया जाता है)। इसलिए, यदि आपको अपनी बिल्ड स्क्रिप्ट को लागू करने की आवश्यकता है, जिसके लिए "असेंबली" समूह से मानक प्लगइन्स का एक सेट पर्याप्त नहीं है, तो आप तीन तरीकों से जा सकते हैं:

किसी भी बाहरी निष्पादन योग्य स्क्रिप्ट को कॉल करें जो इस स्क्रिप्ट को लागू करती है (मेनू से आइटम "एक्सक्यूट शेल" "बिल्ड स्टेप जोड़ें"),
प्रोजेक्ट बिल्ड सिस्टम (Phing, Ant, Maven) के प्लग-इन कनेक्ट करें और आवश्यक लक्ष्य निर्दिष्ट करें,
अपना प्लगइन लिखें।

डिफ़ॉल्ट रूप से, हडसन एसवीएन और मावेन के साथ काम करने के लिए पहले से इंस्टॉल किए गए प्लगइन्स के साथ आता है। यह काफी पर्याप्त हो सकता है अगर यह केवल जावा परियोजनाओं के बारे में था। हालाँकि, मान लीजिए कि हमें PHP प्रोजेक्ट्स के साथ भी काम करना है। इस मामले में, प्रोजेक्ट बनाने के लिए फिंग का उपयोग करना अधिक तर्कसंगत है, जिसके लिए प्लगइन को अलग से स्थापित करने की आवश्यकता है। यह "सेटिंग्स / प्रबंधन प्लगिन / उपलब्ध अपडेट" अनुभाग पर जाकर किया जाता है।

कृपया ध्यान दें कि कुछ प्लगइन्स को जावा 6 के तहत हडसन चलाने की आवश्यकता है। आप पथ को जेवीएम (बस कॉन्फ़िगरेशन के बाकी विकल्पों की तरह) / आदि / डिफ़ॉल्ट / हडसन फ़ाइल में बदल सकते हैं । अन्यथा, हडसन के संचालन से सीधे संबंधित सभी कॉन्फ़िगरेशन पैरामीटर वेब इंटरफ़ेस में एक ब्राउज़र के माध्यम से संपादित किए जा सकते हैं।

प्लग-इन सेटिंग्स के बारे में, यह भी उल्लेखनीय है कि प्लग-इन में सामान्य सेटिंग्स ("सिस्टम सेटिंग्स / कॉन्फ़िगरेशन") और प्रोजेक्ट सेटिंग्स ("सेटिंग्स / प्रोजेक्ट नाम / कॉन्फ़िगर प्रोजेक्ट") दोनों हैं।

अब जबकि सभी आवश्यक प्लगइन्स इंस्टॉल हो गए हैं, हम संबंधित प्लगइन्स के लिए इसके नाम और सेटिंग्स को निर्दिष्ट करके एक नया प्रोजेक्ट / कार्य बना सकते हैं: SVN रिपॉजिटरी में URL और असेंबली के लिए एक कमांड।

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

बिल्ड चरण पर विचार करें:

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

सबसे पहले, स्टेजिंग सर्वर पर एप्लिकेशन को चलाने के लिए कॉन्फिगर कॉम्बैट कॉनफिगर से भिन्न हो सकता है। इस मामले में, स्पष्ट समाधान परियोजना में मचान सर्वर के लिए स्टोर करना होगा और इसे विधानसभा के दौरान मूल परियोजना के साथ प्रतिस्थापित करना होगा (फ़िंग या मैवेन के लिए एक प्रोफ़ाइल के मामले में विधानसभा के लिए एक अलग लक्ष्य)।

दूसरे, एससीपी और एसएसएच प्लगइन्स का उपयोग करते हुए स्टेजिंग सर्वर पर पैकेज स्थापित करना (काम करने के लिए प्लगइन के लिए, सुनिश्चित करें कि sshd config में PasswordAuthentication पैरामीटर हाँ पर सेट है, और स्टेजिंग सर्वर होस्ट ज्ञात होस्ट में जोड़ा जाता है), SSH प्लगइन के रूप में प्रोजेक्ट के असेंबली चरण को संदर्भित करता है, और एससीपी प्लगइन विधानसभा-बाद के संचालन को संदर्भित करता है। इसलिए, एक प्रोजेक्ट को एक स्टेजिंग सर्वर पर तैनात करने की समस्या को Phing या Maven + AntRun का उपयोग करके हल करना होगा।

दूरस्थ सर्वर पर कार्रवाई करने के लिए हमारी बिल्ड स्क्रिप्ट के लिए, ssh कुंजियों को उत्पन्न करना आवश्यक है: CI सर्वर पर निजी कुंजी छोड़ दें, और सभी सर्वरों पर सार्वजनिक कुंजी वितरित करें जो कि आपके साथ बातचीत कर रही हैं: मंचन, रेपो, svn: उन्हें सूची में जोड़ें। ज्ञात होस्ट (ज्ञात_होस्ट)। इसके अलावा, हडसन एक दूरस्थ सर्वर पर पैकेज को स्थापित करने में सक्षम होने के लिए, आपको दूरस्थ सर्वर पर संबंधित उपयोगकर्ता (हडसन) बनाने और इसे sudo देने की आवश्यकता होगी।

तीसरा, मावेन का उपयोग करके जावा अनुप्रयोगों को सफलतापूर्वक बनाने के लिए, आपको CI सर्वर पर हडसन उपयोगकर्ता के लिए मावेन सेटिंग्स निर्धारित करने की आवश्यकता होगी (जिसका अर्थ है ~ / .m2 निर्देशिका )।

स्टेजिंग सर्वर पर पैकेज स्थापित करने के बाद अगला चरण एकीकरण परीक्षणों का लॉन्च होना चाहिए। उन्हें CI सर्वर पर ही चलाया जा सकता है, हालाँकि, स्टेजिंग सर्वर पर ऐसा करना बेहतर होता है। पहले मामले में, सब कुछ काफी सरल है: हम उपयुक्त फ़िंग / मावेन लक्ष्य को कॉल करते हैं या सेलेनियमएचक्यू प्लगइन को कॉन्फ़िगर करते हैं।

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

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

इसके अलावा, मैं सुझाव देता हूं कि जो कोई भी हडसन को PHP परियोजनाओं के लिए उपयोग करता है, उसे हडसन विकी के प्रासंगिक लेखों को पढ़ना चाहिए।

मंचन सर्वर

पैकेज स्थापना

और इसलिए, जैसा कि पहले ही ऊपर उल्लेख किया गया है, हमारे बुनियादी ढांचे में एक सर्वर होना चाहिए जो मुकाबला एक के करीब संभव हो। हडसन इस सर्वर पर ट्रंक के माध्यम से एकत्र किए गए नवीनतम प्रोजेक्ट पैकेज स्थापित करेगा। यह हमें मौका देगा:

परिस्थितियों से निपटने के लिए यथासंभव परिस्थितियों में एकीकरण परीक्षण करें,
आपको नवीनतम कार्यक्षमता प्रदर्शित करने के लिए एक प्रकार का प्लेटफ़ॉर्म रखने की अनुमति देता है।

इस सर्वर को सेट करते समय मुख्य समस्याओं में से एक को हल करना होगा जो संकुल की मौन स्थापना है। हमारे पैकेजों को अनावश्यक संवादों के बिना स्थापित करने के लिए (अर्थात, उन्हें हडसन लिपियों या प्लग-इन का उपयोग करके स्थापित किया जा सकता है), डिबेंक्फ़ को पुन: कॉन्फ़िगर करने के लिए आवश्यक है ( डीपीके-रीकॉन्फ़िगर डीबॉन्फ़ ), जो पूछे जाने वाले प्रश्नों के महत्व के स्तर को इंगित करता है, जिनका उपयोग किया जाता है। अपने डिबेट पैकेज की इंस्टॉलेशन स्क्रिप्ट।

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

पहली नज़र में, स्पष्ट समाधान, डिब पैकेज के माध्यम से परियोजना के वितरण को ध्यान में रखते हुए,

निर्भरता dpkg द्वारा "सर्वर" पैकेज के बारे में जानकारी जोड़कर क्लाइंट पैकेज की निर्भरता नियंत्रण-फ़ाइल में प्रबंधित की जाएगी।

इस मामले में, हमें एक अलग डेबियन रिपॉजिटरी का भी चयन करना होगा, जिसमें CI सर्वर द्वारा एकत्र किए गए सभी पैकेज मर्ज होंगे, और रिपॉजिटरी को पैकेज कॉपी करने के लिए कमांड के साथ बिल्ड स्क्रिप्ट को पूरा करेंगे। इसके अलावा, नए पैकेज को जोड़ने पर इस रिपॉजिटरी में डेटा को स्वचालित रूप से अपडेट करने के लिए एक तंत्र को व्यवस्थित करना आवश्यक होगा, रिपॉजिटरी पूल तक पहुंच की व्यवस्था करें (उदाहरण के लिए, वेब सर्वर बढ़ाकर), और इस रिपॉजिटरी को स्रोत-सूची में स्टेजिंग सर्वर पर जोड़ें। ऑटो-अपडेट को मैन्युअल रूप से व्यवस्थित करते समय (रिपॉजिटरी में पैकेज डालने के बाद पैकेज स्कैनर लॉन्च करके), नया पैकेज एप्ट के माध्यम से स्थापित किया जा सकता है, अगर रिपॉजिटरी को शेड्यूल पर अपडेट किया जाता है, तो आपको dpkg -i पैकेज जैसे ट्रिक का आविष्कार करना होगा ; apt-get -f install अपने डेबियन भंडार को यहां स्थापित करने के बारे में और पढ़ें।

हालांकि, इस दृष्टिकोण के कई नुकसान हैं। सबसे पहले, निर्भरता केवल एक ही सर्वर पर स्थापित की जा सकती है। दूसरे, इस दृष्टिकोण काफी काफी समग्र प्रणाली है, जो के सिद्धांत के विपरीत है पेचीदा हो जाता है KISS (: डी अच्छी तरह से, या "स्मैक" अगर रूसी में)।

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

संकुल।

एक DB के साथ काम करें

हमारे पैकेज डेटाबेस का उपयोग कर सकते हैं। इस स्थिति में, डेटाबेस को स्टेजिंग सर्वर पर भी स्थापित किया जाता है, और डेटाबेस संरचना / डेटा को dbdeploy उपयोगिता का उपयोग करके अपडेट किया जाता है।

एक परियोजना में dbdeploy को एकीकृत करने के दो तरीके हैं:

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

अलग-अलग, इस मामले में, परीक्षण के दौरान डेटाबेस डेटा में परिवर्तन के बारे में सवाल उठता है। यह स्पष्ट है कि इकाई परीक्षण लिखते समय हम डेटाबेस के साथ काम नहीं करते हैं, लेकिन नकली वस्तुओं का उपयोग करते हैं (उदाहरण के लिए, मुझे मॉकिटो पसंद है)।

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

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

पैच, या परीक्षण का निर्माण ताकि वे डेटाबेस से किसी विशिष्ट डेटा से बंधे न हों (उदाहरण के लिए, स्वयं वेब इंटरफ़ेस के माध्यम से परीक्षण के लिए आवश्यक डेटा बनाएं) और, यदि संभव हो तो, "कचरा" पीछे न छोड़ें।

सर्वर सेलेनियम

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

सेलेनियम एक शक्तिशाली वेब अनुप्रयोग परीक्षण प्रणाली है, जिसे सशर्त रूप से दो भागों में विभाजित किया जा सकता है:

Selenuim IDE - ब्राउज़र में टेस्ट स्क्रिप्ट विकसित करने और चलाने के लिए एक टूल (प्लगइन 'फ़ायरफ़ॉक्स के रूप में उपलब्ध),
सेलेनियम आरसी सेलेनियम सर्वर और उसके अधीनस्थ ग्राहकों से एक वितरित प्रणाली है, जिस पर विभिन्न ब्राउज़रों के तहत परीक्षण चलाए जाते हैं।

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

टिप्पणी

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

निष्कर्ष

ऊपर वर्णित समाधान काम करता है और लाभ लाता है । हालांकि, जैसा कि हम सभी जानते हैं, सिद्धांत, दुर्भाग्य से, हमेशा अभ्यास के अनुरूप नहीं होता है। सीआई प्रणाली के कार्यान्वयन के लिए कई समस्याओं का समाधान आवश्यक था, जिनमें से सभी को आदर्श रूप से हल नहीं किया गया था।

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

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

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

हडसन निरंतर एकता