Я думаю, это сводится к тому, нужно ли вам на самом деле выполнять всю эту работу, как я работаю с SSDT, - это определить, что я хочу, чтобы текущая версия выглядела в коде схемы +, и любые сценарии обновления, которые мне нужны в файлы после развертывания в виде перезапускаемых сценариев (idempotent).
Если db находится на версии 1 или 100, они по-прежнему получают один и тот же пост-развертывающий скрипт, но либо скрипт проверяет данные, либо флаг, который хранится в базе данных, чтобы сказать, что данный скрипт уже запущен - это должен быть довольно прост в настройке, но зависит от ваших точных требований.
Чтобы сохранить это управление, рекомендуется знать, когда отдельные сценарии перешли во все ваши среды, а затем удалите их, чтобы на самом деле у вас были только сценарии после развертывания, которые вам когда-либо понадобятся.
Это, как говорится, иногда есть определенные ограничения, которые, как правило:
- Клиенты управления базами данных, так что вы не можете быть уверены, что у них есть версия
- регулирования (мнимые или иным образом) требования требуют обновления/откат сценарии
во-первых, выяснить, как установить в камне ваши требования, цель SSDT, чтобы не придется беспокоиться о модернизации скриптов/даунгрейд (конечно, для схемы) - вопросы, которые я бы спросить, являются:
- достаточно ли сделать резервную копию или моментальный снимок перед развертыванием?
- Можете ли вы оставить сценарии понижения и написать их, если вам когда-нибудь понадобится?
- как часто Откат сценарии когда-либо использовали (и зная, первые два могут помочь здесь)
Если у вас есть хороший набор тестов, автоматизированный конвейер развертывания (даже если он имеет ручной шаг DBA в в какой-то момент), то эти проблемы становятся менее важными и со временем, когда все учатся доверять процессу, могут стать значительно быстрее и проще развертывать изменения.
Каковы ваши ограничения?
Ed
Thanks Ed. «Если db находится на версии 1 или 100, они все равно получают один и тот же пост-развертывающий скрипт, но либо скрипт проверяет данные, либо флаг, который хранится в базе данных, чтобы сказать, что определенный скрипт уже запущен - это должно быть довольно легко настраивается, но зависит от ваших точных требований ». это именно то, что я хочу, но не знаю, что такое лучшая практика. Из вашего объяснения, похоже, мне нужно управлять 1 проектом SSDT и выполнять управление версиями кода внутри сценариев pre/post с учетом текущей версии на целевом db. Можете ли вы поделиться мне кратким примером того, как вы это сделали? – beewest
Конечно, проще всего использовать таблицу «version_deployed», которая содержит идентификатор версии и дату, чтобы ваш сценарий обновления становился (если не существует (выберите * из версий_deployed, где name = id) начните blah insert into version_deployed id) - если вы поместите каждое обновление версии в свой собственный скрипт и ссылаетесь на него из сценария после развертывания, используя «: r filename», тогда проще просмотреть, что у вас есть в explorer - это также отслеживает, когда все было развернуто, что приятно для некоторых сценарии. –
Дано 3 версии: v1 (pre1, schema1, post1), v2, v3. Ваше решение (pre1 pre2 pre3, schema, post1 post2 post3). Он работает хорошо Если прес не зависит от предыдущего сообщения. Однако если post1 вставляет новую строку, pre2 изменяет, то post2 перемещается где-то в другом месте. Есть предположения? – beewest