Slack मध्ये वापरलेली प्रोजेक्ट डिप्लॉयमेंट पद्धत

उत्पादनामध्ये नवीन प्रोजेक्ट रिलीझ आणण्यासाठी तैनाती गती आणि समाधानाची विश्वासार्हता यांच्यात काळजीपूर्वक संतुलन आवश्यक आहे. स्लॅक मूल्ये जलद पुनरावृत्ती, लहान अभिप्राय चक्र आणि वापरकर्त्याच्या विनंतीस त्वरित प्रतिसाद देतात. याव्यतिरिक्त, कंपनीकडे शेकडो प्रोग्रामर आहेत जे शक्य तितके उत्पादक होण्याचा प्रयत्न करतात.

साहित्याचे लेखक, ज्याचे भाषांतर आम्ही आज प्रकाशित करत आहोत, असे म्हणतात की अशा मूल्यांचे पालन करण्याचा प्रयत्न करणाऱ्या आणि त्याच वेळी वाढणाऱ्या कंपनीने प्रकल्पांच्या उपयोजनासाठी त्याची प्रणाली सतत सुधारली पाहिजे. कंपनीने कामाच्या प्रक्रियेची पारदर्शकता आणि विश्वासार्हता यासाठी गुंतवणूक करणे आवश्यक आहे, हे सुनिश्चित करण्यासाठी की या प्रक्रिया प्रकल्पाच्या प्रमाणाशी सुसंगत आहेत. येथे आपण स्लॅकमध्ये विकसित झालेल्या वर्कफ्लोबद्दल आणि काही निर्णयांबद्दल बोलू ज्यामुळे कंपनीला आज अस्तित्वात असलेल्या प्रोजेक्ट डिप्लॉयमेंट सिस्टमचा वापर करण्यास प्रवृत्त केले.

आज प्रकल्प उपयोजन प्रक्रिया कशा कार्य करतात

Slack मधील प्रत्येक PR (पुल विनंती) कोड पुनरावलोकनाच्या अधीन असणे आवश्यक आहे आणि सर्व चाचण्या यशस्वीपणे उत्तीर्ण होणे आवश्यक आहे. या अटी पूर्ण झाल्यानंतरच प्रोग्रामर त्याचा कोड प्रोजेक्टच्या मास्टर ब्रँचमध्ये विलीन करू शकतो. तथापि, हा कोड फक्त उत्तर अमेरिकन वेळेत, व्यवसायाच्या वेळेत तैनात केला जातो. परिणामी, आमचे कर्मचारी त्यांच्या कामाच्या ठिकाणी आहेत या वस्तुस्थितीमुळे, आम्ही कोणत्याही अनपेक्षित समस्यांचे निराकरण करण्यासाठी पूर्णपणे तयार आहोत.

दररोज आम्ही सुमारे 12 नियोजित तैनाती करतो. प्रत्येक डिप्लॉयमेंट दरम्यान, डिप्लॉयमेंट लीड म्हणून नियुक्त केलेला प्रोग्रामर नवीन बिल्ड उत्पादनात आणण्यासाठी जबाबदार असतो. ही एक बहु-चरण प्रक्रिया आहे जी असेंब्ली सहजतेने उत्पादनात आणली जाईल याची खात्री करते. या दृष्टिकोनामुळे, आमच्या सर्व वापरकर्त्यांवर परिणाम होण्यापूर्वीच आम्ही त्रुटी शोधू शकतो. जर बर्याच त्रुटी असतील तर, असेंब्लीची तैनाती मागे घेतली जाऊ शकते. रिलीझ झाल्यानंतर एखादी विशिष्ट समस्या आढळल्यास, त्याचे निराकरण सहज करता येते.

चेकपॉईंट सिस्टमचा इंटरफेस, जो प्रकल्प तैनात करण्यासाठी स्लॅकमध्ये वापरला जातो

उत्पादनासाठी नवीन प्रकाशन उपयोजित करण्याच्या प्रक्रियेचा विचार केला जाऊ शकतो चार चरणांचा समावेश आहे.

▍1. प्रकाशन शाखा तयार करणे

प्रत्येक रिलीझ नवीन रिलीझ शाखेने सुरू होते, आमच्या Git इतिहासातील एक बिंदू. हे तुम्हाला रिलीझला टॅग नियुक्त करण्यास अनुमती देते आणि उत्पादनासाठी रिलीज तयार करण्याच्या प्रक्रियेत आढळलेल्या बगसाठी तुम्ही थेट निराकरणे करू शकता अशी जागा प्रदान करते.

▍2. स्टेजिंग वातावरणात उपयोजन

पुढील पायरी म्हणजे स्टेजिंग सर्व्हरवर असेंब्ली तैनात करणे आणि प्रकल्पाच्या एकूण कार्यक्षमतेसाठी स्वयंचलित चाचणी चालवणे (स्मोक टेस्ट). स्टेजिंग वातावरण हे उत्पादन वातावरण आहे जे बाह्य रहदारी प्राप्त करत नाही. या वातावरणात, आम्ही अतिरिक्त मॅन्युअल चाचणी करतो. हे आम्हाला अतिरिक्त आत्मविश्वास देते की सुधारित प्रकल्प योग्यरित्या कार्य करतो. हा आत्मविश्वास प्रदान करण्यासाठी केवळ स्वयंचलित चाचण्या पुरेशा नाहीत.

▍3. डॉगफूड आणि कॅनरी वातावरणात उपयोजन

उत्पादनासाठी उपयोजन डॉगफूड वातावरणासह सुरू होते, जे होस्टच्या संचाद्वारे प्रस्तुत केले जाते जे आमच्या अंतर्गत स्लॅक कार्यस्थानांना सेवा देतात. आम्ही खूप सक्रिय स्लॅक वापरकर्ते असल्याने, हा दृष्टीकोन घेतल्याने आम्हाला उपयोजनापूर्वी बरेच बग पकडण्यात मदत झाली. प्रणालीची मूलभूत कार्यक्षमता खंडित होणार नाही याची आम्ही खात्री केल्यानंतर, कॅनरी वातावरणात असेंब्ली तैनात केली जाते. हे अशा प्रणालींचे प्रतिनिधित्व करते जे उत्पादन रहदारीच्या अंदाजे 2% आहे.

▍4. उत्पादनासाठी हळूहळू प्रकाशन

जर नवीन रिलीझसाठी मॉनिटरिंग इंडिकेटर स्थिर असल्याचे दिसून आले आणि कॅनरी वातावरणात प्रकल्प उपयोजित केल्यानंतर आम्हाला कोणत्याही तक्रारी प्राप्त झाल्या नाहीत, तर आम्ही उत्पादन सर्व्हर हळूहळू नवीन रिलीझमध्ये हस्तांतरित करणे सुरू ठेवतो. उपयोजन प्रक्रिया खालील टप्प्यात विभागली गेली आहे: 10%, 25%, 50%, 75% आणि 100%. परिणामी, आम्ही सिस्टमच्या नवीन रिलीझमध्ये उत्पादन रहदारी हळूहळू हस्तांतरित करू शकतो. त्याच वेळी, कोणतीही विसंगती आढळल्यास परिस्थितीची तपासणी करण्यासाठी आमच्याकडे वेळ आहे.

▍ तैनाती दरम्यान काहीतरी चूक झाल्यास काय?

कोडमध्ये बदल करणे नेहमीच धोक्याचे असते. परंतु प्रशिक्षित "उपयोजन नेत्यांच्या" उपस्थितीमुळे आम्ही याचा सामना करतो जे उत्पादनात नवीन प्रकाशन आणण्याची प्रक्रिया व्यवस्थापित करतात, निर्देशकांचे निरीक्षण करतात आणि कोड रिलीज करणार्‍या प्रोग्रामरच्या कार्याचे समन्वय साधतात.

खरोखर काहीतरी चूक झाल्यास, आम्ही शक्य तितक्या लवकर समस्या शोधण्याचा प्रयत्न करतो. आम्ही समस्येची तपासणी करतो, त्रुटी निर्माण करणारा PR शोधतो, तो परत आणतो, त्याचे पूर्ण विश्लेषण करतो आणि नवीन बिल्ड तयार करतो. खरे आहे, काहीवेळा प्रकल्प उत्पादनात येईपर्यंत या समस्येकडे लक्ष दिले जात नाही. अशा परिस्थितीत, सेवा पुनर्संचयित करणे ही सर्वात महत्वाची गोष्ट आहे. म्हणून, आम्ही समस्येचा तपास सुरू करण्यापूर्वी, आम्ही ताबडतोब मागील कार्यरत बिल्डवर परत जातो.

डिप्लॉयमेंट सिस्टमचे बिल्डिंग ब्लॉक्स

आमच्या प्रोजेक्ट डिप्लॉयमेंट सिस्टमला अधोरेखित करणारे तंत्रज्ञान पाहू या.

▍त्वरित उपयोजन

वर वर्णन केलेला वर्कफ्लो, भूतकाळात, काहीसा स्पष्ट वाटू शकतो. पण आमची तैनाती यंत्रणा लगेच तशी बनली नाही.

जेव्हा कंपनी खूपच लहान होती, तेव्हा आमचा संपूर्ण ऍप्लिकेशन 10 Amazon EC2 उदाहरणांवर चालू शकतो. या परिस्थितीत प्रकल्प तैनात करणे म्हणजे सर्व सर्व्हर द्रुतपणे समक्रमित करण्यासाठी rsync वापरणे. पूर्वी, नवीन कोड उत्पादनापासून फक्त एक पाऊल दूर होता, स्टेजिंग वातावरणाद्वारे प्रस्तुत केले जात असे. अशा वातावरणात असेंब्ली तयार केली आणि चाचणी केली गेली आणि नंतर थेट उत्पादनावर गेले. अशी प्रणाली समजणे खूप सोपे होते; कोणत्याही प्रोग्रामरला त्याने लिहिलेला कोड कधीही तैनात करण्याची परवानगी दिली.

परंतु आमच्या ग्राहकांची संख्या जसजशी वाढत गेली, तसतसे प्रकल्पाला समर्थन देण्यासाठी आवश्यक असलेल्या पायाभूत सुविधांचे प्रमाण वाढले. लवकरच, सिस्टीमच्या सततच्या वाढीमुळे, सर्व्हरवर नवीन कोड पुश करण्यावर आधारित आमचे डिप्लॉयमेंट मॉडेल आता त्याचे काम करत नव्हते. अर्थात, प्रत्येक नवीन सर्व्हर जोडणे म्हणजे उपयोजन पूर्ण करण्यासाठी लागणारा वेळ वाढवणे. rsync च्या समांतर वापरावर आधारित धोरणांनाही काही मर्यादा आहेत.

आम्ही या समस्येचे निराकरण पूर्णतः समांतर उपयोजन प्रणालीकडे जाऊन केले, जे जुन्या प्रणालीपेक्षा वेगळ्या पद्धतीने डिझाइन केले होते. म्हणजे, आता आम्ही सिंक्रोनाइझेशन स्क्रिप्ट वापरून सर्व्हरला कोड पाठवला नाही. आता प्रत्येक सर्व्हरने नवीन असेंब्ली स्वतंत्रपणे डाउनलोड केली आहे, हे जाणून की, कॉन्सुल की बदलाचे निरीक्षण करून असे करणे आवश्यक आहे. सर्व्हरने कोड समांतर लोड केला. यामुळे आम्हाला सतत सिस्टम वाढीच्या वातावरणातही तैनातीचा उच्च वेग राखता आला.

1. प्रोडक्शन सर्व्हर कॉन्सुल कीचे निरीक्षण करतात. 2. मुख्य बदल, हे सर्व्हरना सांगते की त्यांना नवीन कोड डाउनलोड करणे सुरू करणे आवश्यक आहे. 3. सर्व्हर अनुप्रयोग कोडसह टारबॉल फायली डाउनलोड करतात

▍अणू तैनाती

आणखी एक उपाय ज्याने आम्हाला बहु-स्तरीय तैनाती प्रणालीपर्यंत पोहोचण्यास मदत केली ती म्हणजे अणु तैनाती.

अणु उपयोजन वापरण्यापूर्वी, प्रत्येक तैनातीमुळे मोठ्या प्रमाणात त्रुटी संदेश येऊ शकतात. वस्तुस्थिती अशी आहे की उत्पादन सर्व्हरवर नवीन फाइल्स कॉपी करण्याची प्रक्रिया अणू नव्हती. यामुळे नवीन फंक्शन्स म्हटला जाणारा कोड फंक्शन्स स्वतः उपलब्ध होण्याआधी उपलब्ध होताना एक लहान विंडो आली. जेव्हा असा कोड कॉल केला गेला तेव्हा त्याचा परिणाम अंतर्गत त्रुटी परत केल्या गेल्या. हे अयशस्वी API विनंत्या आणि तुटलेल्या वेब पृष्ठांमध्ये प्रकट होते.

या समस्येवर काम करणार्‍या टीमने "हॉट" आणि "कोल्ड" डिरेक्ट्रीची संकल्पना सादर करून त्याचे निराकरण केले. हॉट डिरेक्टरीमधील कोड उत्पादन रहदारीवर प्रक्रिया करण्यासाठी जबाबदार आहे. आणि "कोल्ड" डिरेक्टरीमध्ये, कोड, सिस्टम चालू असताना, फक्त वापरासाठी तयार केला जात आहे. उपयोजनादरम्यान, नवीन कोड न वापरलेल्या कोल्ड निर्देशिकेत कॉपी केला जातो. नंतर, सर्व्हरवर कोणतीही सक्रिय प्रक्रिया नसताना, त्वरित निर्देशिका स्विच केले जाते.

1. "कोल्ड" निर्देशिकेत अनुप्रयोग कोड अनपॅक करणे. 2. सिस्टमला "थंड" निर्देशिकेवर स्विच करणे, जे "गरम" होते (अणु ऑपरेशन)

परिणाम: विश्वासार्हतेकडे जोर देणे

2018 मध्ये, प्रकल्प इतक्या प्रमाणात वाढला की अतिशय जलद तैनातीमुळे उत्पादनाच्या स्थिरतेला हानी पोहोचू लागली. आमच्याकडे एक अतिशय प्रगत उपयोजन प्रणाली होती ज्यामध्ये आम्ही बराच वेळ आणि मेहनत गुंतवली. आम्हाला फक्त आमच्या उपयोजन प्रक्रियेची पुनर्बांधणी आणि सुधारणा करायची होती. आम्ही बर्‍यापैकी मोठ्या कंपनीत वाढलो आहोत, ज्याच्या विकासाचा वापर अखंडित संप्रेषणे आयोजित करण्यासाठी आणि महत्त्वाच्या समस्या सोडवण्यासाठी जगभरात केला जातो. म्हणून, विश्वासार्हता आमच्या लक्ष केंद्रीत झाली.

आम्हाला नवीन स्लॅक रिलीझ तैनात करण्याची प्रक्रिया अधिक सुरक्षित करणे आवश्यक आहे. या गरजेमुळे आम्हाला आमची तैनाती प्रणाली सुधारली. खरं तर, आम्ही वर या सुधारित प्रणालीची चर्चा केली. प्रणालीच्या खोलात, आम्ही वेगवान आणि अणु उपयोजन तंत्रज्ञान वापरणे सुरू ठेवतो. तैनात करण्याची पद्धत बदलली आहे. आमची नवीन प्रणाली वेगवेगळ्या स्तरांवर, वेगवेगळ्या वातावरणात हळूहळू नवीन कोड तैनात करण्यासाठी डिझाइन केलेली आहे. आम्ही आता पूर्वीपेक्षा अधिक प्रगत समर्थन साधने आणि सिस्टम मॉनिटरिंग साधने वापरतो. हे आम्हाला अंतिम वापरकर्त्यापर्यंत पोहोचण्याची संधी मिळण्यापूर्वी त्रुटी पकडण्याची आणि दुरुस्त करण्याची क्षमता देते.

पण आम्ही तिथे थांबणार नाही आहोत. अधिक प्रगत सहाय्यक साधने आणि कार्य ऑटोमेशन साधने वापरून आम्ही या प्रणालीमध्ये सतत सुधारणा करत आहोत.

प्रिय वाचक! तुम्ही जिथे काम करता तिथे नवीन प्रोजेक्ट रिलीझ तैनात करण्याची प्रक्रिया कशी कार्य करते?

स्त्रोत: www.habr.com