नमस्ते! मैं रूस में एलएम डेवलपमेंट के प्रमुख वालेरी लाप्टेव हूं। दो साल के लिए मुझे एक बड़ा विभाग जुटाने की जरूरत थी, और यह एक दिलचस्प अनुभव था।
तथ्य यह है कि लेरॉय मर्लिन कई देशों में है। फ्रांस में मूल कंपनी को ADEO कहा जाता है। वे फ्रांस, इटली, स्पेन और रूस के लिए कोड लिखते हैं। हमारे व्यवसाय मॉडल अलग हैं: यदि हम रूसी बाजार पर सबसे कम कीमत रखते हैं (निगरानी में सभी प्रतियोगियों से नीचे), तो यूरोप में सब कुछ अलग है। वास्तव में, समुद्र अलग है - लोकेल की विशेषताओं से अन्य कानून तक। एक आदेश रखने के लिए रूस के बुनियादी ढांचे (खाबरोवस्क के समान बहुत बड़े विलंब) और एक अन्य जीवन चक्र की विशेषताएं हैं। यह सब इस तरह के नारकीय कोड को जन्म देता है जिसमें विशाल IF ब्लॉक होते हैं:
दो साल पहले, हमारे पास 60 स्टोर और कई, कई विशलिस्ट फ़ीचर थे। वे लगभग छह महीने में लुढ़के और हमेशा सही ढंग से नहीं। कम प्राथमिकता द्वारा अस्वीकार किए गए सुविधाओं का एक गुच्छा के बाद अंतिम पुआल क्रम में एक पंक्ति क्षेत्र में प्रवेश करने का अनुरोध था, ताकि हम इसे बाद में पार्स कर सकें। यह रूस में प्रसव की सुविधाओं के लिए आवश्यक था, क्योंकि देश एलएम की उपस्थिति के अन्य देशों की तुलना में बड़ा है। उन्होंने हमें इससे इनकार कर दिया, या यों कहें कि उन्होंने कहा कि यह सात से आठ महीने में कहीं होगा।
इत्मीनान से मूल कंपनी के आधे साल का चक्र हमें शोभा नहीं देता। स्वाभाविक रूप से, हमने अपना स्वयं का कोड लिखने का सुझाव दिया, इसे समीक्षा के लिए प्रस्तुत किया और कार्यान्वयन की प्रतीक्षा की ... सच है, इससे अच्छा कुछ नहीं आया।
विशेषताएं धीरे-धीरे क्यों लागू की गईं?
कहानी बहुत सरल है: हमारे दर्जनों स्टोर के बावजूद, हम दुनिया में पहले नहीं हैं। फ्रांस (जहां मूल संगठन है) की जरूरतें हैं, अन्य देशों की जरूरतें हैं। कंपनियों के एक समूह के लिए संभावित लाभ या लागत में कमी के अनुसार उन्हें प्राथमिकता दी जाती है और इस क्रम में निष्पादित किया जाता है। यही है, हमारी विशेषताएं लगभग कभी नहीं बनाई जाती हैं, जब तक कि बहुत भाग्यशाली और किसी तरह के स्प्रिंट में कोई अपना हिस्सा पहले खत्म नहीं कर देगा और बैकलॉग के निचले हिस्से को अलग करने के लिए जाएगा।
दूसरी विशेषता यह है कि जब आप किसी भी विशेषता को मास्टर शाखा में (यहां इस लिगेसी आईएफ-आईएफ-कोड में) रोल करते हैं, तो आपको यह जांचने की आवश्यकता है कि यह अन्य देशों में कैसे व्यवहार करता है। मुझे बैश से
441869 उद्धृत करें:
प्रोग्रामर: ठीक है, कल्पना कीजिए कि आप एक लेखक हैं और परियोजना "युद्ध और शांति" का समर्थन करते हैं। आपके पास TK है - एक अध्याय लिखें कि नताशा रोस्तोवा बारिश में पार्क में कैसे चली। आप लिखते हैं - "बारिश हो रही थी", बचाओ, त्रुटि संदेश उड़ गया: "नताशा रोस्तोवा की मृत्यु हो गई है, निरंतरता असंभव है।" वह मर क्यों रही है? आप समझने लगते हैं। यह पता चलता है कि पियरे बेजुखोव के फिसलन वाले जूते, वह गिर गया, उसकी बंदूक जमीन पर गिर गई और एक पोल पर गोली चल गई, और खंभे से निकली गोली नताशा के पास जा गिरी। क्या करें? बंदूक निष्क्रिय चार्ज? जूते बदलो? हमने पिलर को हटाने का फैसला किया। हमें संदेश मिलता है: "लेफ्टिनेंट Rzhevsky की मृत्यु हो गई है।" यह पता चला है कि अगले अध्याय में वह एक स्तंभ पर झुक जाता है जो अब नहीं है ...
सामान्य तौर पर, जब हम रूसी बॉक्स ऑफिस के लिए कुछ पेश करते हैं, तो कहीं ब्राजील में, कोई व्यक्ति पलटाव कर सकता है।
इसका अर्थ है बहुत बड़ी परीक्षण कवरेज, लंबी पूर्व-रिलीज़ प्रक्रिया और आमतौर पर कोड बनाए रखने की अनिच्छा जो तेजी से बढ़ रही है। इसलिए, कम विशेषताएं - बेहतर। लेकिन तुम वहीं पकड़ लेते हो।
एक पूरे के रूप में स्थिति बहुत समझ में आती है, और मैं मूल कंपनी की साइट पर बस यही करूंगा। क्योंकि यह तर्कसंगत है।
समस्या हल करना
पहला दृष्टिकोण माथे पर था: हमने सुझाव दिया कि हमारे लिए एक कोड खोलने का अनुरोध किया गया था ताकि हम वहां अनुरोध कर सकें। यह माना जाता था कि वहां लगभग 10 डेवलपर्स बैठे होंगे जो व्यापार के महत्वपूर्ण कार्यों को जल्दी और जल्दी से कोड करेंगे, उन्हें फ्रेंच को देंगे, और वे अपनी प्रक्रिया के अनुसार परीक्षण करेंगे, और सब कुछ ठीक होगा।
वास्तव में ये लोग पहले से ही थे: हम अतिरिक्त व्यापार तर्क को काटने में लगे हुए थे जो हमें अन्य देशों से प्राप्त हुए थे, जैसे कि विभिन्न संचयी छूट और असामान्य स्टॉक (जो हमारे व्यापार मॉडल के साथ असंभव हैं), और इस जगह में डमी डालते हैं।
ADEO में फ्रांसीसी खुद के माध्यम से नए संस्करणों को रोल करने और स्थापित करने के लिए एक रिलीज चक्र चाहते थे। प्रयोगों के लिए एक शाखा के बारे में हमारी पेशकश को स्वीकार कर लिया।
समीक्षा के लिए कोड लेना शुरू कर दिया। यह वैसे भी धीमी गति से निकला। कई महीनों के लिए रोलआउट - यह मामला नहीं है। खैर कुछ हफ़्ते जीते, लेकिन फिर भी यह प्रक्रिया ठीक नहीं हुई।
फिर, छह महीने के लिए, सामग्री भाग में हमारे लिए महत्वपूर्ण एक विशेषता (उत्पाद डेटा का प्रबंधन जो ग्राहक देखता है) बाहर नहीं आया। हम बिना रिलीज़ के छह महीने तक बैठे रहे। या तो उनकी सुविधा नहीं हुई, या परीक्षण पास नहीं हुए, तब उन्हें बिल्कुल एहसास नहीं हुआ कि हमें क्या चाहिए। नतीजतन, हम अपडेट के बिना लंबे समय तक एक महत्वपूर्ण सिस्टम पर बैठे। सामने NodeJS + PostgreSQL + Couchbase + Elasticsearch + Angular थे। कोड में, कई पुरातात्विक परतों के कारण, चीजों का सामना किया गया है, जैसे कि SQL डेटाबेस का दुरुपयोग और गैर-संबंधपरक डेटाबेस। एक स्थान पर, मास्टर डेटा का एक बड़ा टुकड़ा लिया गया था, SQL डेटाबेस के एक क्षेत्र में डाला गया, और फिर NoSQL डेटाबेस में संस्थाओं में विभाजित हो गया। माल के प्रदर्शन के साथ साइट के एक पृष्ठ पर दसियों और सैकड़ों ऐसे अनुरोध थे। इस विरासत को आगे पढ़ने के साथ, शरीर के विभिन्न हिस्सों पर बाल निकलने लगे। हमें समझ में आया कि मुखिया की विरासत की विरासत की कौन-कौन सी खासियतें हैं।
खुद का विकास
पहले विचार एक साथ सुविधाओं को करने का था। मौके पर, वह है, फ्रांस में। हम चारों फ्रांस गए और अपने सहकर्मियों के साथ बैठकर एक साथ सब कुछ समझने और हमारी आवश्यकतानुसार काम करने लगे।
यह काम नहीं किया सभी समान, सब कुछ बहुत धीमा था।
दूसरा विचार यह था कि सभी पहले से मौजूद हैं और धीरे-धीरे इसे खत्म कर दें। हम वास्तु समिति द्वारा बैठ गए, संभावनाओं का मूल्यांकन किया, अनुमानित विकास योजनाओं की गणना की और महसूस किया कि हमें एक अलग विधि चुनने की आवश्यकता है। विशेष रूप से, हाँ, कांटा करने के लिए, लेकिन मौजूदा कोड को विकसित करने के लिए नहीं, बल्कि मोनोलिथ को भागों में तोड़ने के लिए और जहां आवश्यक हो, वहां माइक्रोसेवा डाल दिया।
यही है, हमने अपने कोड के रूप में तर्क के पूरे ब्लॉक को फिर से लिखने की योजना बनाई है। और इसके लिए वे हमारे साथ क्या किया जा सकता है, सेवाओं का हिस्सा बदलना शुरू कर दिया। हमने डेवलपर्स को भर्ती करना शुरू किया। तब हमने पूरी तरह से मूल कंपनी के ढेर का अनुसरण किया - जावा, स्प्रिंग और सब कुछ पास में है, काउचबेस के बजाय मैंगो था (यह एक समान NoSQL-base है)।
जैसे-जैसे परियोजना विकसित हुई, हमने महसूस किया कि हमें अपने तरीके से बहुत कुछ करने की ज़रूरत है (क्योंकि यह तेज़ और आसान है ताकि विरासत का समर्थन न करें जिसे हमें विशेष रूप से ज़रूरत नहीं है), और अन्य तकनीकों का विस्तार करना शुरू कर दिया। तब जावा 7, वाइल्डफ्लाय (पूर्व में जेबॉस) और एसवीएन थे। हमने पूछा कि वे जावा 8, जीआईटी, और टॉमकैट की ओर क्यों नहीं जा रहे हैं। यह पता चला कि वे बुरा नहीं मानेंगे, लेकिन कुछ साल बाद। इस बीच, प्रिय, पुराने स्टैक पर लिखें। इसलिए हमने शब्द के लिए शब्द दिया और पूरी तरह से अलग होने का फैसला किया। व्यवसाय ने इस प्रश्न को हल किया, कि पेशेवरों और विपक्षों ने क्या किया है, और इसका पूरी तरह से समर्थन किया है।
लगभग तुरंत 30 प्रतिशत कोड को फेंक दिया, उनके चारों ओर बहुत सारे माइक्रोसेर लिखे। इस तथ्य से कि वे स्पर्श नहीं करते थे, यह पैसे के लिए व्यापार प्रक्रियाओं के लेनदेन का लगभग संपूर्ण मूल है।
स्वाभाविक रूप से, पहली चीज जिसके बारे में हमने सोचा था कि विकास के क्षेत्रों के बीच अंतर कैसे किया जाए। मैं इस बारे में अलग से बात करूंगा, लेकिन सामान्य शब्दों में, योजना इस प्रकार है:
क्षैतिज एक व्यावसायिक क्षेत्र है। उदाहरण के लिए, ग्राहक संबंधों (पहले ग्रीन सेल) से संबंधित सब कुछ एक क्षेत्र है, और एक विभाग से आवेदनों का एक सेट है। उद्देश्य फ़ंक्शन का यह पृथक्करण विभिन्न स्थानों में कोड के कई डुप्लिकेट बनाता है और एक अच्छी कॉर्पोरेट बस (फिर से, एक अलग कहानी) की आवश्यकता होती है, लेकिन यह आपको स्पष्ट रूप से सिरों को खोजने और परिणाम तक समस्या को हल करने की अनुमति देता है। लगभग तीन साल बाद इसे देखते हुए, मैं कह सकता हूं कि वास्तुकला को सही तरीके से चुना गया था, लेकिन अगर मुझे पता था कि मैं अब क्या जानता हूं, तो मैं कुछ बदलाव करूंगा।
अब हम इस निष्कर्ष पर पहुंचे हैं कि सामान्य संरचना में कई फीचर टीमें हैं जो बड़ी उत्पाद टीम बनाती हैं। इसी समय, उत्पाद टीम में न केवल डेवलपर्स स्वयं शामिल हैं, बल्कि डिजाइनर और व्यवसाय प्रतिनिधि भी शामिल हैं। चूंकि किसी कंपनी के किसी भी आईटी विभाग का अंतिम लक्ष्य व्यावसायिक विकास की गति को बढ़ाना है, या स्वचालन के कारण लागत को कम करना है, हमें इन टीमों के भीतर व्यापार प्रतिनिधियों की आवश्यकता है। रिटेल सभी आईटी के बारे में है। एक भी प्रक्रिया नहीं है जिसे "अप्राप्य" कहा जा सकता है।
एक फीचर टीम लोगों का एक छोटा समूह है (आमतौर पर एक विश्लेषक, परीक्षक, बैक-एंड डेवलपर और फ्रंट-एंड डेवलपर, ऑप्स)। विश्लेषक आमतौर पर उत्पाद के मालिक की भूमिका निभाता है या व्यवसाय का एक व्यक्ति इस जगह पर आता है। मालिक के पास एक बैकलॉग, प्राथमिकता, कार्य हैं। वह उनके विकास का हुक्म देता है। डेवलपर खुद कार्यान्वयन विकल्प चुनता है, टीम में चर्चा करता है कि क्या किया जाएगा और कैसे। हमारे पास कार्य मूल्यांकन, कोडिंग और निर्णय लेने के लिए कोई टीम लीड नहीं है। हर कोई सब कुछ करता है। आमतौर पर अधिक अनुभवी टीम के सदस्य राय देते हैं कि कई लोग भरोसा करने को तैयार हैं। लेकिन कोई भी निर्णय ले सकता है। जब दो डेवलपर्स किसी फीचर के कार्यान्वयन पर सहमत नहीं हो सकते हैं, तो निश्चित रूप से संघर्ष होते हैं। यदि संघर्ष व्यक्तित्व में बदल गया - तो आपको सिर की ओर बढ़ने की आवश्यकता है। लेकिन इसमें से अधिकांश कार्यान्वयन के लिए एक समाधान का विकल्प है। तब हर कोई बोर्ड के पास खड़ा होता है और तब तक ड्रॉ करता है जब तक कि वह एक ऐसा विकल्प न खोज ले जो सभी के अनुकूल हो। आमतौर पर यह जल्दी से निकल जाता है, लेकिन ऐसे मामले थे जब वे पूरे दिन बहस करते थे। जब तर्क एक ठहराव की ओर आता है, तो रेफरी को अक्सर कहा जाता है - दूसरी टीम का एक व्यक्ति जिसकी राय पर सभी को भरोसा है। वे समस्या का सार बताते हैं, वह हल करता है। यहां तक कि एक जून या प्रशिक्षु इस विवाद में सिद्धांत से भाग ले सकता है, लेकिन मैं केवल ऐसे मामलों के एक जोड़े को जानता हूं - आमतौर पर जोंस के पास एक संरक्षक होता है जिसे वे सुनते हैं।
एक फीचर टीम का एक उदाहरण: हमारे पास एक सेवा मंच है जो आपको माल के साथ एक ठेकेदार के साथ एक सेवा खरीदने की अनुमति देता है। उदाहरण के लिए, मैंने एक दरवाजा खरीदा - आप तुरंत टोकरी और स्थापना में डाल सकते हैं, ताकि एक स्वतंत्र मास्टर हमारे मानक के अनुसार आए और करे। हम जांच करेंगे और भुगतान करेंगे, गारंटी देंगे। इसलिए, यह टीम एक उत्पाद बनाती है, इसके लिए यह आईटी समाधान लिखती है और व्यापार निर्णय लेती है, दुकानों में प्रक्रिया बदलती है। ठेकेदारों से सहमत हैं। वहाँ - व्यवसाय से उत्पाद का मालिक, दुकानों से क्लर्क, वास्तुकार, डेवलपर्स, विश्लेषक और परीक्षक। वे तुरंत हमारे कॉरपोरेट एपीआई प्लेटफॉर्म का उपयोग सभी डेटा को आगे और पीछे करने के लिए करते हैं और एक माइक्रोसेवा लिखते हैं। इस तरह के एक दृष्टिकोण - डेवलपर्स और एक छोटी टीम के साथ संयोजन के रूप में तुरंत परिचालन और व्यापार करने वाले लोग - आपको जल्दी से एक उत्पाद बनाने की अनुमति देता है। लेकिन, मुझे लगता है, यह बेहतर है कि वे खुद आपको बाद में बताएं कि यह अंदर से कैसा दिखता है।
प्रारंभ में, हम अलग-अलग परीक्षक नहीं करना चाहते थे: एक प्रवृत्ति थी कि डेवलपर को या तो TDD कार्यप्रणाली का पालन करना चाहिए या अपने कोड को अंत में स्वयं परीक्षण करना चाहिए। वास्तव में, यह बहुत प्रभावी नहीं था। पहले तो सब ठीक रहा: लिखा - आपने जवाब दिया। आपको अपने एप्लिकेशन को सही ढंग से काम करने के लिए परीक्षणों की आवश्यकता है। लेकिन फिर, जितने अधिक कार्य और अनुप्रयोग बने, यह उतना ही कठिन था। कुछ एप्लिकेशन मर गए, कुछ ठेस गए और महीनों तक नहीं बदले। परीक्षण लिखना, उन्हें बनाए रखना, इत्यादि कठिन हो गया। टीम के विश्लेषक बदल गए हैं। अपेक्षाकृत हाल ही में, वे सहमत हुए कि वे गलत थे: परीक्षकों की आवश्यकता है। लेकिन डेवलपर्स परीक्षण लिखना बंद नहीं करते हैं और - कभी-कभी - टीडीडी कर रहे हैं। हमने खुद के लिए महसूस किया कि परीक्षण जो कार्यक्षमता की जांच करते हैं (एप्लिकेशन सही ढंग से काम करता है) और वे परीक्षण जो यह सत्यापित करते हैं कि आवेदन समस्याग्रस्त स्थितियों में काम करता है, विभिन्न लोगों द्वारा किया जाना चाहिए। और दूसरे के लिए, परीक्षकों की आवश्यकता होती है, क्योंकि वे न केवल इकाई परीक्षणों के साथ अजीब मामलों को कवर करते हैं।
अब 60 शुद्ध डेवलपर्स हैं - बैक, फ्रंट, फुल स्टैक्स। विश्लेषक, परीक्षक और समर्थन भी हैं। और इसके अलावा एक अतिरिक्त सात और devops। लेकिन फिर भी, शीर्षक से 200 नियोजित लोगों को भर्ती नहीं किया जाता है, इसलिए हम अब नए लोगों की तलाश कर रहे हैं, क्योंकि कार्यक्षेत्र बहुत बड़ा है।
माय सर्कल में रिक्तियां हैं, यदि वह है। यही है, विकास से अब हमारे पास लगभग 200 में से 74 हैं।
InnerSource
यह देखते हुए कि हमारे पास केवल रूस में कई स्वतंत्र टीमें हैं, और अभी भी ऐसी टीमें हैं, जिन्होंने कई अन्य देशों में भी ऐसा ही कुछ देखा है, हम
इंसोर्स की दिशा में आगे बढ़ रहे हैं। यह लोगों के एक सीमित समूह के भीतर खुले स्रोत के समान है।
सभी देश डिवीजनों के ADEO समूह के भीतर, सभी कोड क्लाउड गिथब में निहित है। परियोजना को समान डिजाइन नियमों के अनुसार तैयार किया गया है। शैली, प्रौद्योगिकी और उपकरणों पर कोई प्रतिबंध नहीं है। जब आपके पास ओपन सोर्स कोड और स्पष्ट डिज़ाइन नियम होते हैं, तो स्टैक पर कोई भी डेवलपर योगदान दे सकता है। आपको कोड में कॉपी करने के लिए, आपको डॉक पढ़ने, रिपॉजिटरी को क्लोन करने, एक संपादन करने, एक पुल अनुरोध भेजने की आवश्यकता है।
वर्तमान में, ब्राजील, रूस और फ्रांस इस सक्रिय आधार का बहुत सक्रिय रूप से उपयोग कर रहे हैं।
अब हम ठेकेदारों के पूरे कोड को स्थानांतरित करने की कोशिश कर रहे हैं (और हमारे पास बहुत से अलग-अलग दिशाओं में इनरसोर्स) हैं। विश्लेषण में, हमने दो अक्षों पर एक नक्शा बनाया: एक अक्ष पर आंतरिक सर्कल के मोड में स्थानांतरण की तकनीकी जटिलता और दूसरे अक्ष पर, आंतरिक सर्कल में स्थानांतरण कितना आम तौर पर उपयोगी है। यदि कोड अद्वितीय है और केवल एक ही स्थान पर आवश्यक है - तो शायद आपको इसे छूना भी नहीं है। लेकिन अगर कई टीमें इस साइट का उपयोग करती हैं - तो यह निश्चित रूप से आवश्यक है।
यह सब आम तौर पर विकास संस्कृति को बढ़ाता है। और यह कई टीमों की गति को तेज करता है, क्योंकि आप किसी भी विशेषता के लिए मर्ज अनुरोध लिख सकते हैं। यह मालिक टीम द्वारा विनियोजित किया जाएगा, और जो योगदानकर्ता है, उसके द्वारा परीक्षण किया जाएगा। महत्वपूर्ण स्थितियों में से एक भंडार में किसी भी कोड के ऑटोटेस्ट और विवरण की उपलब्धता है।
कुछ और बारीकियाँ
जब उन्होंने शुरुआत की तो वहां कुछ भी नहीं था। डेवलपर्स के साथ समानांतर में, उन्होंने देवोप्स की भर्ती की। अब devobservices या तो एक सेवा के रूप में प्रदान की जाती है (जिनके लिए इसकी आवश्यकता होती है), या उत्पाद टीम की अपनी ऑप्स हैं, जो पहले से ही निर्धारित करता है कि क्या और कैसे।
असेंबली जेनकिंस में की जाती है, कोड सोनार में चलाया जाता है (अधिक सटीक, पहले से ही सोनारक्यूब)। सोनार विफल - कोई रिलीज़ नहीं परीक्षक ऑटोटेस्ट्स, कोड मालिकों - कार्यात्मक परीक्षण लिखते हैं। डेटाबेस को इंफ्रास्ट्रक्चर इंजीनियरों द्वारा सेवा के रूप में दिया जाता है। पूर्ण लोड परीक्षण दुर्लभ मामलों में किया जाता है, क्योंकि परीक्षण आधार की संरचना और मुख्य एक अलग हैं: प्रप्रोड पर हमारे पास यादृच्छिक डेटा है, और वास्तविक डेटा नहीं अनाम है (यह भविष्य में चरणों में से एक है), इसलिए आपको धीरे से और सभी को एक बार में रोल करने की आवश्यकता नहीं है।
जल्द ही हमें कुबेरनेट्स (और
बाजार में कुछ नए उत्पाद पहले
से ही शुरू में हैं) पर जाना चाहिए, जैसे ही हम संक्रमण योजना का पता लगाते हैं और बुनियादी ढांचे के सभी विवरणों पर सहमत होते हैं।
मेरे सहकर्मी और मैं इस बारे में बात करना जारी रखेंगे कि काम का क्या हिस्सा व्यवस्थित किया जाता है, क्योंकि लगभग हर जगह आप असीम रूप से जा सकते हैं। ठीक है, आप हमारे रियलिटी शो का अनुसरण कर सकते हैं (क्योंकि सब कुछ सिर्फ बनाया जा रहा है और तेजी से बदल रहा है) और शर्त लगाएं कि हम इसे पेंच करते हैं या नहीं।