Django मॉडल को उत्पादन में बदलने के लिए एक शुरुआती मार्गदर्शिका

पहली बार उत्पादन के लिए एक Django परियोजना को कैसे तैनात किया जाए, इस पर आप इंटरनेट पर कई लेख पा सकते हैं। लेकिन, जब आपकी परियोजना पहले से ही उत्पादन पर है, और परिनियोजन के दौरान, आपको संबंधित प्रणालियों की निरंतरता सुनिश्चित करने की आवश्यकता है, और साथ ही, आपके उत्पाद की निरंतरता को सुनिश्चित करने की आवश्यकता है, तो आपको क्या करना चाहिए?

उत्पादन क्या है?

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

उत्पादन के लिए कई आवश्यकताएं होती हैं। हालांकि, इस लेख में, हम दक्षता और निरंतरता पर ध्यान केंद्रित करेंगे।

दक्षता एक गारंटी है कि उत्पाद वही करेगा जो उसे करना चाहिए।

इस उत्पाद का उपयोग करते समय निरंतरता कुशल कार्य की गारंटी है।

यही है, अगर एक लॉगिन प्रयास हमेशा एक त्रुटि देता है, तो यह दक्षता की कमी है। लेकिन, यदि किसी उपयोगकर्ता को शायद ही ऐसी कोई त्रुटि मिलती है, तो यह निरंतरता का उल्लंघन है।

आरंभिक डेटा

आर्किटेक्चर के आधार पर उत्पादन पर कई कंटेनर, वर्चुअल मशीन या सर्वर का उपयोग किया जाता है।

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

उत्पादन योजना

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

कोड और डेटाबेस में एक साथ परिवर्तन

उदाहरण के लिए, आइए हम केवल कोड और डेटाबेस में परिवर्तन पर विचार करें।

कोड में किए जा सकने वाले परिवर्तन ताकि यह एक डेटाबेस को प्रभावित करे और इसके विपरीत:

1. तालिका जोड़ें/निकालें।
2. कॉलम जोड़ें/निकालें।
3. किसी स्तंभ या तालिका का नाम बदलें।
4. कॉलम प्रकार बदलें।
5. स्तंभ की विशेषताएँ (अनुक्रमणिका) बदलें (NULL, अद्वितीय, डिफ़ॉल्ट)।

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

विस्तृत उदाहरण

यदि आपको विकास के माहौल में स्थानीय रूप से किसी एप्लिकेशन में मॉडल (तालिका) जोड़ने की आवश्यकता है, तो आपको निम्न कार्य करना चाहिए:

1. Django मॉडल में एक वर्ग जोड़ें।
2. कमांड को कॉल करें: python manage.py makemigrations ।
3. फिर: python manage.py migrate करें।
4. और उसके बाद ही एप्लिकेशन को पुनरारंभ करें।

लेकिन उत्पादन पर, आपके आवेदन, गिट और माइग्रेशन चलाने के लिए एक अलग प्रक्रिया के कई उदाहरण हैं।

आपके पास अक्सर उत्पाद तक सीधी पहुंच नहीं होती है। और यह अच्छा है। उदाहरण के लिए, प्रवाह इस तरह दिख सकता है।

ऐसी योजना में सबसे पहले पलायन चलाया जाता है। फिर, एक-एक करके पॉड्स को फिर से शुरू किया जाता है।

ऐसी वास्तुकला में, हमेशा ऐसी स्थिति हो सकती है जब पलायन किया गया हो, लेकिन उत्पादन पर कोड नहीं बदला है।

इसके बाद पोल बदले जा रहे हैं। कुछ उदाहरणों में नया कोड होता है, कुछ में पुराना होता है।

इसके अलावा, यदि आप पॉड प्रतिस्थापन पूरा होने पर माइग्रेशन करते हैं, तो एक अलग स्थिति होगी: सर्वर पर कोड अपडेट किया गया है, लेकिन डेटाबेस नहीं है।

दोनों स्थितियों में कुछ समय की अवधि होती है जब डेटाबेस और कोड असंगत होते हैं।

सौभाग्य से, Django स्थिरता की जाँच नहीं करता है। हालांकि, आवश्यक तत्वों की अनुपस्थिति के परिणामस्वरूप अपवाद होते हैं।

वो हैं:

1. कोड में मॉडल में एक वर्ग की उपस्थिति, लेकिन डेटाबेस में इसकी अनुपस्थिति
2. कोड में कक्षा में एक फ़ील्ड की उपस्थिति, लेकिन डेटाबेस में इसकी अनुपस्थिति
3. कोड और डेटाबेस में टेबल और कॉलम के अलग-अलग नाम
4. कोड और तालिका में विभिन्न प्रकार के डेटा
5. डिफ़ॉल्ट मान, NULL और अन्य अंतर, यदि उनका उपयोग करने की बात आती है
6. अन्य अंतर जो कोड से एक्सेस किए जाने पर डेटाबेस की अपेक्षा नहीं करता है

समाधान

जब इसका अर्थ हो तो कोड बदलने से पहले माइग्रेशन करने की आवश्यकता होती है:

1. तालिका जोड़ना
2. एक कॉलम जोड़ना
3. फ़ील्ड में NULL डालने की क्षमता जोड़ना

जब इसका अर्थ हो तो कोड बदलने के बाद माइग्रेशन करने की आवश्यकता होती है:

1. एक मेज निकाल रहा है
2. एक कॉलम हटाना
3. फ़ील्ड में NULL डालने की क्षमता को हटाना

नामकरण कई चरणों में किया जाता है:

1. एक नया क्षेत्र या तालिका बनाना
2. एक नए और पुराने क्षेत्र या तालिका का तुल्यकालन जोड़ना
3. जरूरत पड़ने पर ऐतिहासिक डेटा की नकल करना
4. एक नए क्षेत्र या टेबल का उपयोग शुरू करना
5. तुल्यकालन के साथ एक पुराने क्षेत्र या तालिका को हटाना

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

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

हालांकि, परिवर्तन करते समय, आप डेटाबेस को अनुरोध भेजते समय कोड की अपेक्षाओं के द्वारा हमेशा निर्देशित हो सकते हैं। मानक मामलों के अलावा, ऐसे कई अपवाद और बाधाएँ हो सकती हैं जिनके लिए रास्ता खोजने के लिए सरलता की आवश्यकता होती है।

आने वाले लेखों में, मैं यहां वर्णित कुछ मामलों का विस्तार से वर्णन करूंगा।