थिएरी कार्स के साथ साक्षात्कार, ओपनस्टैक तकनीकी समिति के अध्यक्ष और रिलीज़ प्रबंधक

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

नीचे हम ओपनस्टैक तकनीकी समिति के अध्यक्ष थिएरी कार्रेज़ और रिलीज़ मैनेजर के साथ एक साक्षात्कार प्रस्तुत करते हैं।

मिरान्टिस: हमें अपने बारे में बताओ।

थियरी कार्स: बिल्कुल! इस साल मैं 40 साल का हो गया। मैं फ्रांस के केंद्र में एक छोटे से गाँव में अपनी पत्नी और दो बच्चों के साथ रहता हूँ।

प्रश्न: बहुत अच्छा। क्या आपको दुनिया भर के डेवलपर्स के बीच सांस्कृतिक अंतर दिखाई देता है?

A: हाँ, ये अंतर हड़ताली हैं, और वैश्विक समुदाय के कार्यों में से एक को पूरा करने के लिए एक है जो उन्हें खत्म कर देता है। इसके अलावा, पेशेवर अनुभव की विविधता से उत्पन्न मतभेद हैं, इसलिए यह केवल भूगोल का मामला नहीं है।

प्रश्न: क्या आप एक उदाहरण दे सकते हैं? उदाहरण के लिए, पूर्वी यूरोप में, कोड समीक्षाओं को आलोचना या अस्वीकृति के रूप में माना जाता है - हालांकि वास्तव में ऐसी समीक्षाओं का उद्देश्य डेवलपर्स को कोड को बेहतर बनाने में मदद करना है।

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

प्रश्न: ओपनस्टैक के साथ काम करने का आपका इतिहास क्या है? आप परियोजना में भाग लेने में क्यों रुचि रखते हैं?

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

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

प्रश्न: कंपनियां "ओपन इनोवेशन" डेवलपमेंट मॉडल कैसे अपनाती हैं?

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

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

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

प्रश्न: ओपनस्टैक के निर्माण का सिद्धांत कौन निर्धारित करता है - निर्णय कैसे किए जाते हैं?

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

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

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

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

प्रश्न: अक्सर आईआरसी के उपयोग पर ओपनस्टैक टिप्पणी में रुचि रखने वाले लोग। “आप आईआरसी का उपयोग क्यों कर रहे हैं? यह बहुत पुराना है। आप सभी की तरह ट्विटर का उपयोग क्यों नहीं करते हैं? "

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

प्रश्न: आपने छह महीने की रिलीज़ साइकिल का उल्लेख किया है। उनका मूल्य क्या है?

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

प्रश्न: क्या आप ओपनस्टैक रिलीज चक्र का वर्णन कर सकते हैं, मंथन से लेकर कार्यान्वयन और एकीकरण तक?

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

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

प्रश्न: ओपनस्टैक रिलीज की आवृत्ति क्या निर्धारित करती है?

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

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

प्रश्न: तीन महीने के रिलीज चक्र के फायदे और नुकसान क्या हैं?

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

प्रश्न: अगर वे किसी संगोष्ठी को छोड़ने के लिए मजबूर हैं या डेवलपर संगोष्ठी के लिए यात्रा नहीं कर सकते हैं तो डेवलपर्स कैसे भाग ले सकते हैं?

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

प्रश्न: क्या ओपेनस्टैक समुदाय एक ऑनलाइन-ओनली डेवलपर कार्यशाला के साथ उबंटू समुदाय का अनुसरण करने के बारे में सोचता है? क्या यह ओपनस्टैक के लिए काम करेगा?

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

प्रश्न: हमने हाल ही में निरंतर एकीकरण के लिए तकनीकी परियोजना प्रबंधक मोंटी टेलर का साक्षात्कार लिया। आपको क्या लगता है कि ओपनस्टैक के लिए निरंतर एकीकरण इतना महत्वपूर्ण है?

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

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

प्रश्न: क्या ऐसी विकास प्रक्रिया के क्षेत्र हैं जो अभी तक स्वचालित नहीं हैं, लेकिन भविष्य में स्वचालित हो जाएंगे?

एक: नहीं, सभी पहलू स्वचालित हैं, हालांकि सुधार की गुंजाइश है। कुछ परियोजनाएँ अधिक एकीकरण परीक्षणों का उपयोग कर सकती हैं; आपका निरंतर एकीकरण आपके परीक्षणों जितना ही अच्छा है।

प्रश्न: उन डेवलपर्स को क्या करना चाहिए जो ओपनस्टैक के लिए कोड लिखने में शामिल होना चाहते हैं?

A: हास्य की भावना। ओपनस्टैक डेवलपर्स अच्छे लोगों का एक समुदाय है और यह हमेशा इस तरह रहना पसंद करेगा!

प्रश्न: आप शुरुआती लोगों को क्या सलाह देंगे - जो डेवलपर्स योगदान देना चाहते हैं, और कंपनियां जो ओपनस्टैक के आसपास व्यवसाय बनाना चाहती हैं?

एक: ओपनस्टैक प्रोजेक्ट वह है जो हम इसे बनाते हैं। हमसे जुड़ें, आप इसे पछतावा नहीं होगा!

प्रश्न: धन्यवाद, थियरी!

A: धन्यवाद!