مهاجرت‌هایی که باعث از کار افتادن محیط عملیاتی (Production) نمی‌شوند

یک migration روی سیستم شما بدون مشکل اجرا می‌شود. شما آن را جمعه ساعت ۶ عصر مستقر (deploy) می‌کنید چون به نظر کوچک می‌آید. سپس فرآیند استقرار متوقف می‌شود. یا بدتر از آن، جدولی با ۸ میلیون ردیف برای ۴۰ ثانیه قفل می‌شود و سایت شما از کار می‌افتد.

رفتار migrationها در محیط production متفاوت است. پایگاه‌های داده محلی خالی و سریع هستند، اما پایگاه‌های داده production دارای داده‌های واقعی و کاربران فعال هستند.

برای جلوگیری از فجایع در محیط production، این قوانین را دنبال کنید.

  • همیشه یک متد down کارآمد بنویسید هر migration به یک تابع up و یک تابع down نیاز دارد. تابع down باید دقیقاً عملکرد تابع up را معکوس کند. اگر نمی‌توانید یک rollback بنویسید، migration شما بیش از حد پیچیده است. قبل از push کردن، آن را روی سیستم خود با دستور migrate و سپس migrate:rollback تست کنید.

  • هرگز migrationهای قدیمی را ویرایش نکنید ممکن است بخواهید اندازه یک ستون را در یک فایل migration قدیمی اصلاح کنید. این کار را انجام ندهید. Laravel آن فایل را دوباره روی سرور اجرا نخواهد کرد. در عوض، یک migration جدید برای تغییر ساختار ایجاد کنید. migration در واقع تاریخچه‌ای از تغییرات است؛ شما به جای بازنویسی فصل‌های قدیمی، فصل‌های جدید اضافه می‌کنید.

  • از مقادیر nullable یا default استفاده کنید اضافه کردن یک ستون NOT NULL به جدولی که دارای داده‌های موجود است، باعث بروز خطا می‌شود. پایگاه داده نمی‌داند چه چیزی را باید در ردیف‌های قدیمی قرار دهد.

به جای آن از این روش‌ها استفاده کنید: • ستون جدید را nullable کنید. • یک مقدار default تعیین کنید. • اگر ستون حتماً باید اجباری (required) باشد، آن را در سه مرحله انجام دهید: ابتدا آن را به صورت nullable ایجاد کنید، داده‌ها را پر کنید، و سپس آن را به NOT NULL تغییر دهید.

  • از دست رفتن داده‌ها دائمی است دستور dropColumn داده‌ها را برای همیشه حذف می‌کند. یک rollback می‌تواند ستون را دوباره ایجاد کند، اما داده‌های داخل آن از بین رفته است. قبل از حذف یک ستون، بک‌آپ‌های خود را بررسی کنید. یک راه امن‌تر این است که ابتدا استفاده از آن ستون را در کد خود متوقف کنید، چند هفته صبر کنید و سپس آن را از پایگاه داده حذف کنید.

  • تغییرات ساختار (schema) را از به‌روزرسانی داده‌ها جدا کنید اجرای User::all() داخل یک migration می‌تواند میلیون‌ها ردیف را در حافظه بارگذاری کرده و فرآیند استقرار شما را با شکست مواجه کند. اگر مجبور هستید در طول یک migration داده‌ها را به‌روزرسانی کنید، از chunkById برای پردازش رکوردها در دسته‌های کوچک استفاده کنید.

  • در خط لوله‌های (pipelines) استقرار از پرچم force استفاده کنید اگر Laravel برای تأیید نیاز به پاسخ داشته باشد، خط لوله‌های استقرار خودکار متوقف (hang) می‌شوند. در اسکریپت‌های استقرار خود از این دستور استفاده کنید: php artisan migrate --force

  • مراقب قفل شدن جداول (table locks) باشید تغییر یک ستون یا افزودن یک ایندکس (index) روی یک جدول بسیار بزرگ، آن جدول را قفل می‌کند. این کار باعث از کار افتادن سایت (downtime) می‌شود. برای جداول بسیار بزرگ، از ابزارهای تغییر ساختار آنلاین (online schema change tools) استفاده کنید یا تغییرات را در ساعات کم‌ترافیک انجام دهید.

چک‌لیست قبل از push کردن: • آیا متد down کار می‌کند؟ • آیا rollback را به صورت محلی تست کرده‌ام؟ • آیا به جای ویرایش یک migration قدیمی، یک migration جدید ایجاد می‌کنم؟ • آیا ستون جدید nullable است یا مقدار default دارد؟ • آیا قبل از حذف ستون‌ها، بک‌آپ دارم؟

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