सतत वितरण PHP अनुप्रयोग

मैं php अनुप्रयोगों के लिए निरंतर एकीकरण और "दर्द रहित" तैनाती को लागू करने की कोशिश करने के अनुभव को साझा करना चाहता हूं। मैं इस मुद्दे पर कुछ पहलुओं पर विचार करने की कोशिश करूंगा:

• निरंतर एकीकरण क्या है?
• क्या तैनात है, यह सीआई में कैसे फिट होता है
• इस "कन्वेयर" के ढांचे में परीक्षण के बारे में थोड़ा सा

निरंतर एकीकरण - यह क्या है?

निरंतर एकीकरण (Eng। सतत एकीकरण) - यह सॉफ्टवेयर विकास का अभ्यास है, जिसमें एकीकरण की समस्याओं को जल्दी से पहचानने और हल करने के लिए परियोजना के लगातार स्वचालित विधानसभाओं के कार्यान्वयन में शामिल हैं।

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

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

कुछ समय बीत गया, जिसके दौरान मैं फ्रंट-एंड में गहराई से डील करने में कामयाब रहा और देव सर्वर पर r.js के अनुकूलन के साथ CSS में LESS को वरीयता देने के सवाल को बढ़त मिली - मैंने फिर भी CI से निपटने का फैसला किया। चूँकि फ़ाइल को सहेजने या ग्रंट के सामान्य लॉन्च के तथ्य पर स्थानीय वातावरण में मक्खी पर सब कुछ फिर से बनाया गया था, इसलिए कोई समस्या नहीं थी।

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

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

कूल, लेकिन इसे कैसे तैनात किया जाए?

तैनाती विभिन्न वातावरणों में एक आवेदन को तैनात करने की प्रक्रिया है। सब कुछ इसी तरह से होता है:

• ssh के माध्यम से हम सर्वर पर जाते हैं
• रिपोजिटरी से खींचो
• हमारे मामले में, हम फिंग भी चलाते हैं, जिसका अनुसरण ग्रंट द्वारा किया जाता है
• लाभ
• सभी उत्पादन सर्वर पर इसे दोहराएं

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



अब तक, सब कुछ रिपॉजिटरी की एक शाखा में चला जाता है और आप गलती से कुछ गलत तैनात कर सकते हैं। अब हम इस स्थिति को ठीक कर देंगे।

बिल्डिंग और php - क्या आप अभी भी कनेक्ट कर सकते हैं?

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



अब हमारे पास कुछ पाइपलाइन (पाइपलाइनिंग) हैं, जिन बिंदुओं के साथ मैंने कार्यों को चिह्नित किया है जिन्हें मैन्युअल रूप से कहा जाता है।
स्टेज सीआई जॉब तभी कहलाती है जब मेक रिलीज़ सफल हो।
यह पहले से बेहतर लग रहा है, अब हम परीक्षकों को जोड़ेंगे।

परीक्षण और पूर्वावलोकन जारी

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

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



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