Использование FluentMigrator с существующей базой данных

Я ищу структуру переноса, которая будет работать с существующим проектом, который использует .NetTiers, более старый ORM, который требует, чтобы CodeSmith генерировал код доступа к данным.

У нас есть опыт круглого стола, и у нас есть успех в его использовании. Мы также можем автоматически развертывать изменения схемы при запуске развертываний из Octopus Deploy. Довольно легко, поскольку это всего лишь коллекция SQL-скриптов.

Мне было интересно перейти на FluentMigrator. Мне нравится FM DSL, и я нашел этот SO-вопрос весьма полезным, однако есть несколько вещей, которые я не задираю:

  • Каков правильный способ импорта существующей схемы базы данных [*]?
  • Каков правильный способ развертывания миграции в производственной среде [**]?

[*] Мое предположение заключается в том, что я генерирую единственный script с использованием инструментов SQL Server и использую ExecuteEmbeddedSql в качестве начальной миграции. Это правильно?

[**] Существует три основных способа запуска миграции (Command Line, NAnt runner, runner MSBuild). Им потребуется доступ к базе данных, чтобы они могли работать. Представьте, что мы хотим развернуть это в среде PROD. Разработчики и сервер сборки не имеют доступа к этой среде. Как вы запускаете эти бегуны против этой среды?

Наш обычный процесс развертывания - создать сборник SQL-скриптов, которые необходимо развернуть как часть развертывания. Ops запускает их как часть развертывания либо автоматически как часть процесса Octopus Deploy (powershell), либо запускается вручную, если развертывание находится вне Octopus).

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

  • Запись миграции
  • Запустите миграцию для обновления базы данных (укажите конкретную базу данных .NetTiers)
  • Запустите .NetTiers против конкретной базы данных .NetTiers(центральный сервер сборки)
  • Код против новых .NetTiers сгенерированных объектов, полей db и т.д.

Мне бы хотелось сбросить .NetTiers, но рефакторинг, к сожалению, в настоящее время не является жизнеспособным вариантом.

Ответы

Ответ 1

Я, наконец, решил это. Полный план решения можно найти на http://benpowell.org/deploying-database-migrations-in-net-using-fluentmigrator-teamcity-and-octopus-deploy/.

Я подвел итоги блога ниже. Большинство моих проблем связано с недостаточным пониманием FluentMigrator. Я выберу свои оригинальные вопросы один за другим.

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

Я не мог найти "правильный путь", но я мог найти способ, который сработал у меня! Я принял следующие основные решения:

  • я запустил всю базу данных в качестве базовой линии. Я включил все таблицы, procs, ограничения, представления, индексы и т.д. Я настраиваю свою первую итерацию как базовую. Я выбрал вариант CREATE без DROP. Это будет моя миграция.
  • Я запускал тот же самый script дамп, но выбирал только DROP. Это будет моя миграция вниз.

Миграция базовой линии просто должна использовать метод EmbeddedScript для выполнения прикрепленного script (я также организую сценарии в итерационных папках).

[Tags(Environments.DEV, Environments.TIERS, Environments.CI, Environments.TEST)]
[Migration(201403061552)]
public class Baseline : Migration
{
    public override void Up()
    {
        this.Execute.EmbeddedScript("BaselineUp.sql");
    }

    public override void Down()
    {
        this.Execute.EmbeddedScript("BaselineDown.sql");
    }
}

Исходный уровень решен...

Как работать с .NetTiers

Хорошо, это было несколько сложной задачей. Я создал конкретную базу данных .NetTiers, которую я бы использовал для запуска генерации кода .NetTiers. В FluentMigrator вы можете "пометить" миграции. Я решил пометить на основе среды. Следовательно, у меня есть тег 'tiers', а также теги для 'dev', 'test', 'uat', 'prod' и т.д. Как это произойдет, последует позже.

При изменении схемы я создаю миграцию и использую теги 'tiers', чтобы сфокусироваться на изменении схемы .NetTiers. Затем я запускаю migrate.exe из внешние инструменты Visual Studio используя этот тег как флаг. Соединение с базой данных app.config, которое соответствует имени моей машины, будет использоваться для подключения к базе данных, поэтому я указываю его в базе данных уровней. Теперь моя миграция запустила мою исходную базу данных .NetTiers. Теперь я могу запустить инструмент генерации кода .NetTiers Codesmith для создания новых DLL.

.NetTiers решили...

Каков правильный способ развертывания миграции в рабочей среде?

Я использую Octopus Deploy и, честно говоря, если вы развертываете .NET-приложения, особенно на нескольких серверах, это должен быть ваш абсолютный инструмент для этого!

Я не буду вдаваться в подробности Octopus Deploy, но на базовом уровне вы можете объединить TeamCity и Octopus. OD предоставляет два предмета, чтобы вы могли двигаться.

  • Программа под названием Octopack, которая завершает ваше приложение как пакет NuGet.
  • Плагин TeamCity, который позволяет TeamCity создавать пакет NuGet и предлагать его как артефакт, открытый в канале NuGet.

Octopus Deploy затем потребляет этот канал NuGet и может развернуть эти пакеты на конечных серверах. В части этого процесса развертывания работает PreDeploy и PostDeploy Powershell script. Здесь я собираюсь запустить приложение migrate.exe с моими конкретными тегами.

Развертывание решено...