व्यंजनों टीमसिटी। रिपोर्ट Yandex.Taxi

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


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





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

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

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



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

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

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

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



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

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

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



TeamCity में, आप इस संस्करण के लिए प्रत्येक परियोजना शुरू कर सकते हैं और इसे काफी लचीले ढंग से कॉन्फ़िगर कर सकते हैं।



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



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



आप एक जटिल जटिल पदानुक्रमित प्रणाली स्थापित कर सकते हैं, जो हमारी टीम अंततः आई। हमारे पास एक सामान्य बड़ी जड़ और कुछ छोटी जड़ें हैं। बैकएंड, मोबाइल डेवलपमेंट, फ्रंटेंड, Yandex.Food - ये सभी अपने-अपने अलग भंडार में रहते हैं। इसी समय, इन सभी परियोजनाओं के बारे में जानकारी एक बड़े साझा भंडार में संग्रहीत की जाती है - जड़ में।

जब आप अंत में इस संस्करण को जोड़ते हैं, तो इसे अपने सभी सहयोगियों के साथ स्थापित करें, जहां कौन और कैसे जीवित रहेगा, जो समर्थन में लगे रहेंगे - इस सब के बाद, आपको एक कठिन विकल्प बनाना होगा।



TeamCity कॉन्फिग के केवल दो फॉर्मेट को सपोर्ट करता है। XML के साथ, मुझे संदेह है कि कोई भी काम नहीं करना चाहेगा, इसलिए हमने दूसरा प्रारूप चुना। यह आपको कोटलिन स्क्रिप्ट पर इन कॉन्फिग को बनाने की अनुमति देता है।



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



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



ये दो लाइनें पूरी परियोजना का निर्माण करती हैं। यह टीमसिटी एपीआई की बोली है। एपीआई हर प्रमुख संस्करण को बदलता है। 2018-2, 2018-1, 2017 इत्यादि हैं। जल्द ही, उम्मीद है कि 2019 जारी किया जाएगा।

दूसरी पंक्ति बस परियोजना की घोषणा करती है।



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

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



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



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



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

सबसे दिलचस्प रोमांच यहां से शुरू होते हैं: हम कुछ चीजों को कैसे लागू करते हैं और कैसे, सिद्धांत रूप में, टीमसिटी के साथ प्रोजेक्ट की बातचीत को आसान बनाते हैं?

यहां एक फॉर्म या किसी अन्य में मौजूद हर कोई प्रकाशन में, अपनी विधानसभा में भाग लेने के लिए, एक रिलीज की तैयारी कर रहा है। हम Google Play पर विभिन्न चैनलों पर अपनी रिलीज़ प्रकाशित करते हैं।





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



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



कोड में, यह इस तरह दिखता है। कम से कम अब तक, आधे साल के लिए, कोई भी अभी तक नहीं आया है और पूछा है - मैं कोई विशेषता कैसे बनाऊं? अधिकांश बार कोड से यह सब सहज रूप से स्पष्ट है।



उसी समय, कुछ चीजें काफी सरलता से की जाती हैं, लेकिन इंटरफ़ेस की कई परतों के पीछे छिपी होती हैं। हमें चलना है, आगे पीछे जाना है।



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

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



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



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

यह वही है जो इंटरफ़ेस में चेन असेंबली जैसा दिखता है।



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

उसी भावना के आसपास, अन्य सभी चीजें की जा रही हैं। और TeamCity में पूरी परियोजना कोड की शाब्दिक 500 लाइनें लेती है।



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



TeamCity में एक तथाकथित-स्पष्ट और पूरी तरह से गैर-प्रलेखित पैरामीटर है - Rev.dep (रिवर्स डिपेंडेंसी)। यह उन सभी मापदंडों को फेंकता है जो तारांकित के बाद सभी नेस्टेड बिल्ड में आते हैं।


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