1C-बिट्रिक्स विकास पद्धति - एक मूर्ख का अनुभव

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

इसके बाद, मैं उन मुख्य समस्याओं का वर्णन करूँगा जिनका मुझे सामना करना पड़ा था, और कई इसी तरह की परियोजनाओं, मेरे द्वारा हल किए गए समाधान और काम के परिणाम।

स्रोत डेटा:

• 1C-Bitrix पर एक ऑनलाइन स्टोर है
• यह परियोजना कई साल पुरानी है, लेकिन कुछ महीने पहले ही साइट को 1C-Bitrix में स्थानांतरित कर दिया गया था
• उपस्थिति 10-15 हजार लोगों को एक दिन
• स्टोर कैटलॉग में लगभग 12,000 आइटम हैं
• साइट डाउनटाइम और शटडाउन की अनुमति नहीं है
• परियोजना को छह महीने के लिए किसी अन्य कंपनी द्वारा विकसित किया गया था:
• 1. लगभग 40% द्वारा किए गए कार्य के अनुसार TK, लगभग 100 शीट हैं
  2. कोई परियोजना प्रलेखन नहीं
  3. पिछले डेवलपर्स ने सिर्फ ऐसे वास्तुशिल्प समाधानों का उपयोग क्यों किया, यह समझने में कमी।

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

सबसे पहले, मुझे परियोजना के स्रोत कोड तक पहुंच मिली। सतही विश्लेषण किया। ग्राहक के साथ प्राथमिक कार्यों की सूची से सहमत हैं। उन्होंने 3 डेवलपर्स के लिए एक विकास योजना बनाई और, जैसा कि गागरिन ने कहा, चलो!

समस्या नंबर 1 - डेवलपर्स को दोष देना है

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

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

परिणामस्वरूप:

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

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

समस्या संख्या 2 - समानांतर विकास।

1C-Bitrix लाइसेंसिंग नीति के अनुसार, साइट के लिए प्रत्येक लाइसेंस आपको सिस्टम की 2 प्रतियों का उपयोग करने की अनुमति देता है। एक, उत्पादन स्थल के रूप में, दूसरा - विकास के लिए। समस्या यह है कि विकास मेरे मामले में, तीन, डेवलपर्स द्वारा लगातार किया जाता है। क्लासिक विकास के मामले में, सब कुछ सरल है। प्रत्येक डेवलपर अपने मॉड्यूल के साथ काम करता है। फिर, प्रत्येक मॉड्यूल का कार्यात्मक परीक्षण किया जाता है, सभी सुधारों को कुछ संस्करण नियंत्रण प्रणाली के भंडार में विलय कर दिया जाता है, फिर इसे सभी (एकीकरण परीक्षण) एक साथ परीक्षण किया जाता है। यदि परिणाम सामान्य है, तो परीक्षण संस्करण ग्राहक को प्रस्तुत किया जाता है। परीक्षण संस्करण को अपनाने के बाद, उत्पादन सर्वर अपडेट किया जाता है। SCRUM पद्धति के अनुसार, मैंने निर्धारित किया कि मैं सप्ताह में एक बार कॉम्बैट साइट पर नए संस्करण अपलोड करूंगा। तदनुसार, मुख्य विकास के लिए 3-4 दिन हैं। 1 दिन परीक्षण और त्रुटियों को ठीक करने के लिए और युद्ध के सर्वर को अपडेट करने के लिए आधा दिन। निश्चित रूप से तारीखों में उतार-चढ़ाव होता है, लेकिन मैंने "हर गुरुवार को जारी" नियमों का पालन करने की कोशिश की।

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

लाइसेंस के बारे में क्या? मैंने 1C-Bitrix के तकनीकी समर्थन से संपर्क किया। मुझे अतिरिक्त खरीदने का प्रस्ताव मिला। विकास लाइसेंस। कम से कम कहने के लिए, मैं खुश नहीं था, लेकिन कोई अन्य प्रस्ताव नहीं मिला। समाधान जल्दी से पर्याप्त पाया गया था। मैंने एनएफआर कुंजियों का उपयोग करने का निर्णय लिया। सौभाग्य से, भागीदार की स्थिति की अनुमति देता है। परिणामस्वरूप, मैंने ऑनलाइन स्टोर के 5 इंस्टॉलेशन बनाए:

• उत्पादन सर्वर
• टेस्ट सर्वर
• 3 विकास सर्वर (एक प्रति डेवलपर)

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

अब मैं निम्नलिखित योजना का उपयोग करता हूं:

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

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

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

समस्या नंबर 3 - उत्पादन सर्वर को अपडेट करना और ग्राहक के साथ मिलकर काम करना

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

यहाँ मर्फी के नियम पूरी तरह से काम करते हैं:

• यदि परीक्षण सर्वर पर कुछ अच्छा काम नहीं करता है, तो यह निश्चित रूप से मुकाबला सर्वर पर टूट जाएगा।
• यदि परीक्षण सर्वर पर कुछ ठीक काम करता है, तो यह निश्चित रूप से युद्ध सर्वर पर टूट जाएगा।
• यदि साइट पर बग केवल 5 सेकंड के लिए मौजूद है, तो आगंतुकों में से एक निश्चित रूप से इसे ढूंढ लेगा और इसके बारे में समीक्षा या प्रतिक्रिया के रूप में लिखेगा।
• यदि साइट अपडेट के दौरान 1 मिनट काम नहीं करती है, तो उसी क्षण कंपनी का मालिक उसे अपने दोस्त या प्रतियोगी को दिखाएगा (और यह अद्यतन करने के लिए समय और प्रक्रिया के समन्वय के बावजूद)।

बेशक, मैं अतिशयोक्ति करता हूं, लेकिन हर मजाक में मजाक का एक अंश होता है। सुबह 4 से 6 बजे तक साइट पर न्यूनतम लोड। इस समय अद्यतन करना निश्चित रूप से बेहतर होगा, लेकिन मैं वास्तव में नहीं करना चाहता।

अधिकांश वेब अनुप्रयोगों के मामले में, एप्लिकेशन को परतों में विभाजित करने और साइट को अपडेट करने के लिए एक स्पष्ट संरचना है, इसे 2 भागों में विभाजित किया जा सकता है:

• प्रोग्राम कोड अपडेट
• SQL स्क्रिप्ट का उपयोग करके डेटाबेस अपडेट

1C-Bitrix के मामले में, सब कुछ थोड़ा और अधिक जटिल है। सबसे पहले, बहुत सारी फाइलें हैं। मेरे पास परियोजना में उनके एक मिलियन से अधिक हैं। रिपॉजिटरी से सामान्य अपडेट 20-30 मिनट से कम नहीं लेता है। आप बेशक केवल संशोधित फ़ाइलों को अपडेट कर सकते हैं, लेकिन फिर रिपॉजिटरी का पूरा अर्थ खो जाता है। दूसरे, और यह बहुत अधिक दुखद है, अक्सर अद्यतन करते समय आपको व्यवस्थापक पैनल के माध्यम से मैन्युअल परिवर्तन और सेटिंग्स करना पड़ता है। और यह हमेशा धीमा होता है, आपको उन सभी परिवर्तनों को याद रखने की आवश्यकता है, जो गलती से होने की संभावना है, गलती से गलती करने की संभावना अधिक है। आप निश्चित रूप से, एक एसक्यूएल स्क्रिप्ट लिख सकते हैं जो डेटाबेस में सभी आवश्यक परिवर्तन करेगा। सरलतम मामलों में, निश्चित रूप से, हम ऐसा करते हैं। लेकिन ज्यादातर मामलों में, इस तरह की स्क्रिप्ट को लिखना और डिबग करना विकास से अधिक समय लेता है और सभी कार्यों को मैन्युअल रूप से करने और फिर इसकी जांच करने की तुलना में बहुत अधिक समय लगता है।

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

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

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

समस्या नंबर 4 - "इसे मुझे तुरंत करना, यह 5 मिनट के लिए काम है"

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

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

और जब से मैंने बैकअप के विषय पर छुआ, मैं नोट करना चाहता हूं। 1C-Bitrick का उपयोग करके बैकअप निश्चित रूप से अच्छा और सुविधाजनक है, लेकिन बहुत धीमा है। यदि आपको तत्काल डेटाबेस में 1-2 फ़ाइलों या कई मानों को पुनर्स्थापित करने की आवश्यकता है, तो आपको सभी 60 जीबी अनजिप होने तक इंतजार करना होगा। यहाँ सबसे प्रभावी योजना मुझे निम्नलिखित लगती है:

• बाहरी डेटा स्रोत के लिए एक संग्रह के रूप में फ़ाइलों और डेटाबेस का दैनिक बैकअप होना चाहिए।
• हम हमेशा 2 विकल्पों में से एक में अपडेट करने से पहले तुरंत बैकअप बनाते हैं:
• 1. लाइट विकल्प - सर्वर पर पड़ोसी फ़ोल्डर में संपूर्ण प्रोजेक्ट फ़ोल्डर की प्रतिलिपि बनाएँ। डेटाबेस को एक अलग फ़ाइल में डंप के रूप में सहेजा जाता है। हम कुछ भी संग्रह नहीं करते हैं। मामले में आपको डेटाबेस या किसी एक फाइल में कुछ मूल्य को पुनर्स्थापित करने की आवश्यकता होती है, सब कुछ हाथ में और आसानी से सुलभ होगा
  2. भिन्न रूप से मजबूत - पिछले एक के समान, केवल डेटाबेस को किसी अन्य MySQL डेटाबेस में कॉपी करें। यह पूरी तरह से दुर्घटना की स्थिति में, होस्ट फ़ाइल में साइट के रूट फ़ोल्डर को 1-2 मिनट में ठीक करने की अनुमति देगा और प्रोजेक्ट डेटाबेस की प्रतिलिपि के साथ पड़ोसी फ़ोल्डर से काम करना शुरू कर देगा।

निष्कर्ष

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