विकास की प्रक्रिया और बेथ में रोलिंग जारी करता है। स्वचालित परीक्षण। विकास का वातावरण

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

उन्होंने किस बारे में बात की:
विकसित करने और रोलिंग आउट की प्रक्रिया बेत में जारी होती है। प्रयुक्त उपकरण।

• जीआईटी वर्कफ़्लो। एक अलग शाखा में प्रत्येक कार्य;
• JIRA, TeamCity और AIDA का उपयोग करना;
• रिलीज का गठन और प्रति दिन दो रिलीज को रोल आउट करना। समस्याएं और उनके समाधान (रोलबैक, पैच, आदि)।

स्वचालित परीक्षण। बड़ी संख्या में परीक्षणों की त्वरित दौड़ के लिए नुस्खा।

• हम जो उपयोग करते हैं;
• परीक्षण कैसे चलाएं;
• कोड कवरेज
• स्टार्टर। 3.5 मिनट में 18,000 परीक्षण।

एक जटिल वितरित प्रणाली को विकसित करने वाली टीम में विकास का माहौल
और लोगों से सिफारिशें: उपयोगी किताबें, लेख, आदि।


एंटोन सर्गेयेव: सभी को नमस्कार, आप आईटी कम्पोट पॉडकास्ट के 48 वें संस्करण को सुन रहे हैं, और आपको एंटोन टोपीलोव द्वारा होस्ट किया गया है।

एंटोन कोप्पलोव: और एंटोन सर्गेयेव, हैलो।

एंटोन सर्गेव: आज, हमारे मेहमान बहादुर लोग हैं - सगाई रिलीज़ इंजीनियर ओलेग ओयामे और व्लादिस्लाव चेर्नोव। हाय दोस्तों!

व्लादिस्लाव चेरनोव: नमस्कार।

ओलेग ओयामे: नमस्कार।

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

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

एंटोन सर्गेव: मैं देख रहा हूँ, अच्छा। और ओलेग आपका सहयोगी है और इस के साथ आपकी मदद करता है, है ना?

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

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

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

एंटोन सर्गेव: अब कुछ श्रोता शायद "उबलते पानी में लिखना" शुरू कर रहे हैं: यह कैसा है, तोड़फोड़! लेकिन, जहां तक ​​मुझे पता है, एसवीएन, यह किसी भी उद्यम जैसी परियोजनाओं के लिए अधिक अजीब है। आपको माम्बा के बाद से उनके साथ काम करने का बहुत अनुभव था, यानी यह ऐतिहासिक रूप से सही है?

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

एंटोन कोप्पीलोव: क्या आपने मर्क्यूरियल को गिट के विकल्प के रूप में नहीं माना है?

व्लादिस्लाव चेरनोव: जहां तक ​​मुझे पता है, हमने मर्क्यूरियल के विकल्प पर विचार नहीं किया, क्योंकि उस समय प्लग-इन की संख्या, रिपॉजिटरी के प्रबंधन के लिए सॉफ्टवेयर, और इसी तरह गिट पर अधिक था। इसके अलावा, समुदाय उस समय पहले से ही बना हुआ था, लेकिन मर्क्यूरियल पर यह अभी शुरुआत कर रहा था। मेरे लिए, उदाहरण के लिए, एक विशेष प्लस यह है कि Git किसी भी भाषा का उपयोग करता है, लेकिन Mercurial के साथ यह अधिक जटिल है। (परीक्षण निदेशक इल्या आयु से नोट: हमने कई साल पहले Mercurial को पेश करने की कोशिश की थी, लेकिन यह हमारे लिए मूल नहीं था और हम वापस लौट आए। SVN)।

एंटोन कोप्पलोव: हाँ, अच्छा है।

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

एंटोन कोप्पलोव: और बाहर बिछाने और परीक्षण की प्रक्रिया, क्या आपने इसे एक साथ रखा था या ये अलग-अलग प्रक्रियाएं थीं?

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

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

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

एंटोन सर्गेव: यदि आप अब फिर से सगाई करने वाले थे, तो आप तुरंत इस तरह की व्यवस्था कर लेंगे और बहुत पहले प्रतिबद्ध निरंतर एकीकरण के माध्यम से चले गए और सभी परीक्षणों को पारित कर दिया?

ओलेग ओयामे: ठीक है, मैं - हाँ।

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

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

व्लादिस्लाव चेरनोव: मुझे पहले कहानी पर थोड़ा पीछे जाना चाहिए: 2 एक दिन में रिलीज होती है - यह वास्तव में है, हम एक दिन में लगभग 50-60 कार्य छोड़ रहे हैं। सभी को शायद यह जानने में दिलचस्पी होगी कि वास्तव में 2 रिलीज़ क्यों होते हैं। सब कुछ बहुत सरल है। यह स्पष्ट है कि पहले प्रति सप्ताह एक रिलीज़ या कुछ दिनों में एक रिलीज़ होती थी, फिर हर दिन एक रिलीज़ होती थी, और फिर प्रति दिन दो रिलीज़ होती थीं। दो क्यों?
कुछ बिंदु पर, हमने प्रवाह में स्विच किया, जहां प्रत्येक कार्य एक अलग शाखा में किया जाता है, और, तदनुसार, जब हम एक रिलीज़ बनाते हैं, तो हम इन कार्यों को रिलीज़ शाखा में विलय कर देते हैं, प्रत्येक कार्यों की फिर से जाँच करते हैं, और साथ ही हम कोड ज़बरदस्ती (एकीकरण परीक्षण) की जांच करते हैं । जब यह अधिकतम 10 से 30-40 कार्य है - यह करना काफी आसान है। जब आपको इस रिलीज में 100 कार्यों को रेक करने की आवश्यकता होती है, तो यह करना पहले से ही अधिक कठिन होता है। और इसलिए हम दिन में दो बार तैनात करते हैं, हम अधिक बार तैनात कर सकते हैं, लेकिन इसका कोई मतलब नहीं है। एक अलग शाखा में प्रत्येक कार्य संभवतः स्पष्ट क्यों है। हमारे पास परीक्षण के कई चरण हैं, उनमें से लगभग 5 हैं प्रत्येक कार्य एक अलग शाखा में है, क्योंकि हम इसे वापस रोल कर सकते हैं और इसकी जांच कर सकते हैं। यह पता चला है कि हमारे पास उत्पादन और इस कार्य के साथ कोड है। और हम परीक्षण के कई चरणों में इसका परीक्षण करते हैं। पहला चरण मानक है - यह एक कोड समीक्षा है, और केवल यह कार्य दिखता है। किए गए कार्य को विकास पर्यावरण पर जांचा जाता है। वर्चुअल मशीनों के साथ डेटाबेस, और इसी तरह विकास पर्यावरण हमारा मिनी-सर्वर वातावरण है। इस पर आप उन चीजों की जाँच कर सकते हैं जिन्हें उत्पादन में सत्यापित नहीं किया जा सकता है। वहां कार्यों का परीक्षण किया जाता है, फिर हम प्रत्येक कार्य के लिए मिनी-स्टेजिंग बनाते हैं, इसे शॉट कहा जाता है, उत्पादन से आधार का उपयोग किया जाता है, और हम कार्य को फिर से जांचते हैं। फिर कार्य रिलीज़ के लिए छोड़ देता है और रिलीज़ शाखा में कोड आकस्मिकता के लिए जाँच की जाती है, क्या यह अन्य कार्यों को तोड़ता है। वगैरह वगैरह। वहां चौथी बार टास्क चेक किया जाता है। और पोस्ट-प्रोडक्शन के लिए वैकल्पिक परीक्षण हैं, जब हम उत्पाद प्रबंधक से कुछ अनुरोध के लिए इस कार्य का परीक्षण करते हैं, या यह एक बहुत ही महत्वपूर्ण कार्य है और परीक्षक इसे उत्पादन के लिए फिर से परीक्षण करते हैं, लेकिन ये वैकल्पिक चीजें हैं।

एंटोन सर्गेव: आपकी कोड समीक्षा कैसे चल रही है? क्या कुछ विशेष लोग इसे कर रहे हैं, या डेवलपर्स अन्य डेवलपर्स से कोड की अनियमित समीक्षा करते हैं?

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

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

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

एंटोन सर्गेव: आप क्या कर रहे हैं? और अगर आप इसे रोल आउट नहीं करते हैं तो आप इसे कैसे वापस लाएंगे? किस अवधि के लिए आप वापस रोल कर सकते हैं, अगर वह?

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

एंटोन सर्गेव: यह GitHub पर कहीं है? क्या आम लोग इसे महसूस कर सकते हैं?

व्लादिस्लाव चेरनोव: नहीं, वह नहीं है, और क्यों - यह शायद यूरी नसेरेतिनोव के लिए एक सवाल है।

एंटोन सर्गेव: स्पष्ट रूप से, हम आशा करते हैं कि बाहर रखना होगा। यह निश्चित रूप से स्पर्श करना दिलचस्प होगा।

व्लादिस्लाव चेरनोव: हाँ।

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

ओलेग ओयामे: इस समस्या से आपका क्या मतलब है?

एंटोन कोप्पलोव: क्या मैं मचान पर जांच कर सकता हूं, उदाहरण के लिए, एक सौ मिलियन उपयोगकर्ताओं पर नहीं, बल्कि एक मिलियन पर? या आप पूरे डेटाबेस को स्थानांतरित करते हैं और इस कोड को पूर्ण रूप से जांचते हैं?

ओलेग ओयामे: नहीं, यह एक कॉपी का उपयोग नहीं करता है, लेकिन एक पूर्ण-वास्तविक उत्पादन है।

एंटोन कोप्पलोव: आह।

ओलेग ओयामे: और केवल कुछ नए परिवर्तनों के साथ कोड, और आधार का उत्पादन से ठीक उपयोग किया जाता है।

एंटोन कोप्पलोव: हाँ। मंचन में उत्पादन आधार से जुड़ना डरावना नहीं है?

ओलेग ओयामे: नहीं, क्योंकि परीक्षण परीक्षण उपयोगकर्ताओं पर होता है, अर्थात् , भले ही वहां कुछ होता है, यह "प्रभावित" नहीं करता है और वास्तविक उपयोगकर्ताओं को परेशान नहीं करेगा (इसके अलावा, इससे पहले कि कार्य दो बार परीक्षण किया गया है)।

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

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

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

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

एंटोन सर्गेव: क्या आपको गिट रिबेस की कोई समस्या है? जहां तक ​​मुझे पता है, यह बात बल्कि जगह है, आपको इसे सही तरीके से इस्तेमाल करने में सक्षम होना चाहिए। आपका नुस्खा क्या है?

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

एंटोन सर्गेव: हम पहले से ही जानते हैं कि आप Git का उपयोग करते हैं, लेकिन इसके अलावा आप JetCrains के ऐसे अद्भुत उपकरण का उपयोग TeamCity के रूप में भी करते हैं - यह एक निरंतर एकीकरण सर्वर है, और आपके पास यह सब JIRA बग ट्रैकर के साथ एकीकृत है, जैसा कि आप इसे समझते हैं - और कार्य सेटिंग, और स्वचालित स्थिति बदल जाती है। यह सब कैसे आपके बारे में आया और आपके साथ एकीकृत किया गया, और आप इसके साथ कैसे काम करते हैं?

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

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

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

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

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

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

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

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

व्लादिस्लाव चेरनोव: TeamCity , , . , , support . , Jenkins , . , , - , Jenkins, , , , .
TeamCity , -, , . , . , , , , . , . , , support , .

: , TeamCity , killer-, ― . - . .

: . , , , - , -. .

: , ― , TeamCity.

: Git. git-flow . Git. , . flow , feature branch, release branch, hot-fix branch, master, developer branch, , - ― , ― ?

: , . git-flow. : , production, , , , Deploy Dashboard. - : , -, , , production - . , , . , , . JIRA: - . , flow, , review, , , , . PHP-, . , , 40 , , , . , .

: : - ? 2 , , , , ?

: . , TeamCity , TeamCity, «» , , , web ― iOS, . , , , « 365», , .

: , . , , , Redmine, , -, -. , . : « -, ?» , .
, , , , JIRA, TeamCity Git, , , , ― . , AIDA, ? , , ?

: , AIDA. , , - , Jabber, , dashboard, , TeamCity, JIRA. commit message, Git log, . JIRA GitPHP : diff, . , , .

: AIDA, , - rocket science?

: : , .

: , , AIDA TeamCity, JIRA, Git?

: , AIDA API JIRA, TeamCity, Git . , , , , API. , , . , . AIDA, , -: , , automerge . , , - , AIDA , . ― .

: , , , , , - , ?

: . , AIDA, - . .

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

: , , AIDA .

: . . , , , ?

: , . , , unit- . , unit-. , Selenium PHP-, code coverage, . - - : , , , , . , push , , unit- selenium- ― , , , - , . , 18 000 (: 20000), .

, «», 11 , , , - 3,5 ― 18 . ― , . . , JIRA, : , .

: . Selenium, , Selenium?

: , , . , Explorer 6, : Chrome, Firefox, Explorer. . «» , , . GUI, , .

: . , : Mail.ru, , Mail.ru ( , ) Selenium. , ― , - Xen', «» , Selenium , , , , , . , - , - Explorer', , , , - , . , , , . , ? «»?

: , , - selenium- . , , , . : selenium- ― , , ― , . , , , , , . , , Google, , selenium- -.

: .

: , ― production-, . , , selenium-, . - .

: . ?

: , unit- , , . , devel. Selenium, devel, . -, devel . , devel , . , production, . selenium- , , - production. PHP , , .

: : unit- unit? ? , SQL- , ?

: unit- unit-, ― , . Unit Unit' .

: ( , ― , ). A/B- ?

: , A/B-. , Badoo A/B-, , , , , , . .

: ? , , , 18 3,5 , ?

: . यह सही है।

: , , , response production, - .

: , . , ―24 7 ― , , , , . - , .

: code coverage: , , . , , . , ?

: , - , , , unit-. , QA, QA selenium-, coverage , , - , , , - unit-, Selenium'. .

: «», . , - , , , - , «»?

: , , , - suites n- , . , . , , . , , , - 20 , , . 3,5 , . , 11 , suites , , TeamCity-. , , , , 7 , - , , , . 11 . , , , .

: . - , , ? , open-source , ?

: , , . , , Jenkins, , open-source. , , .

: . , , , , , , , . , , . , , , , - , , . , , , . , , , , GitHub -. , . , production , . , - sandbox, production, ?

: , - , Vagrant Puppet?

: . production - , . , devel'e , - . , . , , - , , ― , .

: - , Puppet Chef ?

: , Puppet production , , . , , ― .

: , . , , Puppet, . क्यों? . , MongoDB , -, , API , . - , , , . , , PHP, - , Mongo-, . ? , , «», «», Linux, ?

: DEV- . nginx -, , , - . , . devel'e. , , . , , , -, «», , , , «» Linux, , , , 50 50.

: , . , , - devel, , , , , GUI . , . , . , , , , , Vagrant'. Vagrant'; , , - Linux- , DEV-. , , devel, .

: , , , ― . , . , devel-o, - , , , , , - ― , , , . devel, , production. , - .

: , - , DEV, , , , , , . ― , , production - , , , . , .
- , , , , , , , , .

: , , , , - . . , - , - , :

• Jez Humble & David Farley «Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation» ;
• Paul M. Duvall, Steve Matyas & Andrew Glover «Continuous Integration: Improving Software Quality and Reducing Risk» ;
• Alan Berg, «Jenkins Continuous Integration Cookbook»

. , , , -, , -, .

: , , , - , -, , , , . «» , , « », , - . , HighLoad, , . , , , .

: , , . , . , , , , . , , - . , , .

: Badoo ― - . , .

: , , .

: .

: «www.itkompot.ru», - podfm.ru, iTunes. , .

.

.