कंटीन्यूअस डिलीवरी हेचो एन अलावर

लगभग एक साल पहले, हमारी टीम को कई गेमिंग MMO परियोजनाओं के लिए सर्वर भागों के विकास को शुरू करने का काम सौंपा गया था। लचीलेपन, स्थिरता और मापनीयता के लिए आवश्यकताओं के अतिरिक्त ऐसी परियोजनाओं की विशिष्टता भी शामिल है:

• एक ही खेल के विभिन्न संस्करणों के ए / बी परीक्षण की आवश्यकता
• एक गेम से दूसरे गेम में कार्यक्षमता के पुन: उपयोग को अधिकतम करने की क्षमता
• खेल के ग्राहक पक्ष में शामिल डेवलपर्स से भौगोलिक दूरी की उच्च संभावना

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

इस लेख का उद्देश्य उठाए गए कदमों, निर्णयों के बारे में बात करना और परिणाम का वर्णन करना है।

बुनियादी ढांचे

ऐतिहासिक रूप से, हमारी कंपनी में सर्वर-साइड वेब एप्लिकेशन विकसित करने के लिए मुख्य भाषा PHP है, इसलिए यह काफी हद तक उपकरण की पसंद को पूर्व निर्धारित करता है।

सारांश सूची:

• Git - संस्करण नियंत्रण प्रणाली
• गिटोलिट - भंडार प्रबंधन
• संगीतकार - निर्भरता प्रबंधक
• फिंग - विधानसभा और स्थापना स्क्रिप्ट
• जेनकिंस - निरंतर एकीकरण सर्वर
• phpunit , behat - परीक्षण
• phploc , phpmd , pd निर्भर , phpcs , phpcpd , phpcb , phpdox - अन्य उपयोगिताएँ

शाखा मॉडल

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

इस स्थिति को निम्न उदाहरण द्वारा प्रदर्शित किया जा सकता है। मूल के अनुसार याद करें:

इस बिंदु पर विकसित करने के लिए रिलीज़-टू-बिल्ट के लिए लक्षित कम से कम सभी विशेषताओं का विलय होना चाहिए। भविष्य की रिलीज़ पर लक्षित सभी सुविधाएँ नहीं हो सकती हैं - उन्हें तब तक इंतजार करना होगा जब तक कि रिलीज़ शाखा बंद न हो जाए।

और मान लें कि दो रिलीज़ पहले ही रिलीज़ हो चुके हैं - 1.0 को A और B के साथ रिलीज़ करें। A और B के साथ 2.0 रिलीज़ करें, और आपको A और C के साथ 1.1 रिलीज़ रिलीज़ करने की आवश्यकता है। चूंकि वर्तमान में विकसित शाखा में पहले से ही A और B की सुविधाएँ मौजूद हैं, फिर सबसे आसान समाधान रिलीज शाखा 1 से शाखा सी की एक सुविधा बनाना होगा, और फिर इसे वापस मर्ज करना होगा:

पैकिंग और संस्करण

सभी परियोजनाओं को संगीतकार पैकेज के रूप में डिज़ाइन किया गया है।

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

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

इस प्रकार के संस्करण को "~" वर्ण का उपयोग करके संगीतकार में समर्थित किया गया है, उदाहरण के लिए:

"require": {         ...         "alawar/packet-post-process-server": "~1.3",         ...     }, 

परियोजना की "विधानसभा"

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

विधानसभा कदम:

• संगीतकार के माध्यम से निर्भरता पंप
• डेटाबेस प्रवासन, - केवल संरचना और स्थैतिक डेटाबेस डेटा को अद्यतन करना

विधानसभा को लागू करने के लिए, प्रत्येक प्रोजेक्ट के मूल में target'ami के साथ एक असेंबली फ़िंग स्क्रिप्ट है:

• बिल्ड - बिल्ड चरणों को पूरा करने के लिए
• रनटैस्ट और रनटस्ट-विथ-कवरेज - निर्माण और परीक्षण चलाने और मैट्रिक्स एकत्र करने दोनों के लिए

अधिकांश प्रोजेक्ट के लिए असेंबली स्क्रिप्ट समान है और केवल प्रोजेक्ट के नाम में भिन्न है: विशेषता नाम, टैग प्रोजेक्ट।

परीक्षण

परियोजनाओं के स्वचालित परीक्षण का कार्यान्वयन दो रूपरेखाओं का उपयोग करके किया गया था: बेहट और PHPUnit।

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

यहां और यहां की सामग्रियों के साथ परिचित होने के बावजूद, हमारे पास इन परीक्षणों की गहराई और विस्तार के बारे में समान सिफारिशें नहीं हैं, इसलिए उनकी सामग्री अलग-अलग हो सकती है, उदाहरण के लिए, जैसे:

 :         #       -      : | action | uid | | get-user-bonus-code | player1 |         "GetUserBonusCodeResponse.txt" #                  : | action | code | | get-rewards-info |    |         "template8.txt" 

ऐसे करें:

 :      -                      

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

सर्वर बनाएँ

जेनकिंस CI सर्वर का उपयोग कर बनाएँ। उसी समय, प्रत्येक रिलीज़ शाखा रिलीज़ / XY के लिए, एक अलग असेंबली कार्य स्थापित किया जाता है, जो एक मंचन वातावरण पर होता है:

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

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



उपरोक्त लिंक पर सूचीबद्ध प्लगइन्स की सूची के अलावा, निम्नलिखित स्थापित किए गए थे:

• EnvInject - $ VERSION_NO चर को आरंभ करने के लिए
• ChuckNorris और CI- खेल - सिर्फ मनोरंजन के लिए

deploymenta

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

प्रारंभ में, एक फ़िंग स्क्रिप्ट द्वारा परिनियोजन किया गया था, जो सेटिंग फ़ाइल के अनुसार, कई क्रियाओं को निष्पादित करता है:

• बनाई गई फ़ाइलें, फ़ोल्डर्स और सिमिलिंक
• वांछित शाखा / टैग का चेकआउट स्रोत कोड
• परियोजना को इकट्ठा किया
• और जब से 2012-01-01T23: 59: 59 फॉर्म के एक नए फ़ोल्डर में हर बार चेकआउट किया गया था, यह नवीनतम सिमिलिंक को अद्यतन करता है, जो नवीनतम तैनात संस्करण को दर्शाता है।

दूरस्थ सर्वर पर स्थापना के लिए समर्थन की पूरी कमी के कारण यह बहुत सुविधाजनक नहीं था।

Capistrano , Magallanes और अन्य उपकरणों के साथ कई प्रयोगों के बाद, इंस्टॉलर कंसोल एप्लिकेशन को इस स्क्रिप्ट के अलावा लागू किया गया था। यह वांछित स्क्रिप्ट सर्वर समूह के लिए आवश्यक सेटिंग्स के साथ इंस्टॉलेशन स्क्रिप्ट को कॉपी करता है और वहां इसे निष्पादित करता है।

इसके अलावा, इस एप्लिकेशन में एप्लिकेशन के संभावित संस्करणों को प्राप्त करने और सर्वर पर स्थापित संस्करण का अनुरोध करने के लिए कमांड शामिल है (चित्र संस्करण 1.0.19 से 1.0.20 तक उत्पादन वातावरण में प्रोजेक्ट को अपडेट करने की संभावना दर्शाता है):



और सेटिंग्स फ़ाइल स्वरूप को अधिक सुविधाजनक .yml द्वारा प्रतिस्थापित किया गया है:



इस कंसोल एप्लिकेशन को बिल्ड सर्वर पर तैनात किया गया था, एक वेब इंटरफेस इसे एक पैरामीटर बनाने योग्य जॉब जेनकिंस के रूप में बनाया गया था, जो कंसोल कमांड को निष्पादित करता है:

 /home/projects/installer/installer.phar $command $recipe $environment 

जहां,

• $ कमांड - निष्पादित करने के लिए कमांड का नाम, उदाहरण के लिए, इंस्टॉल, स्थिति, संस्करण
• $ नुस्खा - स्थापना के लिए इच्छित परियोजना के संस्करण को सौंपा गया कोड
• $ वातावरण - सर्वर का एक समूह का वैकल्पिक नाम जिस पर परियोजना को स्थापित करना है

और यह कार्य, बदले में, Parameterized ट्रिगर प्लगिन प्लगइन का उपयोग करके रिलीज शाखाओं के विधानसभा कार्यों के लिए एक डाउनस्ट्रीम परियोजना के रूप में नोट किया गया था।

अंत में

परिणामस्वरूप, हमने निम्न चरणों के साथ निरंतर वितरण को लागू करने की समस्या को सफलतापूर्वक हल किया:

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

भविष्य में

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

जीरा ट्रैकर के साथ विभिन्न प्रकार के एकीकरण की कोशिश करने में रुचि है। किसी तरह, उदाहरण के लिए, स्वचालित:

• एक निश्चित प्रकार के नए टिकटों के लिए शाखाएँ बनाना
• अद्यतन स्थिति और / या परीक्षण के परिणामों के अनुसार टिकट पर टिप्पणी करें
• परिवर्तन लॉग का गठन

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

निष्कर्ष

हमने अपने सामने आने वाली समस्याओं को सफलतापूर्वक हल कर लिया है:

• संस्करण नियंत्रण प्रणाली में अलग-अलग शाखाओं का उपयोग ए / बी संस्करण बनाने के लिए किया जाता है
• पैकेज मैनेजर आपको प्रोजेक्ट से प्रोजेक्ट के लिए कार्यक्षमता का पुन: उपयोग करने की अनुमति देता है
• गेरकिन और उनके कार्यान्वयन पर परीक्षण परियोजना के लिए नए डेवलपर्स के कनेक्शन को आसान बनाने में मदद करते हैं
• और ऊपर वर्णित निरंतर वितरण योजना खेल के ग्राहक भाग के डेवलपर्स से प्रतिक्रिया प्राप्त करने के लिए समय को कम करती है

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

सुएरते!