🧖🏾 👩🏿‍⚖️ 🧖🏼 बेत में विकास की प्रक्रिया 🍩 🎴 🍶

आज हम बुश डेवलपमेंट वर्कशॉप का दौरा करेंगे, जिसमें हमारी वेबसाइट की नई कार्यक्षमता बनाई गई है, हम खुद इस प्रक्रिया के बारे में बात करेंगे - टास्क सेट करने से लेकर इसे युद्ध के माहौल में डालने तक।

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

मुख्य चरण

पूरी प्रक्रिया को चरणों में विभाजित किया जा सकता है:

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

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

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

पूरी प्रक्रिया की निगरानी की जाती है और कार्य ट्रैकर में अच्छी तरह से डिज़ाइन किए गए वर्कफ़्लो का उपयोग करके औपचारिकता की जाती है (हम JIRA, www.atlassian.com/software/jira का उपयोग करते हैं)।

उत्पाद पर काम करते हैं

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

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

PRD (उत्पाद आवश्यकताएँ दस्तावेज़) एक तकनीकी कार्य और नई कार्यक्षमता का पर्याप्त विवरण के बीच का अंतर है। आमतौर पर पीआरडी का अंतिम संस्करण एक सामान्य विचार देता है कि यह कैसा दिखेगा और इसे कैसे काम करना चाहिए। सभी कार्यान्वयन विवरण विकास प्रक्रिया में निर्दिष्ट हैं।

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

कार्यों और निष्पादकों का प्राथमिकताकरण

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

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

PHP प्रोग्रामर की एक विशेष टीम नई कार्यक्षमता बनाने में शामिल है, जिसे 2-4 लोगों के समूह में विभाजित किया गया है। प्रत्येक समूह अपने स्वयं के घटकों के सेट के लिए जिम्मेदार है। चूंकि कार्य आवश्यक रूप से एक विशिष्ट घटक से जुड़ा हुआ है, जो समूह इसे निष्पादित करेगा वह स्वचालित रूप से निर्धारित होता है।

टास्क ट्रैकर में सभी डेवलपर्स अपने कार्यों को एक डैशबोर्ड (अंग्रेजी डैशबोर्ड - कार्यों के लिए अलग-अलग फ़िल्टर के साथ एक पृष्ठ, विशेष रूप से प्रत्येक समूह के लिए कॉन्फ़िगर किया गया है) पर देखते हैं, जहाँ उन्हें एक निश्चित तरीके से समूहबद्ध और क्रमबद्ध किया जाता है। प्रति समूह में कार्यों का एक पूल है और ऐसे कार्यों की एक सूची है जिनसे डेवलपर सीधे संबंधित है (लेखक, कलाकार, समीक्षक)। वह स्थिति जब किसी व्यक्ति के पास करने के लिए कुछ भी नहीं है, सिद्धांत रूप में असंभव है। नीचे नवंबर के लिए टास्क ट्रैकर से निर्धारित कार्यों को पूरा किया गया है, जिसमें से यह देखा जा सकता है कि काम वास्तव में पूरे जोरों पर है!

नीचे उन कार्यों की एक अनुसूची है जो उत्पादन में गिर गए। इस पर आप सुधार और दैनिक सुधार में दैनिक राशि का मूल्यांकन कर सकते हैं:

तकनीकी कार्यान्वयन

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

इस चरण को फ़ोटो रेटिंग ( badoo.com/vote/ ) बनाने के उदाहरण के रूप में देखें, जिसका एक नया संस्करण हाल ही में लॉन्च किया गया था। उत्पाद टीम से, डेवलपर्स को एक दस्तावेज प्राप्त हुआ जिसमें निम्नलिखित आइटम हैं:

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

इस दस्तावेज़ के आधार पर, विभिन्न विभागों में कार्य निर्धारित किए गए थे: टेम्पलेट्स का लेआउट, साइट पर सी सेवाओं और बुनियादी ढांचे का विकास (इंटरफ़ेस तत्व, नए ब्लॉक, सेवाओं के साथ बातचीत, आदि)।

प्रत्येक पूर्ण किए गए कार्य की जाँच काफी औपचारिक है: एक विशिष्ट चेकलिस्ट और एक स्वचालित प्रक्रिया है। प्रत्येक कार्य अपने स्वयं के संस्करण नियंत्रण प्रणाली शाखा में विकसित किया जाता है (हम Git, git-scm.com का उपयोग करते हैं)। शाखाओं में विशेष नामकरण नियम हैं ( उदाहरण: BFG-123_another_cool_ticket), सभी कमिट्स को विवरण की शुरुआत में स्वचालित रूप से कार्य संख्या मिलती है ( उदाहरण: [BFG-123]: फोटो रेटिंग पर महान सुधार) - यह डेवलपर की शाखा से बिल्ड और अंतिम तक कोड आंदोलन को ट्रैक करने में मदद करता है। मास्टर शाखा को मारना।

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

डेवलपर द्वारा कार्य के विकास को पूरा करने के बाद, यह जिम्मेदार व्यक्ति या घटक की अच्छी समझ रखने की कोड समीक्षा में आता है। समीक्षा को अंजाम देने के लिए, हमने gitphp उपयोगिता ( www.gitphp.org/ ) को संशोधित किया ताकि इसमें सामान्य रूप से शाखाओं को देखना संभव हो सके, कोड पर टिप्पणी छोड़ दें, जिन्हें बाद में JRA में कार्य के लिए एक एकल टिप्पणी के रूप में भेजा जाता है। आमतौर पर, समीक्षक यह जाँचता है कि कंपनी द्वारा अपनाए गए नियमों के अनुसार कार्य कार्यान्वित किया गया है या नहीं, क्या डिबग लेफ्ट के रूप में कोई स्पष्ट निरीक्षण हैं; किसी अन्य डिज़ाइन पैटर्न का उपयोग करने की उपयुक्तता का संकेत दे सकता है या अधिक इष्टतम कार्यान्वयन का सुझाव दे सकता है।

किए गए परिवर्तनों के लिए यूनिट परीक्षण कार्य में मौजूद होना चाहिए, जबकि मौजूदा परीक्षणों को तोड़ना नहीं चाहिए (!)। पूरा होने के बाद, सभी परीक्षण TeamCity ( www.jetbrains.com/teamcity/ ) का उपयोग करके उपयुक्त शाखा पर चलाए जाते हैं, और यदि उनमें से कोई भी विफल होता है, तो डेवलपर को सूचित किया जाएगा। कई कार्यों के लिए, महत्वपूर्ण संकेतकों की निगरानी पूर्व-कॉन्फ़िगर की गई है। समीक्षक द्वारा सत्यापन के बाद, कार्य गुणवत्ता नियंत्रण विभाग में आता है।

परीक्षण और अनुवाद

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

डेवलपर के लिए यह अच्छा अभ्यास है कि पूर्ण कार्य कैसे होता है, परीक्षण करने की आवश्यकता है और कैसे। महत्वपूर्ण घटकों के परीक्षण के लिए सर्वोत्तम प्रथाओं को विकी पर वर्णित किया गया है (यह सभी दस्तावेज कंफ़्लुएंस, www.atlassian.com/software/confluence द्वारा प्रदान किए गए हैं)।

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

परीक्षण कार्यों के लिए, हमारा बुनियादी ढांचा कई संभावित वातावरण का समर्थन करता है:

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

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

रिलीज की तारीख

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

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

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

ऐसी घटनाओं को कम करने के लिए, हम अपनी विकास प्रक्रियाओं, कोड प्रबंधन, गणनाओं पर नियंत्रण और यथासंभव निगरानी उपकरणों को स्वचालित और बेहतर बनाने का प्रयास करते हैं।

परिणाम

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

अलेक्जेंडर treg ट्रेगर, डेवलपर।
एंड्री यून सास, ऑफ़लाइन अधिसूचना प्रबंधक।

बेत में विकास की प्रक्रिया