Предыдущий ролик Следующий ролик  

Видео урок: Deploying without automatic migrations

Основы ASP.NET MVC 5

Автоматические миграции Code First - это мощный инструмент, но есть сценарии, в которых приходится использовать только явные миграции на основе кода. Продолжая работу над нашим проектом с того места, на котором мы остановились в предыдущем видео, я покажу вам, как развернуть приложение, для которого отключена функция автоматических миграций. Во время разработки нашего приложения мы много раз активировали функцию автоматических миграций. Но давайте представим себе сценарий, в котором эту функцию нужно отключить. Автоматические миграции не всегда являются идеальным инструментом, есть даже случаи, когда они и вовсе не работают.

Кроме того, возможно, вам придется работать с таким членом команды или начальником, который настаивает на том, чтобы все отложенные изменения анализировались либо с помощью сгенерированных SQL-скриптов, либо с помощью миграций на основе кода. В последнем случае нам нужно будет убедиться, что во время развертывания выполняются наши явные миграции. Поэтому в классе Configuration мы устанавливаем свойство AutomaticMigrationsEnabled равным "false". В классе ApplicationDbContext инициализатор базы данных, который мы настроили для первого развертывания на AppHarbor, должен выполнять действие, аналогичное выполнению команды Update-Database в консоли диспетчера пакетов, которая, как вы помните, применяет явные, а также автоматические миграции перед выполнением метода Seed.

Поскольку мы только что отключили автоматические миграции, нам нужно убедиться в наличии полного комплекта современных явных миграций, а поскольку ранее имеющиеся миграции мы удалили, нам нужно добавить еще одну, олицетворяющую полноценную первоначальную миграцию из пустой базы данных в текущее состояние. Самый простой способ - сбросить наши Code First миграции, удалив сначала историю миграций в базе данных. Добраться до истории миграций можно, дважды щелкнув на файле базы данных.

Итак, можно просто выделить таблицу _MigrationHistory и нажать кнопку Delete, а затем - кнопку Update Database (Обновить базу данных). После этого в консоли диспетчера пакетов просто выполним команду Add-Migration и назовем эту миграцию "InitialCreate", аналогично той, которую мы генерировали первой. В результате получаем миграцию на основе кода для всей схемы, которую при необходимости перед развертыванием можно пересматривать и редактировать. Теперь мы действительно готовы к развертыванию. Но если мы хотим продолжить разработку и впоследствии использовать это приложение локально, то нам нужно проверить, что созданная нами миграция никогда больше не будет выполняться в этой базе данных, поскольку все ее составляющие уже существуют.

Один из способов решения этой проблемы - применить миграцию, закомментировав при этом метод Up. Итак, я только что закомментировал метод Up, что дает нам возможность вставить эту миграцию в таблицу _MigrationHistory, в действительности ее не выполняя. Итак, закомментировав эту секцию, я выполняю команду Update-Database, а потом раскомментирую ее, чтобы миграцию можно было выполнить во время развертывания. Вот теперь мы хорошо подготовились к развертыванию, а также к последующей разработке с использованием явных миграций Code First.

Убедимся, что изменения сохранены. На AppHarbor я уже настроил новое приложение под названием "MVC ATM (Explicit Db)", установил дополнительный компонент - SQL-сервер и задал псевдоним моей строки подключения. Скопируем теперь URL репозитория. Затем в Git Bash можно просто переключить удаленный репозиторий на этот URL с помощью команды "git remote set-url appharbor" и указать URL нового репозитория.

Также добавим и зафиксируем последние изменения. Пока удаление элементов из репозитория мы не рассматриваем. Просто зафиксируем изменения: "git commit -m "explicit migrations"". А затем выполним команду: "git push appharbor master". После публикации изменений можно обновить страницу и подождать, пока она построится и развернется. Если все завершилось успешно, можно обновить страницу. В результате мы увидим ссылку "Перейти к приложению".

Если вы видите вот такую страницу nginx, то это значит, что еще не все готово. Поэтому немного подождите и снова обновите страницу. Теперь она вроде как загружается. Снова войдем на mbcatm под логином администратора, чтобы подтвердить, что наша база данных обновлена и метод Seed выполняется. Если вы будете продолжать вносить изменения в свои модели, то не забывайте добавлять явные миграции. В противном случае вы получите ошибку, в которой будет говориться о необходимости добавления такой миграции или перехода на автоматические миграции.

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