Постановка базы данных затруднительно

Question

Предположим, что есть 3 базы данных для

• Производство
• Постановка
• Dev

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

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

Для тестирования в Staging необходимо изменить схему базы данных Staging в соответствии с изменениями, внесенными в базу данных Dev. Но промежуточная база данных должна быть синхронизирована с Production.

Как вы, ребята, справляетесь с этой проблемой?

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

У некоторых людей есть две базы данных.

Сегодня # 1 - производство, # 2 - постановка.

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

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

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