Свободные миграции в установщике продуктов для нескольких платформ

Question

Мы разрабатываем продукты для внешних клиентов-клиентов (т.е. мы не являемся внутренней ИТ-функцией, которая только когда-либо выпускает продукты для сред в нашей сфере контроля), и в настоящее время мы должны поддерживать как SQL Server 2005+ и Oracle 10.2+ в качестве задней части. Мы используем TeamCity с Wix для CI и сборки, которые идут в нашу тестовую группу и, очевидно, в конечном итоге к нашим клиентам, когда тестирование завершено. В настоящее время у нас есть бесконечное количество SQL-скриптов для обновления баз данных. В самой базовой форме может быть сценарий DDL и сценарий данных (для каждой версии для каждой платформы), но также могут быть сценарии, содержащие хранимые процедуры и даже клиентские скрипты. В зависимости от того, сколько версий клиент обновляет (например, от 2.0 до 2.7), им может потребоваться выполнить до двух десятков скриптов в правильном порядке.

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

Я изучаю использование Fluent Migrator или аналогичный - не обязательно должен быть Fluent - чтобы попытаться принести немного больше контроля над порядком и версией для всего процесса, но в то время как есть много статей и примеров о том, как использовать его с CI, я ничего не могу найти о интеграции миграции в установщик MSI или подобное.

Я хочу сделать это либо как часть нашего общего установщика, либо создать его специально для обновления/понижения базы данных. Оставляя в стороне какие-либо специфические миграции клиентов на данный момент, можно ли вообще выполнять универсальные миграции из установщика? И если да, то как насчет таргетинга на несколько платформ в одном инсталляторе (т. Е. Доступны и как миграции SQL, так и Oracle) во время исполнения?

Мой план состоит в том, чтобы сохранить миграции в одной сборке (аналогично описанию в this article) и установить установщиком соответствующую миграцию вверх/вниз на основе информации, испеченной при создании установщика. Предполагая, что это можно сделать, это звучит как разумное решение или есть лучший способ управлять всем этим, о котором я не знаю?

Большое спасибо

Стив

Answer 1

Да, это вполне возможно.

Чтобы запустить FluentMigrator из собственного кода, вам просто нужно создать RunnerContext и выполнить его. См. Пример NAnt runner (или Console runner).

Для таргетинга на различные платформы вы можете управлять этим при выполнении RunnerContext путем передачи в базе данных типа через параметр базы данных. Другие параметры передаются в ApplicationContext, которые будут использоваться в процессе миграции. Или используя фильтрацию с Tags, которая может быть установлена ​​при миграции.