सतत वितरण और साइटकोर: हमारा कार्यान्वयन

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

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

इस लेख में, मैं शामिल सभी पहलुओं का वर्णन करने की कोशिश करूंगा।

GIT

इस संस्करण नियंत्रण प्रणाली का विकल्प सीडी की हमारी अवधारणा के कारण है, जिसमें हमारे पास प्रत्येक रिपॉजिटरी में तीन मुख्य शाखाएं हैं: देव, स्वीकृति और मास्टर। नामों के अनुसार, प्रत्येक शाखा तीन सर्वरों में से एक पर कोड की स्थिति को दर्शाती है:

• देव = क्यूए, केवल हमारे नेटवर्क पर उपलब्ध एक आंतरिक सर्वर। इस पर बुनियादी परीक्षण किया जाता है।
• स्वीकृति = स्वीकृति सर्वर, हमारे नेटवर्क और ग्राहकों दोनों के लिए सुलभ है, लेकिन अन्य इंटरनेट उपयोगकर्ताओं के लिए उपलब्ध नहीं है
• मास्टर = उत्पादन सर्वर, सभी के लिए सुलभ।

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

टीमकेस और लिपियों / अनुप्रयोगों के साथ वितरण प्रक्रिया

स्थापित करने में आसान, छोटी परियोजनाओं के लिए मुफ्त (20 से अधिक बिल्ड कॉन्फ़िगरेशन नहीं), यह सामान्य संस्करण नियंत्रण प्रणाली के अधिकांश को समझता है (जीआईटी हमने चुना है), MSBuild, nANT, Visual Studio के लिए अंतर्निहित रनर्स है, और इसके लिए पहुँच भी प्रदान करता है डेटा प्राप्त करने और कॉन्फ़िगर करने के लिए restAPI। मेरी राय में, इसकी कक्षा में सबसे सुविधाजनक बिल्ड सर्वरों में से एक (साथ ही अन्य जेटब्रिंस उत्पाद)। इसके अलावा, TeamCity की एक बहुत ही सुविधाजनक विशेषता परियोजना स्तर या सीधे वेब इंटरफ़ेस के माध्यम से निर्माण स्तर पर मापदंडों को कॉन्फ़िगर करने की क्षमता है। सर्वर स्तर पर मापदंडों को कॉन्फ़िगर करना संभव है, साथ ही मेजबान सिस्टम मापदंडों (उदाहरण के लिए, पैट) तक पहुंच।
एक प्रोजेक्ट के लिए एक विशिष्ट बिल्ड जो स्वचालित वितरण और सत्यापन प्रदान करता है कि डिलीवरी के बाद वेब एप्लिकेशन लाइव है (साइट पेज रिटर्न कोड 200) में निम्नलिखित कॉन्फ़िगरेशन पहलू शामिल हैं:
सामान्य सेटिंग्स : प्रत्येक बिल्ड के परिणामों के आधार पर, हम कलाकृतियों को इकट्ठा करते हैं - एक वेब अनुप्रयोग के साथ एक संग्रह, पैकेज के साथ एक संग्रह (साइटकोर पर्यावरण के बीच वितरण के लिए विशेष रूप से बनाई गई और संग्रहीत xml फ़ाइलों का उपयोग करता है, जिसे हम पैकेज कहते हैं) और SQL स्क्रिप्ट के साथ एक संग्रह, यदि समाधान अतिरिक्त डेटाबेस का उपयोग करता है। साथ ही एक ऑटो-इन्क्रीमेंटिंग बिल्ड काउंटर, जिसका उपयोग टीमकेयर असेंबलीइन्फो में निर्मित पैच में किया जाता है, बिल्ड वर्जन को बढ़ाता है।
संस्करण नियंत्रण प्रणाली सेटिंग्स : टीमसिटी असहमति के लिए सरल है और कॉन्फ़िगर करने में आसान है। यहां एकमात्र दिलचस्प बिंदु बिल्ड के परिणामों के आधार पर टैग लगाने की क्षमता है, जो, सैद्धांतिक रूप से, आपको उस कोड पर ठीक लौटने की अनुमति देता है जिसमें कोई समस्या थी / दिखाई दी। जब भी संभव हो, निर्माण को तेज करने और यातायात को कम करने के लिए एक वृद्धिशील चेकआउट का उपयोग यहां किया जाता है।
दरअसल, बिल्ड ही :

1. विज़ुअल स्टूडियो के माध्यम से बिल्ड और प्रकाशक समाधान (वीएस वांछित संस्करण सर्वर पर स्थापित किया जाना चाहिए)। हम sln फ़ाइल के लिए पथ को इंगित करते हैं, चर इंगित करता है जो कॉल करने के लिए इस sln फ़ाइल के लिए कॉन्फ़िगरेशन का निर्माण करता है (प्रत्येक प्रोजेक्ट में शामिल प्रत्येक वातावरण के लिए कई बिल्ड कॉन्फ़िगरेशन हैं)। प्रकाशित को सर्वर पर एक स्थानीय फ़ोल्डर में निष्पादित किया जाता है, क्योंकि एमएस पब्लिश टूल का उपयोग करके वांछित सर्वर पर सीधे वितरण को व्यवस्थित करना संभव नहीं था। पहली और आखिरी समस्या जिस पर मैंने ठोकर खाई, वह यह थी कि हम अलग-अलग डोमेन में हैं। यदि MSBuild त्रुटि होती है, तो बिल्ड बंद हो जाता है और एक सूचनात्मक संदेश निम्न लोगों को भेजा जाता है: वे लोग जिनके निर्माण में भाग लिया गया था, बिल्ड इंजीनियर और परीक्षक।
2. सहेजे गए फ़ाइलों की तैयारी और संकुल (स्क्रिप्ट) की स्थापना के लिए लक्ष्य अनुप्रयोग। इस तथ्य के कारण कि डाटाबेस में नोड्स बनाने से डिफ़ॉल्ट रूप से निषिद्ध है जिसमें विशेष भाषा वर्ण और आरक्षित वर्ण होते हैं, और कभी-कभी आप विकास के दौरान उनके बिना नहीं कर सकते हैं - इस चरण में एक विशेष पैच लक्षित अनुप्रयोग को दिया जाता है जो इन वर्णों के उपयोग की अनुमति देता है। । उसी चरण में, कॉन्फ़िगर पैच वितरित करने के बाद, जिसके कारण एप्लिकेशन पुनः आरंभ होता है, साइट के मुख्य पृष्ठ को प्राप्त करने के लिए wget का उपयोग किया जाता है। यह सुनिश्चित करता है कि एप्लिकेशन ऊपर है और अगले चरण के लिए तैयार है।
3. Sitecore डेटाबेस में नोड्स का वितरण। WCF सेवा को वेब एप्लिकेशन पर तैनात किया जाता है, जो पैकेज स्वीकार करता है और उन्हें स्थापित करता है (मैं आपको याद दिलाता हूं कि साइट संवाददाता विशेष रूप से पर्यावरण के बीच वितरण के लिए विशेष रूप से निर्मित और संग्रहीत xml फ़ाइलों का उपयोग करता है, जिसे हम पैकेज कहते हैं), जो हमें इस प्रक्रिया को निम्न प्रकार से स्वचालित करने की अनुमति देता है: विकास के दौरान, डेवलपर कहते हैं। एक विशेष रूप से नामित फ़ोल्डर में लक्ष्य आवेदन के लिए वितरण के लिए आवश्यक संकुल, जो पाठ्यक्रम नियंत्रण में भी संग्रहीत है। TeamCity स्वतंत्र रूप से इस निर्माण में शामिल परिवर्तनों पर डेटा एकत्र करता है और उन्हें restAPI के माध्यम से एक्सेस प्रदान करता है। वितरण के लिए जिम्मेदार एप्लिकेशन restAPI से xml पढ़ता है, बिल्ड में शामिल पैकेजों का चयन करता है और उन्हें WCF सेवा में भेजता है, जिसके बाद WCF सेवा उन्हें स्थापित करती है। कलेक्टर आवेदन के लिए सभी आवश्यक डेटा पैरामीटर द्वारा प्रोजेक्ट स्तर पर कॉन्फ़िगर किए गए हैं, क्योंकि वे संपूर्ण रिपॉजिटरी के लिए समान हैं। दुर्भाग्य से, WCF सेवा और लक्ष्य एप्लिकेशन की सेटिंग्स से जुड़ी एक समस्या है: यदि पैकेट का आकार बहुत बड़ा है, या इसे स्थापित करने में 20 मिनट से अधिक समय लगता है, तो सेवा डिस्कनेक्ट हो जाती है। यदि कोई त्रुटि होती है - सेवा एक त्रुटि लौटाती है, तो निर्माण बंद हो जाता है, पहले चरण के समान लोगों को सूचनाएं भेजी जाती हैं। सीटीसी को वितरित करने के लिए कुछ होने पर ही डब्ल्यूसीएफ सेवा को कॉल किया जाएगा, जो बिल्ड को गति देने में भी मदद करता है।
4. सामग्री डेटाबेस में नोड्स प्रकाशित करें। इस तथ्य के कारण कि साइटकॉर दो डेटाबेस (मास्टर - जिसमें सामग्री बनाई गई है और वेब - जिसमें से सामग्री अंतिम उपयोगकर्ता तक पहुंचाई गई है) के साथ काम करता है, एक और एप्लिकेशन को मास्टर से डेटा को वेब साइट पर स्थानांतरित करने की प्रक्रिया को लागू करने के लिए बनाया गया था। जिसे प्रकाशित कहा जाता है। यह एप्लिकेशन चरण 3 से एप्लिकेशन के समान सिद्धांत पर काम करता है। डेवलपर एक फाइल को शुरू करता है जिसमें संग्रहीत नोड्स को लाइन-बाय-लाइन किया जाता है, एप्लिकेशन को ये फाइलें restAPI के माध्यम से मिलती हैं (फाइलें रिपॉजिटरी में एक विशिष्ट फ़ोल्डर से कमिट से चुनी जाती हैं, सीमा है) कि फाइलों का एक निश्चित विस्तार होना चाहिए), फाइलों की सामग्री को पढ़ता है और इसे WCF सेवा में भेजता है, जो बदले में, अपने बच्चों के साथ नोड प्रकाशित करेगा। पिछले चरण के विपरीत, जब इस चरण में कोई त्रुटि होती है, तो निर्माण बंद नहीं होता है। साइटकॉर में प्रकाशित करने के लिए कुछ होने पर ही डब्ल्यूसीएफ सेवा को कॉल किया जाएगा, जो गति बढ़ाने में भी मदद करता है।
5. कोड तैयार करना और लक्ष्य सर्वर तक पहुंचाना। इस चरण में, सामान्य cmd स्क्रिप्ट उस समाधान को पैक करता है जो सहेजा गया था और SSH सुरंग के माध्यम से परिणामी संग्रह को अस्थायी निर्देशिका में लक्ष्य सर्वर में संग्रहीत करता है, और संग्रह को अनपैक करते हुए। उसके बाद, App_Offline.htm को वेब एप्लिकेशन फ़ोल्डर में रखा जाता है, जो वेब एप्लिकेशन को रोकता है और उपयोगकर्ताओं को एक संदेश प्रदर्शित करने की अनुमति देता है कि वर्तमान में एप्लिकेशन अपडेट किया जा रहा है।
6. तृतीय-पक्ष डेटाबेस अद्यतन (वैकल्पिक चरण)। यदि एप्लिकेशन न केवल मानक साइटकॉर डेटाबेस का उपयोग करता है, बल्कि अतिरिक्त भी - इस चरण में, ये डेटाबेस एक विशेष फ़ोल्डर में नियंत्रण में संग्रहीत लिपियों का उपयोग करके अद्यतन किए जाते हैं, चरण 3 और 4 से फ़ाइलों के समान। फिलहाल, वांछित स्क्रिप्ट का चयन करें और इसका अनुप्रयोग एक विशेष फ़ाइल नाम प्रारूप (संस्करण नाम) का उपयोग करके किया जाता है। यदि फ़ाइलों का संस्करण डेटाबेस के संस्करण से अधिक है (विस्तारित गुण फ़ील्ड में संग्रहीत), डेटाबेस फ़ाइल से स्क्रिप्ट द्वारा अद्यतन किया जाता है। जल्द ही, डेटाबेस को अपडेट करने की फाइलें कलेक्टर एप्लिकेशन द्वारा चरण 3 और 4 के साथ सादृश्य द्वारा वितरित की जाएंगी। इसके अलावा, निकट भविष्य में, यह कदम WCF सेवा पर निष्पादन के लिए होस्ट सर्वर बिल्ड पर निष्पादन से स्विच करने की योजना है (हालांकि, इसमें आपको मना करना होगा App_Oflline.htm से), जिसे सुरक्षा बढ़ानी चाहिए।
7. आवेदन के लिए कोड वितरण। स्क्रिप्ट एप्लिकेशन में कॉन्फ़िगरेशन और बायनेरिज़ के साथ फ़ोल्डर को साफ़ करती है, फिर चरण 5 में अनकैप्ड फ़ोल्डर से, वेब एप्लिकेशन के फ़ोल्डर में कोड और संबंधित फ़ाइलों को वितरित करता है। स्क्रिप्ट का अंतिम चरण App_offline.htm निकालता है।
8. Wget का उपयोग करके, हमें यह सुनिश्चित करने के लिए साइट का पृष्ठ (आमतौर पर मुख्य एक) मिलता है कि आवेदन जीवित है (कोड 200)। यदि कोड 200 से भिन्न है, तो बिल्ड को विफल माना जाता है।

यह है कि हमारे देश में साइटकोर सीएमएस फ़ंक्शन के आधार पर वेब एप्लिकेशन की स्वचालित डिलीवरी कैसे होती है।

इस दृष्टिकोण के पेशेवरों / विपक्ष / असत्य बन्स

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

1. निर्माण के दौरान, यह आवश्यक है कि इंटरनेट जुड़ा हो। यदि इंटरनेट कनेक्शन में कोई समस्या है, तो बिल्ड विफल हो जाएगा। यह पाँचवें के चरणों पर कोई समस्या नहीं होगी। हालांकि, अगर 5 वें चरण में इंटरनेट बंद हो जाता है - एप्लिकेशन अप्रबंधित रहेगा, और इसे केवल हाथ से ठीक करना संभव होगा।
2. यदि पिछले से ऊपर के चरणों में निर्माण विफल हो जाता है, तो मैं स्वचालित रूप से पिछले संस्करण में वापस आने का अवसर नहीं देखता: डेटाबेस बैकअप स्वचालित रूप से किया जाता है, लेकिन इसे पुनर्स्थापित करना एक लंबी प्रक्रिया है, और तृतीय-पक्ष (और बल्कि महंगे अनुप्रयोगों) के बिना सभी साइटकौर डेटाबेसों का संस्करण बनाना असंभव है। डेटाबेस के साथ - साथ मैं स्वत: कोड रोलबैक की संभावना की कल्पना नहीं कर सकता।
3. कोई 100% मानदंड नहीं है कि डिलीवरी सफल रही: ऐसी परिस्थितियां होती हैं जब परीक्षण पृष्ठ कोड 200 लौटाता है, जबकि अन्य त्रुटियों के साथ विफल हो सकते हैं।
4. SSH के माध्यम से वितरण इसकी स्थिरता और गति के लिए बहुत अच्छा है, लेकिन, एमएस पब्लिश टूल के विपरीत, यह लक्ष्य वेब एप्लिकेशन पर फ़ाइलों को छोड़ देता है जिन्हें समाधान से बाहर रखा गया था। ऐसा नहीं है कि यह एक बड़ी समस्या थी, हालांकि, सिर्फ सादा बदसूरत।