CQRS और इवेंट सोर्सिंग का उपयोग करके वेयरहाउस प्रबंधन प्रणाली। विकास की प्रक्रिया

यह लेख यहाँ पहले प्रकाशित कई लेखों की एक निरंतरता है और चरणों के लिए समर्पित है:

1. आवश्यकताओं का विवरण
2. डिज़ाइन
3. क्रियान्वयन। सेवा परत

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

विकास की प्रक्रिया

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



नतीजतन, 80 से अधिक ऐसे लोग थे, जिन्होंने कम से कम एक अनुरोध पूल बनाया था, और कुल मिलाकर उन्होंने 800 से अधिक अनुरोध पूल रखे।



हैकाथॉन की घटनाओं में विकास को आमने-सामने आयोजित किया गया था, जिसे आमतौर पर मैगनेटो दुनिया में "योगदान दिवस" ​​कहा जाता है, और वितरित किया जाता है जब लोग परियोजना पर दूर से काम करने के लिए एक सुविधाजनक समय पर काम करते हैं जो परिणाम दिखाने और सवाल पूछने के लिए परियोजना पर डेमो खोलने के लिए आते हैं।



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

उदाहरण के लिए, आधिकारिक रिलीज से 2 सप्ताह पहले, Strix, जिसने MSI परियोजना के लिए कोड योगदान में सक्रिय रूप से भाग लिया था, ने पहले ही Magento 2.3 + MSI बीटा पर आधारित अपनी परियोजना शुरू की थी, जिसे उसके ब्लॉग पर साझा किया गया था।

और अगर 2017 में ऐसी 15 घटनाएं हुईं, तो 2018 में 40 से अधिक थे।



और सबसे कई घटनाओं ने एक स्थान पर 100+ योगदानकर्ताओं को इकट्ठा किया, जैसे कि # MageConf18 सम्मेलन से पहले कीव में हाल ही में योगदान दिवस या बार्सिलोना में Magento लाइव यूरोपीय संघ योगदान दिवस:



डेवलपर्स के साथ त्वरित संचार के लिए, हमने संचार के लिए एक अलग स्लैक चैनल आवंटित किया है, जिसमें अब 350 से अधिक डेवलपर्स हैं।



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

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



प्रत्येक शुक्रवार, योगदानकर्ताओं ने परियोजना के लिए अनुरोधों का एक पूल बनाया, साथ ही साथ जिनके पास कुछ सुधार करने के बारे में प्रश्न / सुझाव हैं, एक खुली डेमो रैली में अपने परिणाम प्रदर्शित करते हैं, जिससे कोई भी ज़ूम के माध्यम से जुड़ सकता है:



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




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


ज़ेनहब के साथ निर्मित माइलस्टोन 2 कार्यान्वयन के एक ग्राफ को जला दें ।

परियोजना प्रबंधन के सिद्धांत में, वे आमतौर पर फिक्स्ड रिसोर्स कंडीशन की उपस्थिति में दो संकेतकों में से एक को फिक्स्ड स्कोप या फिक्स्ड डिलीवरी टाइम को ठीक करने का प्रयास करते हैं।

मॉडल के मामले में, जब केवल समुदाय के डेवलपर्स भाग लेते हैं, हमारे पास निश्चित संसाधन नहीं होते हैं और डिलीवरी के समय को ठीक करने के कोई भी प्रयास बहुत मुश्किल थे।

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

और सबसे महत्वपूर्ण बात - हमें मुख्य उत्पाद की रिलीज की तारीख से छुटकारा मिल गया - मैगेंटो 2 और अब हम इसे स्वतंत्र रूप से जारी कर सकते हैं! हमने संगीतकार मेटा पैकेज को एकल क्यों किया, जो सभी इन्वेंट्री मॉड्यूल को संदर्भित करता है और मुख्य रिपॉजिटरी (मुख्य रूप से रिपॉजिटरी के मेटापैकेज से) से मेटाैपेज का लिंक इस तरह दिखता है ...

"magento/inventory-composer-metapackage": "^1.0.3" 

यानी ^ पैकेज संस्करण को इंगित करने के लिए वर्ण का उपयोग किया जाता है।
इसी तरह, पैकेज के अंदर परियोजना मॉड्यूल के सभी संस्करणों के लिंक ^ प्रतीक के अतिरिक्त के साथ इंगित किए जाते हैं:

 { "name": "magento/inventory-composer-metapackage", "version": "1.0.3", "description": "Metapackage with Magento Inventory modules for simple installation", "type": "metapackage", "require": { "magento/inventory-composer-installer": "^1.0.3", "magento/module-inventory": "^1.0.3", "magento/module-inventory-admin-ui": "^1.0.3", "magento/module-inventory-api": "^1.0.3", "magento/module-inventory-bundle-product": "^1.0.3", "magento/module-inventory-bundle-product-admin-ui": "^1.0.3", "magento/module-inventory-cache": "^1.0.3", "magento/module-inventory-configurable-product": "^1.0.3", "magento/module-inventory-catalog-api": "^1.0.3", "magento/module-inventory-catalog": "^1.0.3", "magento/module-inventory-catalog-admin-ui": "^1.0.3", "magento/module-inventory-catalog-search": "^1.0.3", "magento/module-inventory-configurable-product-admin-ui": "^1.0.3", "magento/module-inventory-configurable-product-indexer": "^1.0.3", "magento/module-inventory-configuration": "^1.0.3", "magento/module-inventory-configuration-api": "^1.0.3", "magento/module-inventory-grouped-product": "^1.0.3", "magento/module-inventory-grouped-product-admin-ui": "^1.0.3", "magento/module-inventory-grouped-product-indexer": "^1.0.3", "magento/module-inventory-import-export": "^1.0.3", "magento/module-inventory-indexer": "^1.0.3", "magento/module-inventory-multi-dimensional-indexer-api": "^1.0.3", "magento/module-inventory-low-quantity-notification": "^1.0.3", "magento/module-inventory-low-quantity-notification-api": "^1.0.3", "magento/module-inventory-low-quantity-notification-admin-ui": "^1.0.3", "magento/module-inventory-product-alert": "^1.0.3", "magento/module-inventory-reservations": "^1.0.3", "magento/module-inventory-reservations-api": "^1.0.3", "magento/module-inventory-sales": "^1.0.3", "magento/module-inventory-sales-admin-ui": "^1.0.3", "magento/module-inventory-sales-api": "^1.0.3", "magento/module-inventory-sales-frontend-ui": "^1.0.3", "magento/module-inventory-shipping": "^1.0.3", "magento/module-inventory-shipping-admin-ui": "^1.0.3", "magento/module-inventory-source-deduction-api": "^1.0.3", "magento/module-inventory-source-selection-api": "^1.0.3", "magento/module-inventory-source-selection": "^1.0.3" } } 

^ ऑपरेटर कोड लिखते समय अधिकतम अनुकूलता के लिए मौजूद है, इसलिए हम आंतरिक MSI रिलीज़ तब तक कर सकते हैं जब तक कि हम प्रोजेक्ट " > = 1.0.3 <2.0.0 " में पिछड़े असंगत परिवर्तन न करें।
एक ओर, यह MSI जैसी परियोजनाओं के लिए पर्याप्त लचीलापन देता है, जिन्हें आमतौर पर Magento Core बंडल एक्सटेंशन (CBE) कहा जाता है। इस तरह की परियोजनाएं अलग-अलग GitHub रिपॉजिटरी में स्थित हैं, रिलीज की अपनी कालक्रम है, और अन्य समान परियोजनाओं और मुख्य Magento 2 उत्पाद से संभव के रूप में अलग-थलग हैं। अलगाव के संदर्भ में, प्रक्रियात्मक रूप से, यह मार्ग के नियम का पालन ​​करने जैसा है। और विश्व स्तर पर, मैगेंटो 2 के भीतर नई सेवाओं और परियोजनाओं के लिए यह विकास दृष्टिकोण मैगेंटो वास्तुकला परिषद द्वारा प्रस्तुत सेवा अलगाव अवधारणा से मेल खाता है। लेकिन अधिक लचीलेपन के साथ अधिक जिम्मेदारी आती है ( एक महान शक्ति के साथ एक बड़ी जिम्मेदारी आती है ), क्योंकि इस मामले में, ऐसी परियोजनाओं को पिछड़े असंगत परिवर्तनों को रोकने और उपयोगकर्ताओं के लिए उन्नयन में आसानी सुनिश्चित करने के लिए सिमेंटिक वर्जनिंग ( सेमीवीयर ) का सख्ती से पालन करना चाहिए।

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

उदाहरण के लिए, यह बैकलॉग माइलस्टोन 3 है, जिस पर हम अभी काम शुरू कर रहे हैं:



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