Восстановление миграции Laravel в производственной среде

Question

Привет всем

Я постараюсь объяснить свою проблему настолько ясно, насколько это возможно, не стесняйтесь спрашивать меня более точно, если вы не поняли, что я имел в виду, и простите мои ошибки, английский немой родной язык.

---

Моя цель

Я хочу снова начать использовать миграции, потому что мне нужно создать новую таблицу, после года, когда разработчики моей компании обошли их, создав /удаление / обновление таблиц непосредственно из phpmyadmin.

---

Вещи, которые вам необходимо знать

Последняя миграция была год назад, но с тех пор многие таблицы были созданы без миграций.

---

Почему мне нужна ваша помощь

Я хотел бы знать, как лучше всего начать снова использовать миграцию без потери данных или таблиц, потому что я 'м работаю на среде производства.Каков наилучший способ сделать это?Сохранение миграций, которые уже существуют, и игнорирование созданных таблиц?Удалить все файлы миграции и удалить все строки в таблице миграции?

Если я удалю все файлы миграции и урежу таблицу миграции, php artisan migrate окажет какое-либо влияние на существующую схему?

Какая лучшая практика?Должен ли я воссоздать все миграции всех таблиц моей схемы?Или я должен создать только одну миграцию с новой таблицей, которую я хочу создать?

Answer 1

Laravel отслеживает миграции, используя выделенную таблицу, которая записывает, когда они были применены. Когда запускается любая миграция, она вставляет новую запись в таблицу, и если вы откатываете миграцию, соответствующая запись удаляется. Поэтому вы можете предотвратить запуск нежелательных миграций, добавив их в эту таблицу.

Мой совет будет следующим:

• Создание отсутствующих миграций
• Запустите их на своей локальной копии, чтобы получить базу данных в требуемом состоянии там
• Экспорт таблицы миграции
• Импорт в производственную базу данных
• Если у вас есть какие-либо дополнительные миграции, которые вы хотите запустить после локальных, запустите их в рабочей среде

Я определенно был бы осторожен, чтобы заранее выполнить пробный прогон - возможно, после экспорта миграций, импортируйте производственную базу данных в локальную копию, затем импортируйте миграции и проверьте ее там.

Я также был бы склонен предпринять шаги, чтобы запретить людям вносить изменения непосредственно в производственную базу данных - это очень опасный шаг, который позволяет избежать подотчетности и затрудняет локальное тестирование вашего приложения. Возможно, заблокируйте PHPMyAdmin.

Answer 2

Вы можете начать с нуля, удалив все миграции и обрезав таблицу миграций.

Затем посмотрите на этот пост , чтобы воссоздать все миграции для вашей текущей схемы базы данных.

Answer 3

В большинстве случаев в этих случаях я пытаюсь синхронизировать миграции с моей таблицей, чтобы не потерять текущие данные, которые есть в базе данных, и я знаю, что мои миграции обновлены. Итак, я из первой таблицы, что бы вы ни добавили в свою таблицу вручную, вы должны добавить это и в свою миграцию. В этом случае в будущем, если вам нужно создать усечение базы данных или что-то еще, вы знаете, что ваши миграции уже обновлены. Если честно, лучшая практика состоит в том, чтобы вносить изменения в свою миграцию не в базу данных, чтобы вы не сделали этого наилучшим образом. это лучшая практика, которую можно сделать даже в вашем случае, поэтому вы должны выполнить миграцию в свой проект следующим образом:

php artisan make:migration added_photo_to_user_table --table=users

и затем в вашей миграции:

 public function up()
{
    Schema::create('users', function (Blueprint $table) {
        $table->text('photo')->nullable;

    });
}

тогда вы должны запустить команду

php artisan migrate

но в вашем случае, поскольку вы добавили поля в базу данных, вам не нужно запускать последнюю команду, вам просто нужно выполнить миграцию, поэтому в будущем, если вы захотите обновить базу данных, вы сделаете это как лучший метод и вы не встретите потерянные данные.