स्लैक में प्रयुक्त प्रोजेक्ट परिनियोजन पद्धति

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

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

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

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

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

चेकपॉइंट सिस्टम का इंटरफ़ेस, जिसका उपयोग स्लैक में परियोजनाओं को तैनात करने के लिए किया जाता है

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

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

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

▍2. मंचन वातावरण में तैनाती

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

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

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

▍4. उत्पादन के लिए क्रमिक रिलीज

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

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

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

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

एक परिनियोजन प्रणाली के बिल्डिंग ब्लॉक

आइए उन प्रौद्योगिकियों पर नजर डालें जो हमारी परियोजना परिनियोजन प्रणाली का आधार हैं।

▍त्वरित तैनाती

ऊपर वर्णित वर्कफ़्लो, पीछे मुड़कर देखने पर, कुछ हद तक स्पष्ट लग सकता है। लेकिन हमारी तैनाती प्रणाली तुरंत ऐसी नहीं बनी.

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

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

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

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

▍परमाणु तैनाती

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

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

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

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

परिणाम: विश्वसनीयता पर जोर दिया गया

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

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

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

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

स्रोत: www.habr.com