🍵 👈🏻 🤶 स्लैक द्वारा प्रयुक्त परियोजना परिनियोजन पद्धति ❤️ ⏲️ 📕

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

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

प्रोजेक्ट परिनियोजन प्रक्रियाएँ आज कैसे काम करती हैं

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

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

प्रोजेक्ट को तैनात करने के लिए स्लैक द्वारा उपयोग की जाने वाली चेकपॉइंट प्रणाली का इंटरफ़ेस।

उत्पादन में एक नई रिलीज को तैनात करने की प्रक्रिया को चार चरणों में दर्शाया जा सकता है।

▍1। एक रिलीज शाखा बनाना

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

▍2। इंटरमीडिएट में तैनाती

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

▍3। डॉगफूड और कैनरी वातावरण में तैनाती

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

▍4। उत्पादन में धीरे-धीरे निष्कर्ष

यदि नई रिलीज़ के मॉनिटरिंग संकेतक स्थिर हो जाते हैं, और यदि कैनरी के वातावरण में प्रोजेक्ट को लागू करने के बाद हमें कोई शिकायत नहीं मिली है, तो हम नए रिलीज के लिए प्रोडक्शन सर्वर के क्रमिक हस्तांतरण को जारी रखते हैं। परिनियोजन प्रक्रिया को निम्न चरणों में विभाजित किया गया है: 10%, 25%, 50%, 75% और 100%। नतीजतन, हम उत्पादन प्रणाली को धीरे-धीरे एक नई प्रणाली रिलीज के लिए स्थानांतरित कर सकते हैं। साथ ही, हमारे पास कुछ विसंगतियों को प्रकट करने के मामले में स्थिति की जांच करने का समय है।

▍ अगर तैनाती के दौरान कुछ गलत हुआ तो क्या होगा?

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

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

बिल्डिंग ब्लॉक्स की तैनाती

हमारी परियोजना परिनियोजन प्रणाली में निहित प्रौद्योगिकियों पर विचार करें।

▍प्रत्यक्ष तैनाती

ऊपर वर्णित वर्कफ़्लो पूर्वव्यापी में कुछ पूरी तरह से स्पष्ट हो सकता है। लेकिन हमारी तैनाती की व्यवस्था अभी इतनी दूर नहीं हुई।

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

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

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

1. उत्पादन सर्वर कांसुल कुंजी की निगरानी करते हैं। 2. कुंजी बदल रही है, यह सर्वर को बताता है कि उन्हें नया कोड डाउनलोड करना शुरू करना होगा। 3. सर्वर एप्लिकेशन कोड के साथ तारबॉल फाइल अपलोड करते हैं

Tआटोमिक परिनियोजन

एक अन्य समाधान जो हमें बहु-स्तरीय तैनाती प्रणाली में लाने में मदद करता था, वह था परमाणु तैनाती।

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

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

1. एक "ठंड" निर्देशिका में आवेदन कोड खोलना। 2. सिस्टम को "ठंडे" निर्देशिका में बदलना, जो "हॉट" (परमाणु संचालन) बन जाता है

निचला रेखा: विश्वसनीयता पर जोर देने वाली पारी

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

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

लेकिन हम वहां रुकने वाले नहीं हैं। हम अधिक उन्नत सहायक उपकरण और स्वचालन उपकरण का उपयोग करके इस प्रणाली में लगातार सुधार कर रहे हैं।

प्रिय पाठकों! जहां आप काम करते हैं, वहां नए प्रोजेक्ट रिलीज को तैनात करने की प्रक्रिया कैसी है?

स्लैक द्वारा प्रयुक्त परियोजना परिनियोजन पद्धति