विभिन्न टीमों द्वारा आम घटक। यैंडेक्स रिपोर्ट

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



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





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



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



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



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

एक ही समय में, हम, जहां तक ​​हमारे पास पर्याप्त शक्ति है, इसे उपयोगकर्ताओं के लिए नीरस, समान बनाने का प्रयास करें।



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

क्या यह लायक है, स्लाइड्स पर इस तरह से स्विच करना, यह सुनिश्चित करने के लिए कि पिक्सेल पर कहीं भी कुछ भी नहीं गया है? हम ऐसा होने से रोकने की कोशिश करते हैं।



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

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



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



यदि आप आगे देखते हैं, तो यहां दस्तावेज़ जारी करना सामान्य है। लेकिन यहां भी, बिल्कुल वही स्निपेट है।



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



या, मान लें, नोटिफ़ायर में वीडियो स्निपेट है, जो पोर्टल के विभिन्न पृष्ठों पर है।



या यहां एक वीडियो स्निपेट है जब आप इसे अपने पसंदीदा में जोड़ते हैं, और फिर इसे अपने संग्रह में देखते हैं।



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

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

अब कल्पना कीजिए। मान लीजिए कि हमें कुछ मिला है जो अच्छी तरह से काम करता है। हर जगह, हर जगह उन्होंने इसे लागू किया, और फिर उन्होंने एक नया प्रयोग किया और महसूस किया कि क्या सुधार किया जा सकता है। और फिर, हमें इस पूरी कार्यान्वयन श्रृंखला को दोहराना होगा। बहुत ज़्यादा।



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

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

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



हमने समय से पहले शुरू किया, एसवीएन में वापस, और यह दीपक की तरह और सुविधाजनक था: HTML के साथ एक डैडी, जैसे बूटस्ट्रैप में। आप इसे खुद से कॉपी करें। शैलियों के साथ डैडी के बगल में, कुछ प्रकार के जेएस, जो तब जानते थे कि कैसे बस कुछ दिखाना / छिपाना है। और वह सब है।



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

फिर हम आम कार्यप्रणाली का समर्थन करने में सक्षम होने के लिए पूरी कार्यप्रणाली के साथ आए।



कंपनी के अंदर के पुस्तकालय ने खुद की वेबसाइट को एक खोज और किसी भी वर्गीकरण के साथ हासिल कर लिया है।



भंडार अब इस तरह दिखता है। आप देखते हैं, लगभग 10 हजार कमिट और 100 से अधिक योगदानकर्ता भी हैं।



लेकिन यह नए पुनर्जन्म में बहुत ही बी-हाउस का फ़ोल्डर है। अब वह ऐसी दिखती है। आधी स्क्रीन के अंदर आपके अपने फोल्डर पहले से ही मौजूद हैं।



और इसलिए आज साइट दिखती है।



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



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

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

दूसरी बड़ी समस्या, वास्तव में, इन शांत नए घटकों के बारे में जानकारी का प्रसार है। सिर्फ इसलिए कि बहुत सारे डेवलपर हैं, वे अपने दैनिक कार्यों में व्यस्त हैं। और उनके पास बैठने और अध्ययन करने का अवसर है कि वहां सामान्य क्षेत्र में क्या हो रहा है, कोई फर्क नहीं पड़ता कि इसका क्या मतलब है, वास्तव में, या तो।

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



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



अब उनमें से कई हैं। हैरानी की बात है कि, वहाँ कार्य बिल्कुल समान हैं: विकास की प्रक्रिया को गति देने के लिए, स्थिरता की समस्या को हल करने के लिए, पहिया को सुदृढ़ करने के लिए नहीं और किए गए कार्यों की नकल न करें।



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

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

हमें इस संस्करण को npm में प्रकाशित करने की आवश्यकता है, और फिर कुछ परियोजना के भंडार पर जाएं जहां पुस्तकालय का उपयोग किया जाता है और इस संस्करण को लागू करता है। सबसे अधिक संभावना है, यह package.json में कुछ संख्या को ठीक करेगा, विधानसभा को पुनरारंभ करें। शायद पैकेज-लॉक को भी पुनर्जीवित करें, एक पुल अनुरोध बनाएं, देखें कि परीक्षण कैसे पास होते हैं। और हम क्या देखेंगे?



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

और यह तब भी अच्छा है जब हम इसे एक सेवा में लागू करते हैं, और वहीं पर सब कुछ तुरंत टूट गया। यह बहुत दुखद था जब हमने यह सब किया, इसे दस अलग-अलग सेवाओं में लागू किया। वहां कुछ भी नहीं टूटा। हम पहले से ही एक स्मूदी काढ़ा, या जो कुछ भी आवश्यक हो गया है। इस समय, संस्करण को 11 वीं परियोजना में, या 25 वें में पेश किया जा रहा है। और एक बग है। हम पूरी श्रृंखला के साथ लौटते हैं, एक पैच बनाते हैं और इसे पिछली सभी 20 सेवाओं में लागू करते हैं। इसके अलावा, यह पैच पिछले वाले में से एक में फट सकता है। अच्छी तरह से और इतने पर। मजा आ गया।

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

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

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



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

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



व्यवहार में यह कैसा दिखता है? यहां फिक्स के साथ एक पुल अनुरोध है। यहां आप देख सकते हैं कि स्वचालन ने आवश्यक समीक्षकों को यह जांचने के लिए बुलाया कि कोड में सब कुछ ठीक है। वास्तव में, समीक्षक आए और सहमत हुए कि सब कुछ ठीक था। और इस समय, डेवलपर केवल पुल अनुरोध में एक विशेष / कैनरी कमांड लिखता है।

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

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

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



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

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

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

- , CDN, . . , , , , . , , , changelog - .

, , , , . , , .

, . . , , : , ? . , . . , .