अपने
लेख के पहले भाग में
, मैंने इस बारे में बात की कि हम कैसे पैच सिस्टम के पहले संस्करण का निर्माण करते हैं। संक्षेप में, हमें सभी डेवलपर्स के लिए सुलभ, उत्पादन पर गंभीर कीड़े को ठीक करने का एक तरीका खोजने की आवश्यकता थी। हालांकि, पहला संस्करण इसकी कमियों के बिना नहीं था: हमने एक अजीब लेआउट पद्धति का उपयोग किया, जिसने पैच के लेआउट की परमाणुता और कोड की स्थिरता की गारंटी नहीं दी।
लेख के इस भाग में, मैं कोड को बिछाने के लिए एक नए तरीके के बारे में बात करूंगा, जिसे हमने अपनी समस्याओं को हल करने की कोशिश करते समय किया था और इसके साथ हमारे पैच सिस्टम को कैसे बदल दिया गया था।
छवि: स्रोतयूनिवर्सल सॉल्यूशन - मल्टीवर्सियल डिप्लॉयमेंट किट
हमारे जुरा सिस्टम की एक और समीक्षा के बाद,
youROCK Nasretdinov ने कहा कि उन्हें इस बात पर विचार है कि हमारी सभी समस्याओं को कैसे हल किया जाए। उन्होंने जो कुछ भी पूछा वह लेआउट सिस्टम का रीमेक बनाने के लिए बहुत समय था। यह इस प्रकार है कि बहुविध तैनाती किट की अवधारणा, या, आम लोगों में, एमडीके दिखाई दिया (जुरा ने इसकी
रिपोर्ट हाईलेड ++ पर अपनी
रिपोर्ट में कोड लेआउट के अन्य तरीकों से की)।
नई प्रणाली को हमारी लेआउट प्रक्रिया को बदलने के लिए डिज़ाइन किया गया था। उन लोगों के लिए जिन्होंने मेरे लेख के पहले भाग को नहीं पढ़ा है, मैं आपको संक्षेप में बताऊंगा कि तैनाती की प्रक्रिया कैसी दिखती है: पहले हम एक निर्देशिका में सभी आवश्यक फाइलों को इकट्ठा करते हैं, फिर हम निर्देशिकाओं की स्थिति को सर्वर पर सहेजते हैं और वितरित करते हैं।
एमडीके युग से पहले, हमने स्टोर और डिलीवर करने के लिए लूप्स नामक ब्लॉक डिवाइस (यानी, फाइल सिस्टम इमेज) का इस्तेमाल किया। निर्देशिका को एक खाली लूप में कॉपी किया गया था, इसे संग्रहीत किया गया था और सर्वर पर भेजा गया था।
नई प्रणाली में, हम संपूर्ण निर्देशिका को नहीं, बल्कि प्रत्येक फ़ाइल को व्यक्तिगत रूप से संस्करणित कर रहे हैं ताकि फ़ाइल का संस्करण उसकी सामग्री के साथ स्पष्ट रूप से संबद्ध हो। निर्देशिकाओं के लिए मानचित्र (मैप्स) होते हैं - विशेष फाइलें जिनमें निर्देशिका में सभी फाइलों के संस्करण दर्ज किए जाते हैं। ये कार्ड संस्करण भी हैं, और यह सब कुछ इस तरह दिखता है:
परिचित लगता है? यह कैसे वस्तुओं को गिट में व्यवस्थित किया जाता है (आप इसके बारे में
यहां पढ़ सकते हैं, लेकिन लेख को समझने के लिए यह आवश्यक नहीं है)।
वर्जनिंग के लिए, हम एमडी 5 हैश से (इसके हेक्साडेसिमल प्रतिनिधित्व से, सटीक होने के लिए) पहले आठ अक्षरों का उपयोग करते हैं, फ़ाइल की सामग्री से लिया जाता है। यह संस्करण फ़ाइल नाम के अंत में या मानचित्र नाम की शुरुआत में लिखा जाता है (ताकि आप उत्पन्न फ़ाइल मैप से मैप फ़ाइल को अलग कर सकें):
कोड संस्करण www रूट निर्देशिका का मानचित्र संस्करण है। वर्तमान मानचित्र को खोजने के लिए, हमारे पास एक प्रतीकात्मक लिंक (सिमलिंक) current.map है।
Git का उपयोग क्यों नहीं करते?इस तथ्य के बावजूद कि एमडीके आंशिक रूप से गिट से विचार उधार लेता है, उनके बीच कुछ मतभेद हैं। सबसे महत्वपूर्ण बात यह है कि फाइलों को कार्य निर्देशिका (अर्थात मशीनों पर) में संग्रहीत किया जाता है। अगर Git केवल एक, वर्तमान, संस्करण को संग्रहीत करता है, तो MDK फ़ाइलों के सभी उपलब्ध संस्करणों को वहां रखता है। इसी समय, कोड के वर्तमान संस्करण में केवल एक सिमलिंक current.map इंगित करता है, जो अपने काम में ऑटोलॉड का उपयोग करता है और जिसे परमाणु रूप से बदला जा सकता है। तुलना के लिए, Git संस्करण बदलने के लिए
git-checkout का उपयोग करता है, जो बदले में फ़ाइलों को बदलता है और परमाणु नहीं है।
MDK के साथ बनाएँ
एमडीके को विधानसभा के अंत में निर्देशिका की स्थिति को बचाने के लिए आवश्यक है। ऐसा करने के लिए, हमारे पास एक विशेष स्थान है, जिसे हमने रिपॉजिटरी कहा है, - फ़ाइलों के सभी संस्करणों का भंडार जो हमारे लिए मूल्य हैं (जो कि हम विघटित करना चाहते हैं)। जब निर्देशिका की नई सामग्री तैयार हो जाती है, तो हम इसमें सभी फाइलों के संस्करणों की गणना करते हैं और लापता लोगों को रिपॉजिटरी को रिपोर्ट करते हैं।
MDK के साथ लेआउट
प्रत्येक प्राप्त सर्वर पर लेआउट के दौरान, हम एक स्क्रिप्ट चलाते हैं जो यह जांचता है कि क्या सभी आवश्यक फाइलें सर्वर पर हैं और उन से अनुरोध करती हैं जो रिपॉजिटरी से गायब हैं। हम करंट को बदलकर केवल वर्जन को एक नए में बदल सकते हैं।
इसे हमारी समस्याओं को कैसे हल करना चाहिए
यह मान लिया गया था कि यदि नए संस्करण में केवल कुछ ही फाइलें बदल गई हैं, तो नई प्रणाली का उपयोग करके इसका असेंबली और लेआउट अलग-अलग फाइलों के रूप में पैच के लेआउट के समय में कम से कम तुलनीय होना चाहिए। यदि ऐसा है, तो प्रत्येक पैच के लिए हम सिर्फ एक नया संस्करण उत्पन्न करेंगे।
MDK कार्यान्वयन
एमडीके में एक खामी थी: अंतिम मशीनों पर, प्रत्येक फ़ाइल का नाम उसका संस्करण होना चाहिए। यह वह है जो आपको एक ही बार में एक फ़ाइल के कई संस्करणों को एक निर्देशिका में संग्रहीत करने की अनुमति देता है, लेकिन यह आपको उपयोगकर्ता को कोड से शामिल करने की अनुमति नहीं देता है - आपको एक विशिष्ट संस्करण निर्दिष्ट करना होगा। इसे उन विभिन्न बगों में जोड़ें जो अच्छी तरह से लेआउट सिस्टम के कोड में बने रह सकते हैं, नया लेआउट एल्गोरिथ्म, जो पुराने वाले की तुलना में अधिक जटिल था, और यह स्पष्ट हो जाएगा कि हमने नए सिस्टम को छोटे चरणों में लागू करने का निर्णय क्यों लिया। हमने एक या दो सर्वरों के साथ शाब्दिक रूप से शुरुआत की और धीरे-धीरे अपनी सूची का विस्तार किया, साथ ही साथ आने वाली समस्याओं को ठीक किया।
यह देखते हुए कि एक नई प्रणाली पर स्विच करने में बहुत समय लगना चाहिए था, हमें यह सोचना था कि संक्रमण काल के दौरान हमारे पैच कैसे काम करेंगे। उस समय, पैच के लेआउट के लिए, हमने mscp स्व-लिखित उपयोगिता का उपयोग किया, जिसने एक समय में एक फाइल रखी। हमने उसे पहले से MDK के साथ सर्वर पर वर्तमान फ़ाइलों को बदलने के लिए सिखाया था, लेकिन हम ऐसे सर्वरों के लिए एक नई फ़ाइल नहीं जोड़ सकते थे (क्योंकि मुझे फ़ाइल नक्शा बदलना था)। मैं कुछ बहुत ही जटिल मध्यवर्ती समाधान पेश नहीं करना चाहता था - क्योंकि हम एक उज्ज्वल भविष्य की ओर जा रहे थे, जहाँ mscp की आवश्यकता नहीं है। नतीजतन, मुझे इस समस्या से जूझना पड़ा। सामान्य तौर पर, संक्रमण की अवधि के दौरान, डेवलपर्स को नुकसान हुआ, लेकिन अब यह हमें लगता है कि यह इसके लायक था।
किसी पर विश्वास न करें
छवि: स्रोतशायद, सवाल तार्किक होगा, लेकिन क्या एमडीके में संस्करणों की टक्कर होगी (यानी, ऐसी स्थिति जिसमें विभिन्न सामग्रियों वाली दो फाइलें एक ही संस्करण को सौंपी जाती हैं)?
वास्तव में, हम इस तरह की त्रुटि से काफी सुरक्षित हैं। हम इस तरह
{ }.{} फाइलों को
{ }.{} :
{ }.{} , जिसका अर्थ है कि त्रुटि होने के लिए आठ से अधिक वर्णों का मिलान होना चाहिए।
लेकिन एक बार कुछ गलत हो गया। अगली गणना के बाद, हमने HTTP कोड 404 (फ़ाइल नहीं मिली) के साथ त्रुटियों की बढ़ती संख्या पर ध्यान दिया। एक छोटी सी जांच से पता चला कि कुछ स्थिर फाइलें गायब थीं। यह पता चला कि हमने एक बहुत पुराना स्थैतिक मानचित्र तैयार किया है और उन फाइलों के लिंक दिए हैं जो पहले से ही सर्वर पर नहीं होनी चाहिए। लेकिन यह कार्ड कहां से आया? लेख के पहले भाग में, मैंने नोट किया कि स्थैतिक को एक अलग प्रक्रिया द्वारा विघटित किया जाता है, और केवल संस्करण मैप PHP कोड के साथ निकलता है। जब हम MDK का एक नया संस्करण उत्पन्न करते हैं, तो हम फाइलों के गुम हुए संस्करणों को रिपॉजिटरी में रिपोर्ट करते हैं, जहाँ से कुछ भी डिलीट नहीं होता है (बहुत जगह होती है, हमें कोई आपत्ति नहीं है)। और हम अक्सर मंचन के लिए शुभकामनाएं देते हैं, और इसलिए स्टेटिक्स संस्करण का नक्शा उन फ़ाइलों में से एक है जो दूसरों की तुलना में अधिक बार बदलते हैं। यह सब इस तथ्य के कारण था कि हम एक टकराव के साथ सामना कर रहे थे। संस्करण की जांच करने के बाद, एमडीके ने फैसला किया कि सब कुछ ठीक है, क्योंकि इस तरह के एक संस्करण की एक फाइल पहले से मौजूद है, और इसे सर्वर पर रखी गई है। यह अच्छा है कि हमने त्रुटि को जल्दी खोज लिया।
अब, संस्करण के अलावा, हम फ़ाइल आकार की जांच करते हैं: यदि यह रिपॉजिटरी में समान है, तो सबसे अधिक संभावना है कि यह एक ही फाइल है। सबसे खराब स्थिति में, हमारे पास एक नए लेख के लिए एक कहानी होगी।
एमडीके - क्रिसमस चोर
छवि: स्रोतऔर मैं आपको एक और गलती के बारे में बताना चाहता हूं, क्योंकि यह कम से कम मजाकिया है। यह अनुमान लगाना आसान है कि हमारे पास गंतव्य सर्वर पर फ़ाइलों के पुराने संस्करणों को साफ करने की एक प्रक्रिया थी। समस्याओं में से एक को जल्दी से हल करने के प्रयास में, हमने एक भाग्यपूर्ण निर्णय लिया: सफाई की अवधि एक दिन (सात के बजाय, जैसा कि पहले था) निर्धारित करें। यह काम किया - और समस्या दूर हो गई है। हम भी कुछ समय तक जीवित रहे।
रविवार को सुबह लगभग पाँच बजे, मेरे बेडरूम में एक टेलीफोन बजता था, और कॉल पर निगरानी रखी जाती थी: “लिपियाँ हमारे काम नहीं आतीं। वे कहते हैं कि आप जानते हैं कि क्या मामला है। " मेरे लिए, यह लग रहा था कि "कार्यालय में, जूसर बाहर जला दिया गया। वे कहते हैं कि आपको पता है कि क्या मामला है। " मुझे केवल लेखों और कहानियों से हमारे स्क्रिप्टिंग ढांचे के सिद्धांतों के बारे में पता था, मेरे पास उनके साथ कोई "व्यक्तिगत संबंध" नहीं था, और इससे भी अधिक, मैंने कभी भी उनकी मरम्मत नहीं की। लेकिन मैं यह जानने के लिए सर्वर पर चढ़ गया कि क्या हो रहा है, और पाया कि समस्या वास्तव में "हमारी तरफ" थी: सर्वर पर कोई कोड नहीं था।
मैंने फिर से कोड अपलोड किया - और यह काम किया। वैसे, त्रुटि, आदिम निकली: शनिवार को, एमडीके का एक भी नया संस्करण नहीं रखा गया था, और सफाई स्क्रिप्ट, जैसा कि यह निकला, वर्तमान संस्करण को हटाने के लिए कोई भी जांच नहीं की। नतीजतन, सुबह पांच बजे उन्होंने (एक शेड्यूल पर) सभी सर्वर से कोड को हटा दिया। इस कहानी के बाद, हमें एहसास हुआ कि पुरानी सेटिंग्स के साथ, यह 7 दिनों की छुट्टियों पर आएगा, उदाहरण के लिए, नए साल की छुट्टियों पर, बस क्रिसमस की पूर्व संध्या पर। "मसीह का जन्म हुआ - कोड चला गया" - लंबे समय तक हम इस मजाक को सुन सकते थे।
नई पैच प्रणाली
अंत में, हमने एक नया लेआउट सिस्टम पेश किया - और यह पैच सिस्टम को फिर से करने का समय है। Mscp की अब कोई आवश्यकता नहीं थी और नए संस्करणों को बनाने से बचने की कोई आवश्यकता नहीं थी। सबसे पहले, हमने पैच के जीवन चक्र को बदल दिया। अब, परिवर्तनों की पुष्टि करने के बाद, वह डेवलपर के पास वापस जाता है, जो पैच की गणना के लिए तैयार होने पर निर्णय लेता है। वह Deploy बटन पर क्लिक करता है, जिसके बाद हम MDK के एक नए संस्करण को मास्टर, जनरेट और तैनात करने के लिए पैच जोड़ते हैं। इस स्तर पर डेवलपर की भागीदारी की अब आवश्यकता नहीं है।
हमने एक बहुत अच्छी लेआउट गति प्राप्त की है: परिवर्तन सर्वर पर शाब्दिक रूप से एक मिनट में मिलते हैं। ऐसा करने के लिए, हालांकि, हमें कुछ ट्रिक्स का सहारा लेना पड़ा: उदाहरण के लिए, हम अभी भी स्टैटिक्स या अनुवाद नहीं बनाते हैं - इसके बजाय, हम पिछले विघटित बिल्ड से संस्करण लेते हैं। इस वजह से, हम जेएस और सीएसएस फाइलों के लिए पैच पर प्रतिबंध बनाए रखते हैं।
प्रयोगों
हम वास्तव में उन सभी समस्याओं को हल करने में कामयाब रहे जो हमारे पास पहले थीं। अब आपको यह सोचने की ज़रूरत नहीं है कि परिवर्तनों को सही ढंग से कैसे बनाया जाए, जो फ़ाइल-दर-फ़ाइल लेआउट के साथ कठिनाइयों का कारण नहीं बनेगा - बस स्टैटिक्स को स्पर्श न करें, और सब कुछ काम करेगा।
लेकिन एक नई मुश्किल सामने आई। पहले, हमने डेवलपर्स को अपने परिवर्तनों को एक या अधिक सर्वरों पर पोस्ट करने की अनुमति दी, बस यह सुनिश्चित करने के लिए कि सब कुछ उनके साथ काम करेगा। नई प्रणाली के साथ, यह सुविधा गायब हो गई, क्योंकि मास्टर अब अपवाद के बिना सभी सर्वरों के लिए वर्तमान संस्करण बन गया है।
छवि: स्रोतइस वजह से, पैच सिस्टम के लिए एक नई आवश्यकता दिखाई दी है: आपको मास्टर में परिवर्तन को जोड़ने के बिना सर्वर की थोड़ी संख्या पर अपने परिवर्तनों की जांच करने की क्षमता की आवश्यकता है। हमने नई कार्यक्षमता प्रयोगों को बुलाया।
डेवलपर के लिए, प्रक्रिया कुछ इस तरह दिखती है: उन्नयन प्राप्त करने के बाद, एक नया पृष्ठ पैच सिस्टम इंटरफ़ेस में उपलब्ध हो जाता है जहां आप उन सर्वरों का चयन कर सकते हैं जिन पर आप प्रयोग करना चाहते हैं। यह सर्वर, एक सर्वर या किसी भी संयोजन का समूह हो सकता है जिसे हमारा सिस्टम समझेगा। सिस्टम पैच को दिखाता है और डेवलपर को सूचित करता है। उसी समय, प्रभावित सर्वर से नवीनतम त्रुटियों का एक लॉग पृष्ठ पर दिखाई देता है।
हम किसी भी तरह से डेवलपर्स को सीमित नहीं करते हैं, वे एक ही सर्वर पर प्रयोग कर सकते हैं। एक 10% क्लस्टर पर प्रयोग कर सकता है, दूसरा पूरे क्लस्टर पर।
यह इस तथ्य के कारण संभव हो गया कि हमारे पास "पैच का संस्करण" था जो हमारे पास बहुत कमी थी। यह एक ऐसा संस्करण है जो सिद्धांत रूप में प्रत्येक सर्वर के लिए अद्वितीय हो सकता है। यह कॉमा द्वारा अलग किए गए पहचानकर्ताओं की एक स्ट्रिंग की तरह दिखता है, उदाहरण के लिए, "32,45,79"। इसका मतलब यह है कि सर्वर में विज़ार्ड और पैच 32, 45 और 79 नंबर से सभी परिवर्तन होने चाहिए। ऐसे प्रत्येक संस्करण के लिए, हम एमडीके का अपना संस्करण तैयार करते हैं। हम मुख्य शाखा से नवीनतम परिवर्तन लेते हैं, और फिर क्रमिक रूप से प्रत्येक पैच को लागू करते हैं। यदि किसी एक संस्करण की पीढ़ी के दौरान संघर्ष उत्पन्न होता है, तो हम केवल नवीनतम पैच के लिए प्रयोग को रद्द करते हैं और डेवलपर को सूचित करते हैं।
जनरेट की गई फाइलें
पैच सिस्टम के अस्तित्व के पहले दिन से, हम चाल में गए: हमने स्थैतिक उत्पन्न करने से इनकार कर दिया ताकि परिवर्तन सर्वर तक जल्द से जल्द पहुंच जाए। बेशक, हम वास्तव में जेएस-कोड को उसी तरह बदलने का अवसर प्राप्त करना चाहते थे जैसे कि हम पीएचपी-कोड को बदलते हैं, लेकिन इस प्रक्रिया के निर्माण के सभी प्रयास असफल रहे।
लगभग छह महीने पहले, हम फिर से इस मुद्दे पर लौट आए। उद्देश्य: आपको स्टैटिक्स को बदलने की आवश्यकता है, लेकिन आप PHP-code के लेआउट की गति का त्याग नहीं कर सकते। मुख्य समस्या: एक पूर्ण विधानसभा में आठ मिनट लगते हैं। क्या करें?
आपको समझौता करना होगा। हमने इस तथ्य के साथ शुरुआत की कि जेएस कोड को प्रयोगों के हिस्से के रूप में नहीं रखा जा सकता है। इससे बहुत समय बचा होना चाहिए: बस स्टैटिक्स के एक संस्करण को मशीनों के विभिन्न समूहों के लिए दर्जनों अलग-अलग संस्करण बनाने के बजाय अद्यतित रखें। लेकिन यह अभी भी एक लंबा समय है। आप और क्या बचा सकते हैं? हमने यह पता नहीं लगाया कि समय को कैसे कम किया जाए, लेकिन यह तय किया कि असेंबली को PHP कोड के लेआउट को ब्लॉक नहीं करने पर कोई समस्या नहीं होगी।
हमने एसिंक्रोनस रूप से स्टैटिक्स उत्पन्न करना शुरू कर दिया। जेएस या सीएसएस फाइलों में परिवर्तन के साथ, हम एक अलग प्रक्रिया शुरू करते हैं जो स्थैतिक संस्करणों का एक नया नक्शा बनाता है। काम की शुरुआत में PHP कोड को इकट्ठा करने की प्रक्रिया यह देखने के लिए करती है कि क्या कोई नया स्थैतिक मानचित्र है, और, यदि कोई है, तो इसे उठाता है और सभी सर्वरों पर इसे देता है। क्या आपने समस्या का समाधान किया? व्यवहार में। इस दृष्टिकोण के साथ, हम एक नई सीमा के लिए गए: आप JS और PHP कोड को एक पैच में नहीं बदल सकते, क्योंकि हम इन परिवर्तनों को असिंक्रोनस रूप से विघटित करते हैं और गारंटी नहीं दे सकते कि वे एक ही समय में मशीनों पर होंगे।
परिणाम
हम अपडेट से बहुत खुश हैं। यह हमारे लिए आसान नहीं था, लेकिन इसने हमारे सिस्टम को और अधिक विश्वसनीय बना दिया। डेवलपर्स को प्रयोगों के लिए एक वैकल्पिक एप्लिकेशन मिला: उनके साथ आप मास्टर में अपने परिवर्तनों को जोड़े बिना आसानी से सर्वर की एक जोड़ी से विशिष्ट लॉग एकत्र कर सकते हैं।
हमारे पास अभी भी व्यवस्था में सुधार के लिए विचार हैं, जिनके कार्यान्वयन के लिए अभी पर्याप्त समय नहीं है। उदाहरण के लिए, हम एक पैच बनाने की प्रक्रिया को फिर से करना चाहते हैं और नवीनतम प्रतिबंधों से छुटकारा पाने के लिए मुख्य कोड के रूप में एक ही समय में जेएस फाइलों को बदलने की क्षमता जोड़ते हैं।
हर दिन हम लगभग 60 पैच पोस्ट करते हैं, कभी-कभी कई गुना अधिक होते हैं, उदाहरण के लिए, कुछ कार्यक्षमता के विकास के दौरान जो अभी तक केवल परीक्षकों के लिए उपलब्ध है। लगभग एक तिहाई पैच प्रयोग से पहले ही निकल जाते हैं। कुल मिलाकर, सिस्टम के अस्तित्व के दौरान, हमारे पास मास्टर के लिए लगभग 46,000 पैच थे।