कैसे डार्क डिप्लॉय्स 50ms कोड

जितनी तेजी से विकास की प्रक्रिया है, उतनी ही तेजी से प्रौद्योगिकी कंपनी विकसित हो रही है।

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

इन पाइपलाइनों में आमतौर पर एक संकीर्ण अनुप्रयोग होता है, धीरे-धीरे काम करता है और विश्वसनीय नहीं होता है। डेवलपर्स को पहले उन्हें मैन्युअल रूप से बनाना होगा, और फिर उन्हें प्रबंधित करना होगा, और कंपनियां अक्सर इसके लिए पूरी DevOps टीमों को नियुक्त करती हैं।

विकास की गति इन पाइपलाइनों की गति पर निर्भर करती है। सर्वश्रेष्ठ टीमों के लिए, तैनाती में 5-10 मिनट लगते हैं, लेकिन आमतौर पर इसमें बहुत अधिक समय लगता है, और एक तैनाती में कई घंटे लगते हैं।

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

निरंतर कन्वेयर इतने धीमे क्यों हैं?

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

परिवर्तन कर रहा है

• Git में एक नई शाखा बनाना
• समारोह स्विच के पीछे परिवर्तन करना
• फ़ंक्शन स्विच के साथ और बिना परिवर्तनों को सत्यापित करने के लिए यूनिट परीक्षण

पूल अनुरोध

• वचन देना
• जीथब पर दूरस्थ रिपॉजिटरी में परिवर्तन पोस्ट करना
• पूल अनुरोध
• CI बैकग्राउंड में अपने आप बनता है
• कोड समीक्षा
• कुछ और समीक्षा, यदि आवश्यक हो
• गिट विज़ार्ड के साथ परिवर्तन को मर्ज करें।

सीआई जादूगर पर चलता है

• Npm के माध्यम से सीमा निर्भरता की स्थापना
• HTML + CSS + JS संसाधनों का निर्माण और अनुकूलन
• यूनिट और फ़ंक्शन परीक्षणों के सामने के अंत में चलाएं
• PyPI से Python निर्भरता स्थापित करें
• यूनिट और कार्यात्मक परीक्षणों के बैकएंड में चलाएं
• दोनों सिरों पर एकीकरण परीक्षण
• CDN के लिए दृश्यपटल संसाधन भेजें
• पायथन कार्यक्रम के लिए एक कंटेनर का निर्माण
• एक कंटेनर को रजिस्ट्री में भेजना
• कुबेरनेट्स अद्यतन प्रकट करते हैं

नए के साथ पुराने कोड को बदलना

• कुबेरनेट्स ने एक नए कंटेनर के कई उदाहरण लॉन्च किए
• Kubernetes संचालन बनने के लिए उदाहरणों की प्रतीक्षा कर रहा है
• Kubernetes HTTP लोड बैलेंसर में इंस्टेंस जोड़ता है
• Kubernetes पुराने उदाहरणों के लिए प्रतीक्षा करता है कि उसका उपयोग किया जाए
• Kubernetes पुराने उदाहरणों को रोकता है
• कुबेरनेट्स इन ऑपरेशनों को तब तक दोहराते हैं जब तक कि नए उदाहरण सभी पुराने को बदल न दें

नया फ़ंक्शन स्विच चालू करें

• नया कोड केवल अपने लिए शामिल है, यह सुनिश्चित करने के लिए कि सब कुछ ठीक है
• 10% उपयोगकर्ताओं के लिए नया कोड शामिल है, परिचालन और व्यापार मीट्रिक ट्रैक किए जाते हैं
• 50% उपयोगकर्ताओं के लिए नया कोड शामिल है, परिचालन और व्यापार मीट्रिक ट्रैक किए जाते हैं
• नए कोड को 100% उपयोगकर्ताओं के लिए शामिल किया गया है, परिचालन और व्यावसायिक मीट्रिक ट्रैक किए जाते हैं
• अंत में, आप पुराने कोड को हटाने और स्विच करने के लिए पूरी प्रक्रिया को दोहराते हैं

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

यहां कई घटक हैं, और उनमें से कई आसानी से धीमा हो सकते हैं, दुर्घटना कर सकते हैं, अस्थायी प्रतिस्पर्धा पैदा कर सकते हैं या कार्य प्रणाली को नीचे ला सकते हैं।

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

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

बेशक, यह एक बहुत ही विचारशील पाइपलाइन है। इसे बनाने वाली टीम ने जल्दी से तैनात करने के लिए समय और पैसा लिया। आमतौर पर तैनाती पाइपलाइनें बहुत धीमी और अधिक अविश्वसनीय होती हैं।

अंधेरे में सतत वितरण को लागू करना

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

जेसी फ्रैजेल ने रेक्जाविक में फ्यूचर ऑफ सॉफ्टवेयर डेवलपमेंट कॉन्फ्रेंस में नए शब्द को तैनात किया

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

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

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

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

सुरक्षित तैनाती

संरचित संपादक

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

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

डार्क में प्रत्येक कार्यक्रम का अपना अर्थ है, इसलिए अपूर्ण कोड समाप्त कार्य में हस्तक्षेप नहीं करता है।

संपादन मोड

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

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

समारोह स्विच

अंधेरे में अतिरिक्त जटिलता को दूर करने का एक तरीका एक समाधान के साथ कई समस्याओं को ठीक करना है। फ़ंक्शन स्विच कई अलग-अलग कार्य करते हैं: स्थानीय विकास वातावरण की जगह, गिट शाखाएं, कोड की तैनाती, और निश्चित रूप से, नए कोड की पारंपरिक धीमी और नियंत्रित रिलीज।

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

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

विकास का वातावरण

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

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

शाखाएँ और नियुक्तियाँ

अब नए कोड को सिस्टम में दर्ज करने के कई तरीके हैं: git शाखाओं, परिनियोजन चरण और फ़ंक्शन स्विच। वे वर्कफ़्लो के विभिन्न हिस्सों में एक समस्या को हल करते हैं: git - परिनियोजन से पहले चरणों में, परिनियोजन - पुराने कोड से संक्रमण के समय नए एक में, और फ़ंक्शन स्विच - नए कोड के नियंत्रित रिलीज़ के लिए।

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

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

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

वर्ज़निंग

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

उसी कारणों के लिए, हम प्रकारों का संस्करण कर रहे हैं। हमने पिछले पोस्ट में अपने टाइप सिस्टम के बारे में विस्तार से बात की है।

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

यह पूरी तरह से एक ही बार में सब कुछ तैनात करने की तुलना में अधिक सुरक्षित है, जैसा कि अभी है।

नए पैकेज संस्करण और मानक पुस्तकालय

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

Dict के दो संस्करणों को दिखाने वाले Dark में एक स्वचालित प्रक्रिया के एक हिस्से का स्क्रीनशॉट :: फ़ंक्शन प्राप्त करता है। डिक्ट :: get_v0 टाइप किया गया कोई भी (जिसे हम मना करते हैं), और डिक्ट :: get_v1 प्रकार का विकल्प।

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

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

नए डार्क संस्करण

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

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

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

डेटाबेस माइग्रेशन

सुरक्षित डेटाबेस माइग्रेशन के लिए एक मानक सूत्र है :

• नए और पुराने प्रारूपों का समर्थन करने के लिए कोड फिर से लिखें
• सभी डेटा को एक नए प्रारूप में परिवर्तित करें
• पुराने डेटा एक्सेस को हटा दें

परिणामस्वरूप, डेटाबेस माइग्रेशन में देरी हो रही है और बहुत सारे संसाधनों की आवश्यकता है। और हम पुरानी योजनाओं को जमा कर रहे हैं, क्योंकि यहां तक ​​कि सरल कार्य, जैसे कि तालिका या स्तंभ का नाम सही करना, प्रयास के लायक नहीं हैं।

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

डार्क में डेटा वेयरहाउस की पहुँच संस्करण वाले चर नामों के माध्यम से है। उदाहरण के लिए, उपयोगकर्ता डेटा स्टोर को शुरू में उपयोगकर्ता-वी 0 कहा जाएगा। जब एक अलग प्रकार के साथ एक नया संस्करण बनाया जाता है, तो उपयोगकर्ता-v1 में नाम बदल जाता है। यदि डेटा Users-v0 के माध्यम से सहेजा जाता है, और आप इसे Users-v1 के माध्यम से एक्सेस करते हैं, तो रोल-ओवर फ़ंक्शन लागू होता है। यदि उपयोगकर्ता-v1 के माध्यम से डेटा सहेजा जाता है, और आप इसे उपयोगकर्ता-वी 0 के माध्यम से एक्सेस करते हैं, तो रोलबैक फ़ंक्शन का उपयोग किया जाता है।

पुराने डेटाबेस के लिए फ़ील्ड नामों के साथ डेटाबेस माइग्रेशन स्क्रीन, रोलबैक और रोलबैक अभिव्यक्तियाँ, और माइग्रेशन को सक्षम करने के लिए निर्देश।

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

परीक्षण

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

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

हमें किस चीज से छुटकारा मिला

चूंकि हमारे पास तैनाती नहीं है, लेकिन फ़ंक्शन स्विच हैं, परिनियोजन पाइपलाइन का लगभग 60% ओवरबोर्ड रहता है। हमें Gub शाखाओं या पूल अनुरोधों की आवश्यकता नहीं है, बैकएंड संसाधनों और कंटेनरों के निर्माण, संसाधनों और कंटेनरों को रजिस्ट्रियों या कुबेरनेट्स में तैनाती चरणों को भेजने के लिए।

मानक निरंतर वितरण पाइपलाइन (बाएं) और अंधेरे (दाएं) की निरंतर आपूर्ति की तुलना। डार्क में, डिलीवरी में 6 चरण और एक चक्र होता है, जबकि पारंपरिक संस्करण में 35 चरण और 3 चक्र शामिल होते हैं।

डार्क में, तैनाती में केवल 6 चरण और 1 चक्र होते हैं (कई बार दोहराए जाने वाले चरण), जबकि आधुनिक निरंतर आपूर्ति पाइपलाइन में 35 चरण और 3 चक्र होते हैं। डार्क में, परीक्षण स्वचालित रूप से चलते हैं, और आप इसे देखते भी नहीं हैं; निर्भरता स्वचालित रूप से स्थापित होती है; git या github से संबंधित किसी भी चीज़ की अब आवश्यकता नहीं है; डॉकटर कंटेनरों को इकट्ठा करना, परीक्षण करना और भेजना आवश्यक नहीं है; कुबेरनेट्स की तैनाती की अब आवश्यकता नहीं है।

यहां तक ​​कि डार्क में शेष चरण आसान हो गए हैं। चूंकि फ़ंक्शन स्विच को एक क्रिया में नियंत्रित किया जा सकता है, इसलिए आपको पुराने कोड को निकालने के लिए दूसरी बार पूरी तैनाती पाइपलाइन से नहीं गुजरना होगा।

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

मैं HackerNews पर इस बारे में सवालों के जवाब देता हूं।

डार्क डिवाइस के बारे में अधिक जानने के लिए, डार्क आर्टिकल पढ़ें, ट्विटर पर हमें (या मुझे ) फॉलो करें , या बीटा संस्करण के लिए साइन अप करें और निम्नलिखित पोस्ट की सूचना प्राप्त करें । यदि आप सितंबर में स्ट्रेंजलोप में आ रहे हैं, तो हमारे लॉन्च पर आएं ।