Проблемы с промежуточной базой данных

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

Это или создайте четвертую среду под названием Test, в которой проверяются новые обновления. Мы называем нашу UAT / Test, и это обычно вторая база данных на промежуточном сервере.

Точная методология будет зависеть от того, как вы синхронизируете вещи. Вы действительно используете репликацию? Или просто бэкап / восстановление Prod to Stage?

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

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

Затем вы можете обновить этап следующим образом.

• Дамп производственной базы
• Заполнить базу данных этапов производственным дампом
• Выполнить миграции поэтапно
• Проверка работоспособности миграции (модульные тесты, ручные проверки)

Как только все заработает ...

• Дамп базы данных prod с помощью команды mysqldump (поскольку она могла быть изменена) с сохранением резервной копии на сервере
• Запускайте миграции на продукте
• Тестовая миграция сработала на прод
• Пейте пиво (просматривая журналы ошибок)

«Промежуточная база данных должна быть синхронизирована с производственной» Неправда.

Схема производства («дизайн») синхронизирована со схемой подготовки. Сначала идет постановка, затем следует производство.

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

Постановка "Чистая".

Производство строится на промежуточном этапе путем помещения реальных данных в чистую промежуточную схему.

Некоторые люди используют две базы данных.

Сегодня №1 - продакшн, №2 - постановка.

Завтра планируем внести изменения в схему. Модернизируем №2 до нового дизайна. Затем мы перемещаем данные из №1 в №2.

Затем, когда мы закончили перенос данных, мы переключаем прикладное программное обеспечение на использование №2 в качестве производственного.

Мы работаем с №2 в качестве производства, пока не придет время для следующих изменений.

Мы используем нашу промежуточную базу данных только для тестирования нашего механизма развертывания. Соответствует производству.

Мы вносим свои изменения в разработку и периодически разворачиваем их в QA. Когда мы готовы перейти к производству, мы объединяем все изменения в один пакет выпуска. Этот пакет выпуска сначала тестируется на этапе подготовки, а затем, если нет проблем с развертыванием, он отправляется в производство.

Если вы можете позволить себе добавить тестовую среду, возможно, вы захотите это рассмотреть.

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

Кроме того, хорошим инструментом для сравнения схемы базы данных является SqlCompare. Вы должны всегда использовать что-то подобное, прежде чем вносить изменения в схему.