Как правильно управлять развертыванием базы данных с помощью проектов баз данных SSDT и Visual Studio 2012?

Я нахожусь на стадии исследования, пытаясь принять 2012 Database Projects на существующий небольшой проект. Я разработчик С#, а не администратор базы данных, поэтому я не очень хорошо разбираюсь в лучших практиках. Я искал google и stackoverflow в течение нескольких часов, но я до сих пор не знаю, как правильно обрабатывать некоторые ключевые сценарии развертывания.

1) В течение нескольких циклов разработки, как мне управлять несколькими версиями моей базы данных? Если у меня есть клиент на v3 моей базы данных, и я хочу обновить их до версии v8, как мне это сделать? В настоящее время мы используем сценарии миграции схем и данных вручную для каждой версии нашего продукта. Нужно ли все еще делать это отдельно или есть что-то в новой парадигме, которая поддерживает или заменяет это?

2) Если схема изменяется таким образом, что требуется перемещение данных, каков наилучший способ справиться с этим? Я предполагаю, что некоторые работы в Pre-Deployment script сохраняются, а затем Post-Deploy script вернет его в нужное место. Это путь или есть что-то лучше?

3) Любые другие рекомендации или рекомендации о том, как лучше всего работать с этими новыми технологиями, также очень ценятся!

ОБНОВЛЕНИЕ: Мое понимание проблемы немного выросло с тех пор, как я изначально задал этот вопрос, и пока я придумал подходящее решение, это было не совсем то решение, на которое я надеялся. Здесь переписывается моя проблема:

Проблема, с которой я столкнулась, связана с чисто данными. Если у меня есть клиент в версии 1 моего приложения, и я хочу обновить их до версии 5 моего приложения, у меня не было бы проблем с этим, если в их базе данных не было данных. Я бы просто позволил SSDT разумно сравнить схемы и перенести базу данных одним выстрелом. К сожалению, у клиентов есть данные, поэтому это не так просто. Изменения схемы от версии 1 моего приложения до версии 2 до версии 3 (и т.д.) Все данные воздействия. Моя текущая стратегия управления данными требует, чтобы я поддерживал script для каждого обновления версии (от 1 до 2, от 2 до 3 и т.д.). Это мешает мне перейти от версии 1 моего приложения к версии 5, потому что у меня нет миграции данных script, чтобы идти прямо туда. Перспектива создания пользовательских сценариев обновления для каждого клиента или управления сценариями обновления для перехода от каждой версии к каждой большей версии экспоненциально неуправляема. Я надеялся, что существует какая-то стратегия. SSDT позволяет упростить управление передачей данных, возможно, даже так же просто, как и с точки зрения схемы. Мой недавний опыт работы с SSDT не дал мне никакой надежды на такую существующую стратегию, но мне бы хотелось узнать по-другому.

Ответ 1

Я работал над этим сам, и я могу сказать вам это нелегко.

Во-первых, чтобы ответить на ответ JT - вы не можете уволить "версии", даже с декларативной механикой обновления, которую имеет SSDT. SSDT выполняет "довольно приличную" работу (при условии, что вы знаете все переключатели и gotchas) о перемещении любой исходной схемы в любую целевую схему, и это правда, что это не требует проверки как такового, но не знает, как управлять "движение данных" (по крайней мере, не то, что я вижу!). Итак, как и DBProj, вы оставили свои собственные устройства в сценариях Pre/Post. Поскольку сценарии движения данных зависят от известного состояния начальной и конечной схемы, вы не можете избежать управления версиями БД. Поэтому сценарии "движения данных" должны применяться к версии снимка схемы, что означает, что вы не можете произвольно обновлять БД от v1 до v8 и ожидать, что сценарии перемещения файлов v2-v8 будут работать (по-видимому, вы не будете требуется движение данных v1 script).

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

Первый трюк - отслеживать версии в базе данных (и проект SSDT). Я начал использовать трюк в DBProj и передал его SSDT, и после некоторых исследований выяснилось, что другие тоже используют это. Вы можете применить расширенное свойство DB к самой базе данных (назовите ее "BuildVersion" или "AppVersion" или что-то в этом роде) и примените к ней значение версии. Затем вы можете захватить это расширенное свойство в самом проекте SSDT, и SSDT добавит его как script (затем вы можете проверить параметр публикации, который включает расширенные свойства). Затем я использую переменные SQLCMD для определения исходных и целевых версий, применяемых в текущем проходе. После того, как вы определите дельту версий между исходным (моментальный снимок проекта) и целевым объектом (целевой db, подлежащий обновлению), вы можете найти все моментальные снимки, которые необходимо применить. К сожалению, это сложно сделать из развертывания SSDT, и вам, вероятно, придется переместить его в конвейер сборки или развертывания (мы используем автоматические развертывания TFS и для этого выполняем пользовательские действия).

Следующим препятствием является сохранение моментальных снимков схемы со связанными с ними сценариями перемещения данных. В этом случае, это помогает сделать сценарии как идемпотент насколько возможно (это означает, что вы можете повторно запускать скрипты без каких-либо побочных эффектов). Это помогает разделить скрипты, которые можно безопасно повторить из сценариев, которые должны выполняться только один раз. Мы делаем то же самое со статическими справочными данными (словарем или поисковыми таблицами) - другими словами, у нас есть библиотека сценариев MERGE (по одному на таблицу), которые поддерживают синхронизирующие данные, и эти скрипты включены в сообщение -deployment (через команду SQLCMD: r). Важно отметить, что вы должны выполнить их в правильном порядке, если любая из этих справочных таблиц имеет ссылки FK друг на друга. Мы включаем их в основной пост-развертывание script по порядку, и это помогает нам создать инструмент, который генерирует эти сценарии для нас - он также решает порядок зависимостей. Мы запускаем инструмент этого поколения в конце "версии", чтобы фиксировать текущее состояние статических справочных данных. Все ваши другие сценарии движения данных в основном будут иметь особый случай и, скорее всего, будут одноразовыми. В этом случае вы можете сделать одну из двух вещей: вы можете использовать оператор IF для версии db build/app или вы можете стереть 1 раз скрипты после создания каждого моментального снимка.

Это помогает вспомнить, что SSDT отключит ограничения проверки FK и только повторно включит их после запуска сценариев после развертывания. Это дает вам возможность заполнить новые ненулевые поля, например (кстати, вы должны включить возможность генерации временных "умных" значений по умолчанию для непустых столбцов, чтобы сделать эту работу). Тем не менее, ограничения проверки FK отключены только для таблиц, которые SSDT воссоздает из-за изменения схемы. В других случаях вы несете ответственность за то, чтобы сценарии движения данных выполнялись в правильном порядке, чтобы избежать проблем с ограничениями проверки (или вы вручную отключили/повторно включили их в своих сценариях).

DACPAC может вам помочь, потому что DACPAC по сути является снимком. Он будет содержать несколько XML файлов, описывающих схему (аналогично выпуску сборки проекта), но замороженный во времени в момент его создания. Затем вы можете использовать SQLPACKAGE.EXE или поставщика развертывания для публикации моментального снимка этого пакета. Я не совсем понял, как использовать версию DACPAC, потому что она больше привязана к "зарегистрированным" приложениям данных, поэтому мы придерживаемся нашей собственной схемы управления версиями, но мы помещаем нашу собственную информацию о версии в имя файла DACPAC.

Я бы хотел, чтобы у меня был более убедительный и exhasutive пример, но мы все еще разрабатываем проблемы здесь.

Одна вещь, которая действительно отсасывает SSDT, заключается в том, что, в отличие от DBProj, она в настоящее время не расширяема. Хотя он намного лучше, чем DBProj, имеет много разных вещей, вы не можете переопределить его поведение по умолчанию, если вы не можете найти какой-либо метод внутри сценариев pre/post, чтобы обойти проблему. Одна из проблем, которые мы пытаемся решить сейчас, заключается в том, что метод по умолчанию для воссоздания таблицы обновлений (CCDR) действительно воняет, когда у вас есть десятки миллионов записей.

-UPDATE: я не видел этот пост за какое-то время, но, видимо, он был активным в последнее время, поэтому я подумал, что добавлю пару важных заметок: если вы используете VS2012, выпуск SSDT в июне 2013 года имеет встроенный инструмент сравнения данных, а также предоставляет точки расширяемости - то есть теперь вы можете включать в себя сборщиков и модификаторов плана развертывания для проекта.

Ответ 2

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

В сценариях Pre- и Post-Deploy для данной версии базы данных используются только перенести данные из предыдущей версии. В начале каждого цикла разработки скрипты очищаются, и по мере того, как процесс разработки продолжается, они получают все, что необходимо для безопасной миграции данных из предыдущей версии в новую. Единственным исключением здесь являются статические данные в базе данных. Эти данные известны во время разработки и сохраняют постоянное присутствие в сценариях Post-Deploy в виде операторов TER SQL MERGE. Это помогает развернуть любую версию базы данных в новой среде с помощью только последней публикации script. В конце каждого цикла разработки публикация script создается из предыдущей версии в новую. Этот script будет содержать сгенерированный sql для переноса схемы и сценариев развертывания вручную. Да, я знаю, что инструмент Publish можно использовать напрямую для базы данных, но это не очень хороший вариант для наших клиентов. Я также знаю файлы dacpac, но я не уверен, как их использовать. Сгенерированный публикация script представляется лучшим вариантом, который я знаю для продления производства.

Итак, чтобы ответить на мои сценарии:

1) Чтобы обновить базу данных с v3 до v8, мне пришлось бы выполнить сгенерированную публикацию script для v4, затем для v5, затем для v6 и т.д. Это очень похоже на то, как мы это делаем сейчас. Это хорошо понято, и проекты Database Projects, похоже, облегчают создание/поддержку этих сценариев.

2) Когда схема изменяется из-под данных, сценарии Pre- и Post-Deploy используются для переноса данных туда, где им нужно перейти на новую версию. Поврежденные данные по существу резервируются в Pre-Deploy script и помещаются обратно в Post-Deploy script.

3) Я все еще ищу советы о том, как лучше работать с этими инструментами в этих сценариях и других. Если у меня что-то не так, или если есть какие-то другие ошибки, о которых я должен знать, сообщите мне! Спасибо!

Ответ 3

В моем опыте использования SSDT понятие номеров версий (т.е. v1, v2... vX и т.д.) для баз данных вроде бы уходит. Это связано с тем, что SSDT предлагает парадигму развития, известную как декларативная разработка базы данных, которая свободно означает, что вы сообщаете SSDT, в каком состоянии вы хотите, чтобы ваша схема находилась в этом состоянии, а затем SSDT берет на себя ответственность за то, что он попал в это состояние, сравнивая с тем, что у вас уже есть. В этой парадигме понятие развертывания v4, а затем v5 и т.д. Уходит.

Сценарии предварительного и пост-развертывания, как вы правильно заявляете, существуют для целей управления данными.

Надеюсь, что это поможет.

Ответ 4

Я просто хотел сказать, что этот поток до сих пор был превосходным.

Я боролся с такими же проблемами, и я пытаюсь решить эту проблему в нашей организации, имея довольно большое наследие. Мы начали процесс перехода к SSDT (на ветке TFS), но на тот момент, когда нам действительно нужно понять процесс развертывания и управлять настраиваемыми миграциями, а также ссылочными/поисковыми данными, на этом пути.

Чтобы усложнить ситуацию, наше приложение является одной базой кода, но может быть настроено для каждого клиента, поэтому у нас есть около 190 баз данных, для которых мы имеем дело, для этого одного проекта, не только 3 или около того, как это, вероятно, нормально. Мы все время развертываем и даже настраиваем новых клиентов довольно часто. Мы в значительной степени полагаемся на PowerShell со сценариями постепенного выпуска старой школы (и связанными сценариями для создания нового клиента в этой версии). Я планирую внести свой вклад, как только мы это рассмотрим, но, пожалуйста, поделитесь тем, что вы узнали. Я верю, что мы закончим тем, что будем поддерживать пользовательские сценарии выпуска для каждой версии, но мы увидим. Идея о поддержке каждого script в проекте, включая переменную From и To SqlCmd, очень интересна. Если бы мы это сделали, мы бы, вероятно, обрезали этот путь, физически удалив действительно старые сценарии обновления, как только все были в прошлом.

BTW - Боковое примечание. На тему сведения к минимуму отходов мы также просто потратили кучу времени на выяснение того, как автоматизировать принудительное применение правильных соглашений об именах/типах данных для столбцов, а также автоматическое создание для всех первичных и иностранных ключи, основанные на соглашениях об именах, а также ограничения индексов и проверок и т.д. Самая сложная часть была связана с "девиантами", которые не соблюдали правила. Возможно, я расскажу об этом в один прекрасный день, если кому-то будет интересно, но пока мне нужно продолжить эту историю развертывания, миграции и справочных данных. Еще раз спасибо. Это, как вы, ребята, говорило именно то, что было у меня в голове и искало сегодня утром.