बरामदगी

इस लेख में मैं अपने अनुभव को साझा करना चाहता हूं कि हमने अपनी कंपनी में "फ्रीजिंग" कार्यों की समस्या को कैसे हल किया।

मैं एक स्टार्टअप में काम करता हूं, जो सभी स्टार्टअप की तरह, एक साल पहले 10 लोगों से आज 35 लोगों तक विकास का चरण अनुभव कर रहा है, और इस समय के दौरान प्रोग्रामर की संख्या 5 से 25 लोगों की हो गई है और उनमें से ज्यादातर पिछले छह महीनों में आए हैं।

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

विकास प्रक्रिया, अगर इसे "प्रक्रिया" कहा जा सकता है, तो यह थी:

कोड की समीक्षा पास करते ही डेवलपर का काम समाप्त हो गया और उसने इसे विकसित करने के लिए गिरवी रख दिया।

परीक्षक का काम समाप्त हो गया जब उसने मास्टर शाखा में परीक्षण और smerzhil किया।
दैनिक परियोजना के प्रबंधक के बाद देवोप्स कभी-कभी "डिप्लॉय टू प्रोडक्ट" बटन पर क्लिक करते हैं, उन्होंने कहा: "वे लंबे समय से तैनात नहीं थे, शायद आज हम रद्द कर दिए जाएंगे?"

क्या अच्छा है:

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

समस्याएं:

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

मैं उन दो मामलों का वर्णन करूंगा, जिन्होंने हमें स्पष्ट कर दिया है कि आगे काम करना असंभव है।

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

सबसे पहले, हमने बहुत सारे code_review का पता लगाया। यह पता चला कि इस समस्या को काफी सरलता से हल किया जा सकता है, निम्नलिखित नियमों के लिए धन्यवाद:

1. केवल तीन कार्य ही code_review स्थिति में हो सकते हैं। यह सबसे महत्वपूर्ण नियम है जिसका उल्लंघन नहीं किया जा सकता है।
2. यदि प्रोग्रामर ने विकास समाप्त कर लिया है और कार्य को code_review में अनुवादित करना चाहता है, तो वह यह देखना चाहता है कि क्या वह ऐसा कर सकता है (नियम देखें)।
3. यदि पहले से ही स्थिति में तीन कार्य हैं code_review, तो पहले वह अपने सहयोगी को एक कोड समीक्षा करने में मदद करता है। और अगर समीक्षा की प्रक्रिया में उसके पास बदलाव के लिए टिप्पणियां या सुझाव हैं, तो वह एक सहकर्मी के साथ जोड़ी प्रोग्रामिंग करने जाता है, जिसके कार्य की वह समीक्षा कर रहा है।

मुख्य विचार यह नहीं है कि जब यह पहले से ही लिखा हो, तो कोड को फ्रीज कर दिया जाए, और एक सप्ताह के लिए काम के प्रवाह के साथ परीक्षकों को भी प्रदान किया जाए।

हमने इसे एक घंटे में लागू किया: हम एक साथ मिल गए, चर्चा की और एक समीक्षा करने और जोड़ी प्रोग्रामिंग करने के लिए चले गए।

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

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

यह समाधान एक प्रकार का हॉटफ़िक्स था, और तब प्रक्रियाओं में बुनियादी परिवर्तन करना आवश्यक था।

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

हमने डेवलपर्स को कई टीमों में संगठित किया: प्रत्येक ग्राहक के लिए, क्योंकि हमारे पास एक मुख्य उत्पाद है, लेकिन यह प्रत्येक ग्राहक के लिए लंबे समय तक अनुकूलित है (हम एक उत्पाद और सेवा कंपनी का एक संकर हैं)। अब ठेस पहुंचाने का काम टीम की जिम्मेदारी है। कोई परिचित परीक्षण टीम और डेपॉप्स नहीं हैं, लेकिन एक सेवा के रूप में क्यूए हैं, और एक सेवा के रूप में देवओपीएस हैं।

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

एक सेवा के रूप में DevOps एक टीम है जो तैनाती स्क्रिप्ट विकसित करती है, परीक्षण वातावरण के काम का समर्थन करती है, और विभिन्न कार्यों को स्वचालित करती है।

नई विकास प्रक्रिया यह है:

1. ग्राहक, उत्पाद प्रबंधक या टॉपर्स में से कोई एक कार्य है।
2. स्प्रिंट योजना के चरण में, हम इसे विकास में लेते हैं।
3. डेवलपर कार्य के लिए एक अलग शाखा में कोड लिखता है और जब वह पूरा कर लेता है तो उसे स्थिति code_review में बदल देता है।
4. सहयोगियों में से एक समीक्षा करता है।
5. जब कार्य ने समीक्षा पास कर ली है, तो डेवलपर उस शाखा में विलय कर देता है, जो इस शाखा को विकसित करने के लिए प्रतिबद्ध है और परीक्षण पर्यावरण के लिए इस शाखा को तैनात करती है।
6. फिर उन्होंने एक रैली की योजना बनाई जिसे हम टेस्ट सत्र कहते हैं और यदि आवश्यक हो तो एक क्यूए इंजीनियर और सहयोगियों को आमंत्रित करते हैं।
7. क्यूए इंजीनियर टेस्ट सत्र से पहले परीक्षण योजना की जांच करता है और उसे परिष्कृत करता है।
8. टेस्ट सत्र में, डेवलपर डेमो के रूप में संपूर्ण परीक्षण योजना से चलता है। कभी-कभी एक परीक्षण योजना भागों में टूट जाती है और फिर हम समानांतर में परीक्षण करते हैं। मुख्य बात यह है कि यह बैठकों के लिए एक अलग कमरे में एक साथ किया जाता है।
9. यदि परीक्षण करने के बाद बग नहीं पाए गए, तो डेवलपर अपने कोड को विकसित शाखा में और तुरंत मास्टर शाखा में विलय कर देता है (यह कुछ ऐसा है जिसे हम अभी तक नहीं बदल पाए हैं, क्योंकि हमें अभी भी तैनाती स्क्रिप्ट को अपडेट करने की आवश्यकता है)। भविष्य में हम केवल मास्टर शाखा छोड़ने की योजना बनाते हैं।
10. उसके बाद, डेवलपर मंचन पर तैनाती शुरू करता है, बस यह सत्यापित करने के लिए कि तैनाती अभी भी उत्पाद के समान वातावरण पर चलती है।
11. यदि सब कुछ ठीक है, तो तुरंत ठेस के लिए तैनात करें। तैनात करने या न करने का निर्णय विकास टीम द्वारा किया जाता है, लेकिन क्यूए के पास तैनाती रोकने का अधिकार है यदि यह मानता है कि अतिरिक्त परीक्षण आवश्यक है, या यह कि यदि कुछ महत्वपूर्ण बग को ठीक करने के लिए आवश्यक है तो इंतजार करना आवश्यक है।

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

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

योजना बनाने पर भी, हम विकास के समय का मूल्यांकन नहीं करते हैं, लेकिन जब हम किसी विशेषता को तैनात करने की योजना बनाते हैं, तो इसके बारे में बात करते हैं।

डेली पर, हम यह नहीं कहते हैं कि "मैंने विकास को समाप्त कर दिया है", लेकिन कहते हैं कि "आज मैं फीचर एक्स की तैनाती करने जा रहा हूं", या "आज मैं टेस्ट के माहौल को दूर कर रहा हूं, जिसके पास टेस्ट सत्र में मेरी मदद करने का समय है?"

नतीजतन, हमने स्वतंत्र विकास टीमों को विकसित किया है जो अपने स्वयं के परीक्षण वातावरण के मालिक हैं और योजना बनाते हैं कि कब और क्या तैनात करना है।