💨 👩‍💼 👨🏻 Reddit में कोड परिनियोजन दृष्टिकोण का विकास ⬇️ 🅰️ 💮

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

"समय पर एक अच्छी दिशा में भेजने में सक्षम होने के लिए अपने विकास की दिशा का पालन करना महत्वपूर्ण है।"

रेडिट टीम लगातार कोड तैनात कर रही है। विकास टीम के सभी सदस्य नियमित रूप से उस कोड को लिखते हैं जो लेखक द्वारा स्वयं फिर से जांचा जाता है, और बाहर से परीक्षण किया जाता है, ताकि वह फिर "उत्पादन" पर जा सके। हर हफ्ते हम कम से कम 200 "तैनाती" करते हैं, जिनमें से प्रत्येक में आमतौर पर कुल 10 मिनट से कम समय लगता है।

यह सब प्रदान करने वाली प्रणाली वर्षों में विकसित हुई है। आइए देखें कि इस बार इसमें क्या बदलाव आया है, और क्या अपरिवर्तित रहा है।

कहानी की शुरुआत: स्थिर और आवर्ती तैनाती (2007-2010)

आज हमने जो पूरी व्यवस्था की है वह एक बीज से बढ़ी है - एक पर्ल स्क्रिप्ट जिसे पुश कहा जाता है। यह बहुत पहले लिखा गया था, रेडिट के लिए बहुत अलग समय में। हमारी पूरी तकनीकी टीम उस समय इतनी छोटी थी कि चुपचाप एक छोटे से "मीटिंग रूम" में फिट हो गई । हमने तब AWS का उपयोग नहीं किया था। साइट ने सर्वर की सीमित संख्या पर काम किया, और किसी भी अतिरिक्त क्षमता को मैन्युअल रूप से जोड़ना पड़ा। सब कुछ एक बड़े, अखंड पाइथन एप्लिकेशन पर काम करता है जिसे आर 2 कहा जाता है।

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

लक्ष्य सर्वर की सूची मैन्युअल रूप से पुश टूल कोड में लिखी गई थी, और परिनियोजन प्रक्रिया एक अखंड प्रणाली के साथ काम करती थी। उपकरण सर्वर की सूची के माध्यम से चला गया, SSH के ऊपर चला गया, कमांड के पूर्वनिर्धारित अनुक्रमों में से एक को चलाया, जो कि git का उपयोग करके कोड की वर्तमान प्रतिलिपि को अपडेट किया और सभी एप्लिकेशन प्रक्रियाओं को फिर से शुरू किया। प्रक्रिया का सार (कोड एक सामान्य समझ के लिए बहुत सरल है):

#            `make -C /home/reddit/reddit static` `rsync /home/reddit/reddit/static public:/var/www/` #    app-        #    ,   foreach $h (@hostlist) { `git push $h:/home/reddit/reddit master` `ssh $h make -C /home/reddit/reddit` `ssh $h /bin/restart-reddit.sh` }

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

इस तरह के तंत्र ने तैनाती के दौरान स्थिरता और नियंत्रण सुनिश्चित करने का अच्छा काम किया। उपकरण ने बहुत तेजी से काम किया। बात सही निकली।

हमारी रेजिमेंट आ गई (2011)

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

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

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

आमतौर पर एक समय में कई सर्वरों को जोड़कर पूल की शक्ति को बढ़ाया जाता था। नतीजतन, सूची के माध्यम से क्रमिक रूप से चलने वाले एक ही पूल में सर्वर के एक पूरे समूह में परिवर्तन को रोल करने में कामयाब रहे, दूसरों को प्रभावित किए बिना, अर्थात, पूल द्वारा कोई विविधता नहीं थी।

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

रीसायकल इंस्ट्रूमेंट डिप्लॉयमेंट (2012)

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

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

क्रमिक पुनरारंभ की समस्या को हल करने के लिए, हमने तैनाती से पहले मेजबानों की सूची में फेरबदल किया। घटते जोखिम को कम किया और प्रक्रिया को गति देने की अनुमति दी।

मूल संस्करण ने हर बार सूची को बेतरतीब ढंग से बदल दिया, हालांकि, इससे जल्दी से वापस रोल करना मुश्किल हो गया, क्योंकि हर बार सर्वर के पहले समूह की सूची अलग थी। इसलिए, हमने मिश्रण को ठीक किया: यह अब एक निश्चित क्रम उत्पन्न करता है जिसे रोलबैक के बाद दोहराया तैनाती के दौरान इस्तेमाल किया जा सकता है।

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

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

 sudo /opt/reddit/deploy.py fetch reddit sudo /opt/reddit/deploy.py deploy reddit f3bbbd66a6 sudo /opt/reddit/deploy.py fetch-names sudo /opt/reddit/deploy.py restart all

विशेष रूप से ध्यान देने योग्य है-नामों के नाम: यह निर्देश r2 के लिए अद्वितीय है।

ऑटोस्कोलिंग (2013)

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

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

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

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

इसलिए इसने कुछ समय के लिए काम किया।

बहुत सारे सर्वर (2014)

समय के साथ, सर्विस पीक ट्रैफिक के लिए आवश्यक सर्वरों की संख्या बढ़ती गई। इस तथ्य के कारण तैनाती को अधिक से अधिक समय की आवश्यकता थी। सबसे खराब स्थिति में, एक सामान्य तैनाती में लगभग एक घंटा लगा - एक खराब परिणाम।

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

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

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

बहुत सारे लोग (2015)

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

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

कई (दो) सेवाएं (2015 भी)

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

25 सेवाएं (2016)

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

एयरबैग (2017)

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

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

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

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

पीछे मुड़कर देखा

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

भविष्य

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

Reddit में कोड परिनियोजन दृष्टिकोण का विकास