विचार से विमोचन तक। विस्तृत मार्केट फ्रंटेंड अनुभव

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

मेरा नाम अलेक्जेंडर है, मैं Yandex.Market में इंटरफ़ेस विकास समूहों में से एक का नेतृत्व करता हूं। आज मैं Habr के पाठकों को इन समस्याओं को हल करने के हमारे अनुभव के बारे में बताऊंगा। हम उत्पादन में सुविधाओं को वितरित करने का एक उदाहरण मानते हैं।

टीम

Yandex.Market माल का चयन करने और कीमतों की तुलना करने के लिए रूस का सबसे बड़ा संसाधन है। हर दिन, 3.5 मिलियन लोग इसका उपयोग करते हैं - वे यहां अपनी भविष्य की खरीद की योजना बनाते हैं, उत्पादों पर चर्चा करते हैं और अन्य लोगों को सही विकल्प बनाने में मदद करते हैं।

अब Yandex.Market 40 फ्रंट-एंड डेवलपर्स को नियुक्त करता है, और उनकी संख्या बढ़ रही है। हां, 40 लोग - यह केवल बाजार का मोर्चा है, और हमारे अन्य दो परियोजनाओं के मोर्चों पर भी हैं - बेरू और ब्रेंटली के बाज़ार। 2005 में, बाजार में केवल 5 डेवलपर्स थे, कल्पना करें?

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

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

विचारों

सर्किट का कोई भी सदस्य एक विचार दे सकता है। हम सभी विकल्पों का स्वागत करते हैं, यहां तक ​​कि तुच्छ या बिल्कुल पागल। आमतौर पर लोग आम सभाओं में विचार उत्पन्न करते हैं - यह पूरी टीम को काम करने के लिए चार्ज करता है।

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

जिन विचारों ने सबसे अधिक अंक प्राप्त किए हैं, वे ग्राहक और कलाकारों के साथ परियोजनाओं में बदल जाते हैं। ट्रैकर में डिजाइन कार्यों का एक जबरदस्त सेट दिखाई देता है। टीम लीडर द्वारा स्प्रिंट के लिए कार्य वितरित किए जाते हैं और टीम में प्रवेश किया जाता है।

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

प्रक्रिया

मान लीजिए कि हमने अपने हितों को ध्यान में रखते हुए, उपयोगकर्ता के लिए सामान का एक हिंडोला विकसित करने का फैसला किया।

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



यह सामने के छोर पर काम करने और उपयोगकर्ता को हमारे हिंडोला देने के लिए रहता है।

मार्केट का फ्रंटेंड एक वेब क्लाइंट और स्टेटलेस NodeJS सर्वर है, जिसके पीछे दर्जनों अन्य बैकएंड हैं: सर्च, एडवाइजरी सर्विसेज, एनालिटिक्स, यूजीसी कंटेंट और बहुत कुछ। फ्रंटेंड कई डीसी में यैंडेक्स बादलों में रहता है। NodeJS एप्लिकेशन को कंटेनरों में निष्पादित किया जाता है, और इसकी स्टेटलेस प्रकृति के कारण इसे क्षैतिज रूप से बढ़ाया जा सकता है जैसा कि हमें चाहिए:



मार्केट फ्रंट-एंड डेवलपर्स NodeJS पर सर्वर साइड और रिएक्ट + रिडक्स पर क्लाइंट दोनों विकसित कर रहे हैं। एक भाषा और एक पारिस्थितिकी तंत्र में विकसित करना बहुत प्रभावी है। यदि आप अभी भी सर्वर और क्लाइंट के बीच अपनी प्रौद्योगिकी स्टैक को एकीकृत करने के बारे में सोच रहे हैं, तो कोशिश करें - यह समझ में आता है।

हिंडोला को अंतिम रूप देने के लिए, हमें सर्वर पर माल प्राप्त करने और क्लाइंट भाग को लागू करने के लिए कोड जोड़ना होगा। आप हिंडोला को आलसी बना सकते हैं - स्क्रीन पर दिखाई देने से पहले इसे लोड करें। ऐसा करने के लिए, आपको क्लाइंट API में समापन बिंदु को अतिरिक्त रूप से लागू करना होगा।

जब यह किया जाता है, तो डेवलपर एक पूल अनुरोध बनाता है और कोड समीक्षा के लिए अपना कोड भेजता है। हमारी कोड समीक्षा एक आवश्यक है। ताकि यह लटका न हो, हमारे पास इसके कार्यान्वयन के लिए अनुशंसित SLA भी है। आप इस बारे में पढ़ सकते हैं कि हमने यहां कोड समीक्षा कैसे तेज की।

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

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



यदि सभी चेक सामान्य रूप से पास हो गए हैं, तो टिकट स्वचालित रूप से "आप चेक कर सकते हैं" स्थिति में स्थानांतरित हो जाते हैं, और कार्य क्यूए टीम के डैशबोर्ड पर दिखाई देता है।

QA इंजीनियर के टास्क टिकट पर आने के बाद और सुनिश्चित किया गया कि नई कार्यक्षमता आगे की यात्रा के लिए तैयार है, टिकट को रिलीज़ टैग के साथ चिह्नित किया गया है। अगली रिलीज में इस टैग के साथ सभी टिकट शामिल होंगे।

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

इसलिए, अनुशंसित उत्पादों का हमारा मीरा-गो-राउंड जारी करने के लिए जाता है। यह कैसा चल रहा है?

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



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

इस तरह से रिलीज पाइपलाइन दिखता है (क्लिक करने योग्य):



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

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

रिहाई के बाद बाजार के स्वास्थ्य की निगरानी ऑन-ड्यूटी QA द्वारा भी की जाती है। उनके पास अपने निपटान में बड़ी संख्या में ग्राफ हैं - हम ग्राफिट और ग्राफाना का उपयोग करते हैं। रेखांकन में सब कुछ है: सामान्य 500-के बैकग्राउंड से लेकर नोड्स एप्लिकेशन की त्रुटियों के लिए जब डीसी द्वारा टूटे गए विभिन्न बैकेंड के साथ संचार किया जाता है। हम लोगों का एक अलग समूह भी है - मार्केट हेल्थ ग्रुप। वह मार्केट मेट्रिक्स 24/7 पर नज़र रखती है।

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

इस समय, हमारे उपयोगकर्ता पहले से ही उनके लिए चुने गए उत्पादों को देखते हैं, और सर्किट एक नए विचार पर काम कर रहे हैं।

यहाँ सेवा पर हमारे हिंडोला है:

एक निष्कर्ष के बजाय

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

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

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