Проблемы с промежуточной базой данных
Предположим, что есть 3 базы данных для
- Производство
- Постановка
- Dev
Насколько мне известно, промежуточная база данных должна быть синхронизирована с производственной базой данных. Но,
Когда мы разрабатываем, мы можем делать все, что захотим, с базой данных Dev и изменять схему. А теперь проблема с курицей и яйцом.
Для тестирования в промежуточном режиме схему базы данных Постановка необходимо изменить в соответствии с изменениями, внесенными в базу данных Dev. Но промежуточная база данных должна быть синхронизирована с производственной.
Как вы, ребята, решаете эту проблему?
Ответы 5
Постановка должна быть синхронизирована с производственной только до момента, когда вы развертываете новые изменения.
Это или создайте четвертую среду под названием Test, в которой проверяются новые обновления. Мы называем нашу UAT / Test, и обычно это вторая база данных на промежуточном сервере.
Точная методология будет зависеть от того, как вы синхронизируете вещи. Вы действительно используете репликацию? Или просто бэкап / восстановление Prod to Stage?
Пока не было принято никаких решений, но я думал об использовании доставки журналов SQL Server для синхронизации промежуточной базы данных с производственной базой данных. Репликация, скорее всего, НЕ используется.
«Промежуточная база данных должна быть синхронизирована с производственной» Неправда.
Схема производства («дизайн») синхронизирована со схемой подготовки. Сначала идет постановка, затем следует производство.
Иногда люди переносят производственные данные на промежуточную стадию, чтобы помочь в тестировании, но это может быть опасно, в зависимости от вашей отрасли.
Постановка "Чистая".
Производство строится на промежуточном этапе путем помещения реальных данных в чистую промежуточную схему.
Некоторые люди имеют две базы данных.
Сегодня №1 - продакшн, №2 - постановка.
Завтра планируем внести изменения в схему. Обновляем №2 до нового дизайна. Затем мы перемещаем данные из №1 в №2.
Затем, когда мы закончили перенос данных, мы переключаем прикладное программное обеспечение на использование №2 в качестве производственного.
Мы работаем с №2 в качестве производства, пока не пришло время для следующих изменений.
Мы используем нашу промежуточную базу данных только для тестирования нашего механизма развертывания. Соответствует производству.
Мы вносим свои изменения в разработку и периодически разворачиваем их в QA. Когда мы готовы перейти к производству, мы объединяем все изменения в один пакет выпуска. Этот пакет выпуска сначала тестируется на стадии подготовки, а затем, если нет проблем с развертыванием, он отправляется в производство.
Если вы можете позволить себе добавить тестовую среду, возможно, вы захотите это рассмотреть.
В противном случае вам в основном нужно проводить тестирование в среде разработки. до момента, когда вы достаточно уверены в выпуске, чтобы вносить изменения в схему в промежуточном окружении. Делайте частые резервные копии и используйте хорошую процедуру отката, чтобы, если что-то пойдет не так, когда вы подталкиваете изменения схемы к промежуточной стадии, вы всегда можете выполнить откат.
Также хороший инструмент для сравнения схемы базы данных - SqlCompare. Вы должны всегда использовать что-то подобное, прежде чем вносить изменения в схему.
+1 для SqlCompare. Почувствуйте, что SQL Delta - отличный инструмент для этой цели - тоже заслуживает упоминания.
Вам необходимо записать все изменения в базу данных разработчиков в виде сценариев миграции SQL, которые запускаются в определенном порядке. Не меняйте структуру базы данных, если это не указано в сценарии. Не обновляйте, не вставляйте и не удаляйте какие-либо строки, если это не находится в сценарии.
В идеале иметь способ отслеживать, какие сценарии были запущены для любой версии базы данных, которую вы найдете.
Затем вы можете обновить этап следующим образом.
- Дамп производственной базы
- Заполнить базу данных этапов производственным дампом
- Выполнить миграции поэтапно
- Проверка работоспособности миграции (модульные тесты, ручные проверки)
Как только все заработает ...
- Дамп базы данных prod с помощью команды mysqldump (поскольку она могла быть изменена) с сохранением резервной копии на сервере
- Запускайте миграции на продукте
- Тестовая миграция сработала на прод
- Пейте пиво (просматривая журналы ошибок)
+1 Очевидно, что когда вы развертываете свои изменения, будет некоторый период времени, когда производство и постановка должны выйти из синхронизации. Если, конечно, вы не развернете свои изменения в обоих одновременно, что полностью лишает смысла создание промежуточной среды.