Рекомендуемый рабочий процесс Redgate SQL Source Control для баз данных dev-test-live

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

Есть несколько предложений по вашим вопросам (на мне шляпа Red Gate)

• Обычно не рекомендуется подключать SQL Source Control к вашей реальной среде. Он опрашивает для поиска изменений, и это может быть не то, что вам нужно в вашей действующей системе. Вместо этого рекомендуется использовать SQL Compare для однократного развертывания в системах UAT/Production. В качестве альтернативы вас может заинтересовать продукт Red Gate Deployment Manager.

• Вы спрашивали выше о режиме Shared/Dedicated в тесте. Не имеет значения, используете ли вы общую базу данных для своих разработчиков в ветке разработки, а затем выделенную модель в ветке тестирования. Если единственные изменения в тестовой базе данных происходят из одного места (например, ваши развертывания git), то, вероятно, лучше запускать эту базу данных в выделенном режиме.

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

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

Если у вас есть какая-то система сборки, связанная с вашим репозиторием, вы, вероятно, могли бы автоматизировать последнюю часть, где она развертывается для тестирования, с использованием Пакет SQL Automation — например, что-то вроде TeamCity может быть запущено вами при выполнении слияния, а затем автоматически обновлять Test, чтобы вам не приходилось делать это вручную Это.

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

Red Gate не считает это лучшей практикой (вот почему). Они предпочитают, чтобы вы также приобрели SQL Compare.

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

Я предпочитаю это:

• Developers connect using Shared model
  • then you can see who has modified each table/proc/etc.
• We also keep a working folder on the dev server using shared model.
  • This allows us to use get-latest to update dev with patches from live.

Было бы проще, если бы выпущена функция смешанной модели (голосование здесь).