वे माइग्रेशन जो प्रोडक्शन को खराब नहीं करेंगे

एक माइग्रेशन आपकी मशीन पर बिल्कुल सही चलता है। आप इसे शुक्रवार शाम 6 बजे डिप्लॉय करते हैं क्योंकि यह छोटा लगता है। फिर डिप्लॉयमेंट फ्रीज हो जाता है। या इससे भी बुरा, 8 मिलियन rows वाली एक टेबल 40 सेकंड के लिए लॉक हो जाती है और आपकी साइट क्रैश हो जाती है।

प्रोडक्शन में माइग्रेशन का व्यवहार अलग होता है। लोकल डेटाबेस खाली और तेज़ होते हैं। प्रोडक्शन डेटाबेस में वास्तविक डेटा और सक्रिय उपयोगकर्ता होते हैं।

प्रोडक्शन की आपदाओं से बचने के लिए इन नियमों का पालन करें।

• हमेशा एक काम करने वाला down method लिखें हर माइग्रेशन के लिए एक up और एक down फंक्शन की आवश्यकता होती है। down फंक्शन को up फंक्शन को ठीक से रिवर्स करना चाहिए। यदि आप rollback नहीं लिख सकते, तो आपका माइग्रेशन बहुत जटिल है। पुश करने से पहले अपनी मशीन पर migrate और उसके बाद migrate:rollback के साथ इसका परीक्षण करें।

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

• nullable या default values का उपयोग करें मौजूदा डेटा वाली टेबल में NOT NULL कॉलम जोड़ने से त्रुटियां (errors) आती हैं। डेटाबेस को यह नहीं पता होता कि पुरानी rows में क्या भरा जाए।

इसके बजाय इन तरीकों का उपयोग करें: • नए कॉलम को nullable बनाएँ। • एक default value सेट करें। • यदि कॉलम का होना अनिवार्य (required) है, तो इसे तीन चरणों में करें: इसे nullable के रूप में बनाएँ, डेटा भरें, और फिर इसे NOT NULL में बदल दें।

• डेटा का नुकसान स्थायी होता है dropColumn कमांड डेटा को हमेशा के लिए मिटा देता है। एक rollback कॉलम को फिर से बना सकता है, लेकिन उसके अंदर का डेटा चला जाता है। किसी कॉलम को हटाने (drop) से पहले, अपने बैकअप की जांच कर लें। एक सुरक्षित तरीका यह है कि पहले अपने कोड में उस कॉलम का उपयोग करना बंद कर दें, कुछ सप्ताह प्रतीक्षा करें, और फिर उसे डेटाबेस से हटा दें।

• स्कीमा परिवर्तनों को डेटा अपडेट से अलग रखें माइग्रेशन के अंदर User::all() चलाने से लाखों rows मेमोरी में लोड हो सकती हैं और आपका डिप्लॉयमेंट क्रैश हो सकता है। यदि आपको माइग्रेशन के दौरान डेटा अपडेट करना ही है, तो रिकॉर्ड्स को छोटे बैचों में प्रोसेस करने के लिए chunkById का उपयोग करें।

• पाइपलाइन्स में force flag का उपयोग करें यदि Laravel पुष्टि (confirmation) मांगता है, तो ऑटोमेटेड डिप्लॉयमेंट पाइपलाइन्स हैंग हो जाएंगी। अपने डिप्लॉयमेंट स्क्रिप्ट में इस कमांड का उपयोग करें: php artisan migrate --force

• टेबल लॉक (table locks) से सावधान रहें किसी विशाल टेबल पर कॉलम बदलना या इंडेक्स जोड़ना उस टेबल को लॉक कर देता है। इससे डाउनटाइम (downtime) होता है। बहुत बड़ी टेबल्स के लिए, ऑनलाइन स्कीमा चेंज टूल्स देखें या कम ट्रैफिक वाले घंटों के दौरान बदलाव करें।

पुश करने से पहले चेकलिस्ट: • क्या down method काम करता है? • क्या मैंने लोकल पर rollback का परीक्षण किया है? • क्या मैं पुरानी माइग्रेशन को एडिट करने के बजाय नई माइग्रेशन बना रहा हूँ? • क्या नया कॉलम nullable है या उसमें कोई default है? • क्या कॉलम हटाने से पहले मेरे पास बैकअप है?

स्रोत: https://dev.to/denisgusto1/migrations-que-nao-quebram-em-producao-o-guia-que-ninguem-te-deu-363o