പ്രൊഡക്ഷനെ തകരാറിലാക്കാത്ത മൈഗ്രേഷനുകൾ

ഒരു മൈഗ്രേഷൻ നിങ്ങളുടെ മെഷീനിൽ കൃത്യമായി പ്രവർത്തിക്കുന്നു. അത് ചെറുതാണെന്ന് തോന്നിയതുകൊണ്ട് വെള്ളിയാഴ്ച വൈകുന്നേരം 6 മണിക്ക് നിങ്ങൾ അത് ഡെപ്ലോയ് ചെയ്യുന്നു. എന്നാൽ ഡെപ്ലോയ്മെന്റ് അവിടെ തടസ്സപ്പെടുന്നു. അല്ലെങ്കിൽ അതിലും മോശമായി, 8 ദശലക്ഷം വരികളുള്ള ഒരു ടേബിൾ 40 സെക്കൻഡ് ലോക്ക് ആകുകയും നിങ്ങളുടെ സൈറ്റ് ക്രാഷ് ആകുകയും ചെയ്യുന്നു.

പ്രൊഡക്ഷനിൽ മൈഗ്രേഷനുകൾ വ്യത്യസ്തമായി പെരുമാറുന്നു. ലോക്കൽ ഡാറ്റാബേസുകൾ ശൂന്യവും വേഗതയുള്ളതുമാണ്. എന്നാൽ പ്രൊഡക്ഷൻ ഡാറ്റാബേസുകളിൽ യഥാർത്ഥ ഡാറ്റയും സജീവ ഉപയോക്താക്കളും ഉണ്ട്.

പ്രൊഡക്ഷൻ ദുരന്തങ്ങൾ ഒഴിവാക്കാൻ ഈ നിയമങ്ങൾ പാലിക്കുക.

• എപ്പോഴും പ്രവർത്തിക്കുന്ന ഒരു down മെത്തേഡ് എഴുതുക ഓരോ മൈഗ്രേഷനും ഒരു up, ഒരു down ഫംഗ്ഷൻ ആവശ്യമാണ്. down ഫംഗ്ഷൻ up ഫംഗ്ഷനെ കൃത്യമായി റിവേഴ്സ് ചെയ്യണം. നിങ്ങൾക്ക് ഒരു റോൾബാക്ക് (rollback) എഴുതാൻ കഴിയില്ലെങ്കിൽ, നിങ്ങളുടെ മൈഗ്രേഷൻ വളരെ സങ്കീർണ്ണമാണ്. പഷ് (push) ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങളുടെ മെഷീനിൽ migrate കഴിഞ്ഞ് migrate:rollback ഉപയോഗിച്ച് അത് പരിശോധിക്കുക.

• പഴയ മൈഗ്രേഷനുകൾ ഒരിക്കലും എഡിറ്റ് ചെയ്യരുത് പഴയ ഒരു മൈഗ്രേഷൻ ഫയലിലെ കോളത്തിന്റെ വലിപ്പം മാറ്റാൻ നിങ്ങൾ ആഗ്രഹിച്ചേക്കാം. ഇത് ചെയ്യരുത്. ലാരവെൽ (Laravel) ആ ഫയൽ സെർവറിൽ വീണ്ടും പ്രവർത്തിപ്പിക്കില്ല. പകരം, ഘടന മാറ്റാൻ പുതിയൊരു മൈഗ്രേഷൻ നിർമ്മിക്കുക. മൈഗ്രേഷൻ എന്നത് മാറ്റങ്ങളുടെ ഒരു ചരിത്രമാണ്. പഴയവ വീണ്ടും എഴുതുന്നതിന് പകരം നിങ്ങൾ പുതിയ അധ്യായങ്ങൾ ചേർക്കുകയാണ് ചെയ്യുന്നത്.

• nullable അല്ലെങ്കിൽ default വാല്യൂകൾ ഉപയോഗിക്കുക നിലവിലുള്ള ഡാറ്റയുള്ള ഒരു ടേബിളിലേക്ക് NOT NULL ആയ ഒരു കോളം ചേർക്കുന്നത് പിശകുകൾക്ക് കാരണമാകും. പഴയ വരികളിൽ എന്താണ് ചേർക്കേണ്ടതെന്ന് ഡാറ്റാബേസിന് അറിയില്ല.

പകരം ഈ രീതികൾ ഉപയോഗിക്കുക: • പുതിയ കോളം nullable ആക്കുക. • ഒരു default വാല്യൂ നൽകുക. • കോളം നിർബന്ധമായും ആവശ്യമാണെങ്കിൽ, അത് മൂന്ന് ഘട്ടങ്ങളിലായി ചെയ്യുക: ആദ്യം അതിനെ nullable ആയി നിർമ്മിക്കുക, ഡാറ്റ പൂരിപ്പിക്കുക, തുടർന്ന് അത് NOT NULL ആയി മാറ്റുക.

• ഡാറ്റാ നഷ്ടം ശാശ്വതമാണ് dropColumn കമാൻഡ് ഡാറ്റ എന്നെന്നേക്കുമായി നീക്കം ചെയ്യുന്നു. ഒരു റോൾബാക്കിന് കോളം വീണ്ടും നിർമ്മിക്കാൻ കഴിയും, പക്ഷേ അതിനുള്ളിലെ ഡാറ്റ നഷ്ടപ്പെട്ടേക്കാം. ഒരു കോളം നീക്കം ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങളുടെ ബാക്കപ്പുകൾ പരിശോധിക്കുക. കൂടുതൽ സുരക്ഷിതമായ മാർഗ്ഗം, ആദ്യം നിങ്ങളുടെ കോഡിൽ നിന്ന് ആ കോളം ഉപയോഗിക്കുന്നത് നിർത്തുക, ഏതാനും ആഴ്ചകൾ കാത്തിരിക്കുക, അതിനുശേഷം ഡാറ്റാബേസിൽ നിന്ന് അത് നീക്കം ചെയ്യുക എന്നതാണ്.

• സ്കീമ മാറ്റങ്ങളെ ഡാറ്റാ അപ്‌ഡേറ്റുകളിൽ നിന്ന് വേർതിരിക്കുക ഒരു മൈഗ്രേഷനുള്ളിൽ User::all() പ്രവർത്തിപ്പിക്കുന്നത് ദശലക്ഷക്കണക്കിന് വരികൾ മെമ്മറിയിലേക്ക് ലോഡ് ചെയ്യാനും നിങ്ങളുടെ ഡെപ്ലോയ്മെന്റ് ക്രാഷ് ആകാനും കാരണമായേക്കാം. മൈഗ്രേഷന്റെ ഭാഗമായി ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടി വന്നാൽ, റെക്കോർഡുകൾ ചെറിയ ബാച്ചുകളായി പ്രോസസ്സ് ചെയ്യാൻ chunkById ഉപയോഗിക്കുക.

• പൈപ്പ്‌ലൈനുകളിൽ force ഫ്ലാഗ് ഉപയോഗിക്കുക ലാരവെൽ സ്ഥിരീകരണം (confirmation) ആവശ്യപ്പെട്ടാൽ ഓട്ടോമേറ്റഡ് ഡെപ്ലോയ്മെന്റ് പൈപ്പ്‌ലൈനുകൾ തടസ്സപ്പെടും. നിങ്ങളുടെ ഡെപ്ലോയ്മെന്റ് സ്ക്രിപ്റ്റുകളിൽ ഈ കമാൻഡ് ഉപയോഗിക്കുക: php artisan migrate --force

• ടേബിൾ ലോക്കുകൾ ശ്രദ്ധിക്കുക വലിയൊരു ടേബിളിലെ ഒരു കോളം മാറ്റുന്നതോ ഒരു ഇൻഡക്സ് ചേർക്കുന്നതോ ആ ടേബിളിനെ ലോക്ക് ചെയ്യും. ഇത് സൈറ്റ് പ്രവർത്തനങ്ങൾ തടസ്സപ്പെടാൻ (downtime) കാരണമാകും. വളരെ വലിയ ടേബിളുകൾക്കായി, online schema change ടൂളുകൾ ഉപയോഗിക്കുകയോ അല്ലെങ്കിൽ ട്രാഫിക് കുറഞ്ഞ സമയങ്ങളിൽ മാറ്റങ്ങൾ വരുത്തുകയോ ചെയ്യുക.

പഷ് ചെയ്യുന്നതിന് മുമ്പുള്ള ചെക്ക്‌ലിസ്റ്റ്: • down മെത്തേഡ് പ്രവർത്തിക്കുന്നുണ്ടോ? • ഞാൻ ലോക്കലായി റോൾബാക്ക് പരിശോധിച്ചോ? • പഴയത് എഡിറ്റ് ചെയ്യുന്നതിന് പകരം പുതിയ മൈഗ്രേഷൻ ആണോ ഞാൻ നിർമ്മിക്കുന്നത്? • പുതിയ കോളം nullable ആണോ അതോ അതിന് ഒരു default വാല്യൂ ഉണ്ടോ? • കോളങ്ങൾ നീക്കം ചെയ്യുന്നതിന് മുമ്പ് എന്റെ പക്കൽ ബാക്കപ്പ് ഉണ്ടോ?

Source: https://dev.to/denisgusto1/migrations-que-nao-quebram-em-producao-o-guia-que-ninguem-te-deu-363o