पैच अगर आप कर सकते हैं: कैसे हम उत्पादन पर डिबगिंग कर रहे हैं। भाग 1

UPD: लेख का दूसरा भाग तैयार है ।

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

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


छवि: स्रोत

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

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

हमें क्या चाहिए?

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

हमने पहला प्रश्न जल्दी से जल्दी तय किया: हमने एक रूप बनाया, जिसमें हमें अपने परिवर्तनों को संलग्न करना था और विवरण (समीक्षक और कार्य) को इंगित करना था।


दूसरे पृष्ठ पर, आप परिवर्तन देख सकते हैं, उन्हें अस्वीकार या स्वीकार कर सकते हैं।



पुष्टि के बाद, परिवर्तन मास्टर में गिर गए।

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

निष्पक्ष विधानसभा

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

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

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

निष्पक्ष लेआउट

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

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

कोई विधानसभा नहीं

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

यह जीवित है

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

लेकिन, निश्चित रूप से, लेआउट की इस पद्धति के साथ, हमें समस्याएं थीं। कुछ अनुमान लगाने योग्य थे, कुछ हमने किसी तरह तय भी किए। उनमें से ज्यादातर समानांतर में फ़ाइल संपादन से संबंधित थे।

एकाधिक फ़ाइलों के लिए एक पैच

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


नतीजतन, हम एक तकनीकी समाधान नहीं ढूंढ सके, लेकिन हमें पता चला कि जीवन को थोड़ा सरल कैसे बनाया जाए: हमने इंटरफ़ेस में एक कार्रवाई के साथ कई फाइलों का लेआउट बनाया। डेवलपर ने फ़ाइलों के लेआउट को निर्दिष्ट किया, और सिस्टम ने उन्हें वितरित किया।

प्रति फ़ाइल एकाधिक पैच

यदि एक फ़ाइल है, तो यह अधिक कठिन है, और कई डेवलपर्स हैं जो इसे बदलना चाहते हैं। हमने पहला पैच लगाया, लेकिन इसे विघटित नहीं किया। इस बिंदु पर, दूसरा पैच आता है और विघटित होने के लिए कहा जाता है। क्या करें? इससे भी अधिक दिलचस्प, अगर दूसरा पैच लगाया जाता है, और इस समय हमें पहले से विघटित करने के लिए कहा जाता है।

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

हम इस समस्या का वास्तव में अच्छा समाधान नहीं करते हैं। हमने डेवलपर्स को यह दिखाया कि वे एक निश्चित समय में मशीनों पर क्या करते हैं और मशीनों पर क्या है, लेकिन यह हमेशा काम नहीं करता था। उदाहरण के लिए, बहुत सारे बदलाव हो सकते हैं, और डेवलपर जल्दी में हो सकता है या बस आलसी हो सकता है (कुछ भी हो सकता है)।

बहुत सारे पैच, और हर कोई एक ही फाइल बदलता है

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


चित्र: स्रोत

आयरन की समस्या

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

हम विघटित पैच के संस्करण के लिए एक सटीक तरीका नहीं ले आए, लेकिन हमने वर्कअराउंड द्वारा समस्या को हल करने का प्रयास किया। उदाहरण के लिए, लेआउट प्रक्रिया के अंत में एक पड़ोसी मशीन से rsync। लेकिन किसी तरह हम किसी तरह जाँच नहीं कर सके।

हम इस समस्या के कई समाधानों पर गए, उदाहरण के लिए, हम "मुख्य" सर्वरों पर भी पैच लागू करना चाहते थे (यह याद रखना महत्वपूर्ण है कि हम पैकेज्ड संस्करण को तैनात कर रहे हैं, यानी हमें पैच लागू करने और संस्करण को वापस पैक करने की आवश्यकता है), लेकिन इसे लागू करना काफी कठिन था।

एक चम्मच शहद

लेकिन, समस्याओं के अलावा, सकारात्मक पहलू भी थे।

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

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

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