पूल अनुरोध से जारी करने के लिए। रिपोर्ट Yandex.Taxi

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


- शुभ संध्या! मेरा नाम सर्गेई है, मैं Yandex.Taxi में स्वचालन समूह का प्रमुख हूं। संक्षेप में, हमारे समूह का मुख्य कार्य डेवलपर्स को उनकी समस्याओं को हल करने में लगने वाले समय को कम करना है। इसमें सीआई से लेकर विकास और परीक्षण प्रक्रियाओं तक सब कुछ शामिल है।

कोड लिखे जाने पर हमारा विकास क्या करता है?

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



हमारा परीक्षण कवरेज उतना अच्छा नहीं है जितना हम चाहेंगे, लेकिन हम इसे पर्याप्त स्तर पर बनाए रखने की कोशिश करते हैं।

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

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

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

स्वाभाविक रूप से, हम केवल हमारी सेवाओं और केवल हमारे घटकों का परीक्षण करते हैं, क्योंकि हमें बाहरी सेवाओं का परीक्षण नहीं करना चाहिए, और हम सब कुछ बाहरी गीला करते हैं।

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

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

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

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

आपके द्वारा कोड बनाए जाने के बाद, स्थानीय रूप से जाँच की गई, आप एक पूल अनुरोध कर सकते हैं। पूल अनुरोध GitHub पर बनाए गए हैं।



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

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

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

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



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

हम इस प्रक्रिया में क्या ध्यान देते हैं:



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

हमारा यह भी नियम है कि जब नई कार्यक्षमता को रोल आउट किया जाना चाहिए, और सभी समूहों और सभी डेटा केंद्रों को रोल आउट करने के बाद ही इसे चालू किया जाएगा।

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

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

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



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



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

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

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

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

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

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

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

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

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

इसके अलावा, जब आपका कोड लिखा जाता है, तो समीक्षा पूरी हो जाती है, आप इसे फ्रीज करने के लिए तैयार हैं, लेकिन अक्सर ऐसा होता है कि आपको अतिरिक्त कार्यों को पूरा करने की आवश्यकता होती है, डेटाबेस पर जाएं।



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



जब कोड लिखा जाता है, समीक्षा की जाती है, परीक्षण किया जाता है, तो सभी माइग्रेशन किए जाते हैं, आप इसे सुरक्षित रूप से GitHub में विलय कर सकते हैं और इसे जारी कर सकते हैं।

कुछ सेवाओं के लिए, हमारे पास एक नियमन है जिसके अनुसार हमें एक निश्चित समय में रोल आउट करना होगा, लेकिन सेवाओं का एक महत्वपूर्ण हिस्सा जिसे हम किसी भी समय रोल आउट कर सकते हैं।

यह सब TeamCity के साथ किया जाता है।



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

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

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



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

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

रोलआउट हो गया, सब ठीक है। और अगर कुछ गलत हो गया, अगर अचानक समस्या?



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



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