कैसे हमने पुरानी झोपड़ी को तोड़ा और उसकी जगह एक गगनचुंबी इमारत बनाई

जावा लीडर के टीम लीडर ज़ुरब बेली ने एक बड़ी कंपनी के प्रोजेक्ट में काम करने की अपनी कहानी बताई और अपने अनुभव साझा किए।

मैं कैसे बस गया ...

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

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

शांती जो हवा में उड़ गई

सबसे पहले, मैंने मुख्य रूप से परियोजना की तकनीकी स्थिति का अध्ययन किया, मामूली कीड़े तय किए और छोटे सुधार किए। तकनीकी दृष्टिकोण से, अनुप्रयोग बहुत ही भयानक लग रहा था: dotCMS के एक पुराने वाणिज्यिक संस्करण के आसपास निर्मित एक अखंड वास्तुकला, जावा 6 वें संस्करण में लिखा गया कोड, जब वेग फ्रेमवर्क पर क्लाइंट के हिस्से का नौवां सर्वर-साइड प्रतिपादन, जो कई साल पहले नहीं हुआ था। का समर्थन किया गया था। प्रत्येक उदाहरण को JBoss AS में लॉन्च किया गया था और Nginx का उपयोग करके रूट किया गया था। मेमोरी लीक के कारण नोड्स का लगातार पुनरारंभ हुआ, और सामान्य कैशिंग की कमी के कारण सर्वर लोड में वृद्धि हुई। लेकिन सबसे बड़ा किरच सीएमएस कोड में किए गए बदलाव थे। उन्होंने अधिक हाल के संस्करण में दर्द रहित उन्नयन की संभावना से इनकार किया। इसका एक अच्छा उदाहरण संस्करण 3.2 से 3.7 तक संक्रमण था, जो उस समय समाप्त हो रहा था। अगले मामूली संस्करण में संक्रमण को एक वर्ष से अधिक समय हो गया। कोई भी लोकप्रिय समाधान, जैसे कि स्प्रिंग फ्रेमवर्क, रिएक्ट.जेएस, माइक्रोसर्विस आर्किटेक्चर, डॉकर, आदि प्रश्न से बाहर नहीं थे। परियोजना में गहराई से जाने पर, ऐसी तकनीकी स्थिति के परिणाम दिखाई देने लगे। उनमें से सबसे तीव्र विकास और डिबगिंग के लिए स्थानीय रूप से एप्लिकेशन को चलाने में असमर्थता थी। 8 लोगों की पूरी टीम ने एक विकास स्टैंड पर काम किया, जहां आवेदन के उत्पादन संस्करण की एक प्रति तैनात की गई थी। तदनुसार, केवल एक ही डेवलपर अपने कोड को उसी समय डिबग कर सकता था, और अपडेट किए गए कोड को रोल करने से पूरी टीम अवरुद्ध हो गई। एपोगी एक असफल बिक्री थी, जिसके दौरान लाखों पत्र, एसएमएस और पुश सूचनाएं विभिन्न उपयोगकर्ताओं को दसियों चैनलों के माध्यम से भेजी जाती थीं - दसियों हज़ारों सत्र एक ही समय में खोले जाते थे। सर्वर इसे खड़ा नहीं कर सकते थे, और अधिकांश समय पोर्टल अनुपलब्ध था। आवेदन अच्छी तरह से पैमाने पर नहीं है। ऐसा करने का केवल एक ही तरीका था: एक और कॉपी साइड पर तैनात करना और उनके बीच के भार को Nginx का उपयोग करके संतुलित करना। और उत्पादन कोड के प्रत्येक वितरण में बहुत सारे मैनुअल काम शामिल थे और कई घंटे लगते थे।

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

हमने बनाया, बनाया ...

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

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

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

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

चरण 1. महत्वपूर्ण समस्या क्षेत्रों की पहचान।

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

चरण 2. कोड आधार को अद्यतन करना।

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

पहले तथाकथित था। "सामग्री सेवा", जो भविष्य के अनुप्रयोग और सीएमएस के बीच एक परत बन गई है। यह सामग्री के रास्ते पर एक अमूर्त बन गया है। यह मान लिया गया था कि हम पहले सीएमएस में सीधे किए गए सभी अनुरोधों को इस सेवा के माध्यम से करेंगे, लेकिन पहले से ही HTTP प्रोटोकॉल का उपयोग कर रहे हैं। इस तरह के एक समाधान ने हमें कनेक्टिविटी को कम करने की अनुमति दी और बाद में dotCMS को अधिक आधुनिक एनालॉग के साथ बदलने या यहां तक ​​कि वाणिज्यिक उत्पादों के उपयोग को समाप्त करने और हमारे कार्यों के अनुरूप अपने स्वयं के समाधान को लिखने की संभावना पैदा की (आगे देखते हुए, मैं कहूंगा कि यह वही तरीका है)।

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

सामान्य तौर पर, कार्यक्षमता को निम्नलिखित एल्गोरिदम के अनुसार सेवा को आवंटित किया गया था:

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

शुरुआत में, हम उनमें से कुछ थे:

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

स्टेज 3. ऑटोटेस्ट्स।

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

चरण 4. तैनाती स्वचालन।

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

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

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

स्टेज 5. खुद का सीएमएस।

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

चरण 6. प्रूफ़ फैलाना।

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

... और अंत में बनाया गया। हुर्रे!

एप्लिकेशन अपडेट शुरू हुए एक साल बीत चुका है। अब ये स्प्रिंग बूट में लिखी गई 26 REST सेवाएँ हैं। प्रत्येक के पास स्वैगर UI में विस्तृत एपीआई प्रलेखन है। क्लाइंट पक्ष को React.js में लिखा जाता है और सर्वर साइड से अलग किया जाता है। पोर्टल के सभी मुख्य पृष्ठ परीक्षणों से आच्छादित हैं। कई प्रमुख बिक्री का संचालन किया। पुरानी तकनीकों से छुटकारा पाने, आधुनिक तकनीकों से संक्रमण और सर्वरों के स्थिर संचालन से डेवलपर्स को दृढ़ता से प्रेरणा मिलती है। "जैसा कि हमने कहा, हम इसे करते हैं" से परियोजना मुख्यधारा में चली गई, जहां हर कोई सफलता में रुचि रखता है, सुधार और अनुकूलन के लिए अपने स्वयं के विकल्प प्रदान करता है। टीम के लिए ग्राहक का रवैया बदल गया है, एक दोस्ताना माहौल बनाया गया है।

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