Slack मा प्रयोग गरिएको परियोजना परिनियोजन विधि

उत्पादनमा नयाँ परियोजना रिलीज ल्याउनको लागि तैनाती गति र समाधान विश्वसनीयता बीच सावधान सन्तुलन चाहिन्छ। ढिलो मानहरू छिटो पुनरावृत्तिहरू, छोटो प्रतिक्रिया चक्रहरू, र प्रयोगकर्ता अनुरोधहरूमा द्रुत प्रतिक्रिया। थप रूपमा, कम्पनीसँग सयौं प्रोग्रामरहरू छन् जसले सकेसम्म उत्पादक हुन प्रयास गर्छन्।

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

आज कसरी परियोजना परिनियोजन प्रक्रियाहरू काम गर्दछ

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

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

चेकपोइन्ट प्रणालीको इन्टरफेस, जुन परियोजनाहरू डिप्लोय गर्न Slack मा प्रयोग गरिन्छ

उत्पादनमा नयाँ रिलीज डिप्लोय गर्ने प्रक्रियालाई चार चरणहरू समावेशको रूपमा सोच्न सकिन्छ।

▍१। विमोचन शाखा सिर्जना गर्दै

प्रत्येक रिलीज नयाँ रिलीज शाखा संग सुरु हुन्छ, हाम्रो Git इतिहास मा एक बिन्दु। यसले तपाईंलाई रिलीजमा ट्यागहरू तोक्न अनुमति दिन्छ र उत्पादनमा रिलीजको लागि रिलीजको तयारी गर्ने प्रक्रियामा फेला परेका बगहरूको लागि प्रत्यक्ष समाधानहरू गर्न सक्ने ठाउँ प्रदान गर्दछ।

▍२। स्टेजिङ वातावरणमा तैनाती

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

▍३। डगफुड र क्यानरी वातावरणमा तैनाती

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

▍४। उत्पादनको लागि क्रमिक रिलीज

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

▍ डिप्लोइमेन्टको क्रममा केहि गलत भयो भने के हुन्छ?

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

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

एक तैनाती प्रणाली को निर्माण ब्लक

हाम्रो प्रोजेक्ट डिप्लोइमेन्ट प्रणालीलाई अधोरेखित गर्ने प्रविधिहरू हेरौं।

▍ द्रुत तैनाती

माथि वर्णन गरिएको कार्यप्रवाह, पछाडि फर्केर हेर्दा, केहि स्पष्ट देखिन सक्छ। तर हाम्रो डिप्लोयमेन्ट सिस्टम तत्कालै त्यस्तो बन्न सकेन।

जब कम्पनी धेरै सानो थियो, हाम्रो सम्पूर्ण अनुप्रयोग 10 Amazon EC2 उदाहरणहरूमा चल्न सक्छ। यस अवस्थामा परियोजना तैनाथ गर्नु भनेको सबै सर्भरहरू द्रुत रूपमा सिङ्क्रोनाइज गर्न rsync प्रयोग गर्नु हो। पहिले, नयाँ कोड उत्पादनबाट केवल एक कदम टाढा थियो, स्टेजिङ वातावरण द्वारा प्रतिनिधित्व। यस्तो वातावरणमा विधानसभाहरू सिर्जना र परीक्षण गरियो, र त्यसपछि सीधा उत्पादनमा गए। यस्तो प्रणाली बुझ्न धेरै सजिलो थियो; यसले कुनै पनि प्रोग्रामरलाई कुनै पनि समयमा लेखेको कोड प्रयोग गर्न अनुमति दिन्छ।

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

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

1. उत्पादन सर्भरहरूले कन्सुल कुञ्जीलाई निगरानी गर्दछ। 2. मुख्य परिवर्तनहरू, यसले सर्भरहरूलाई नयाँ कोड डाउनलोड गर्न सुरु गर्न आवश्यक छ भनी बताउँछ। 3. सर्भरहरूले एप्लिकेसन कोडको साथ टारबल फाइलहरू डाउनलोड गर्छन्

▍परमाणु परिनियोजन

अर्को समाधान जसले हामीलाई बहु-स्तरीय तैनाती प्रणालीमा पुग्न मद्दत गर्यो परमाणु तैनाती थियो।

परमाणु परिनियोजनहरू प्रयोग गर्नु अघि, प्रत्येक परिनियोजनले ठूलो संख्यामा त्रुटि सन्देशहरू ल्याउन सक्छ। तथ्य यो हो कि उत्पादन सर्भरहरूमा नयाँ फाइलहरू प्रतिलिपि गर्ने प्रक्रिया परमाणु थिएन। यसले समयको छोटो सञ्झ्यालमा परिणाम दियो जहाँ नयाँ प्रकार्यहरू बोलाउने कोडहरू उपलब्ध हुनुभन्दा पहिले उपलब्ध थियो। जब यस्तो कोड कल गरिएको थियो, यसले आन्तरिक त्रुटिहरू फर्काइयो। यो असफल API अनुरोधहरू र टुटेको वेब पृष्ठहरूमा प्रकट भयो।

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

1. "चिसो" डाइरेक्टरीमा अनुप्रयोग कोड अनप्याक गर्दै। 2. प्रणालीलाई "चिसो" डाइरेक्टरीमा स्विच गर्दै, जुन "तातो" हुन्छ (परमाणु सञ्चालन)

परिणामहरू: विश्वसनीयतामा जोड दिनुहोस्

2018 मा, परियोजना यस्तो स्तरमा बढ्यो कि धेरै छिटो तैनातीले उत्पादनको स्थिरतालाई हानि गर्न थाल्यो। हामीसँग धेरै उन्नत परिनियोजन प्रणाली थियो जसमा हामीले धेरै समय र प्रयास लगानी गर्यौं। हामीले गर्नुपर्ने भनेको हाम्रो परिनियोजन प्रक्रियाहरू पुनर्निर्माण र सुधार गर्नु थियो। हामी एक धेरै ठूलो कम्पनीमा बढेका छौं, जसको विकासहरू विश्वभरि निर्बाध संचार व्यवस्थित गर्न र महत्त्वपूर्ण समस्याहरू समाधान गर्न प्रयोग गरिएको छ। त्यसकारण, विश्वसनीयता हाम्रो ध्यानको केन्द्रबिन्दु बन्यो।

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

तर हामी त्यहाँ रोकिनेवाला छैनौं। हामी यस प्रणालीलाई निरन्तर सुधार गर्दैछौं, थप उन्नत सहायक उपकरणहरू र काम स्वचालन उपकरणहरू प्रयोग गरेर।

प्रिय पाठकहरु! तपाईंले काम गरेको ठाउँमा नयाँ प्रोजेक्ट रिलीजहरू डिप्लोय गर्ने प्रक्रियाले कसरी काम गर्छ?

स्रोत: www.habr.com