За последние годы процедура настройки автоматического деплоймента на .NET стала проще и понятнее. Значительные изменения произошли с выходом в свет Visual Studio 2010, в которую Microsoft встроила базовые инструменты и сценарии для автоматизации деплоймента. Тем не менее, на тот момент нововведения были задокументированы слабо, и разработчикам приходилось перекапывать Интернет на предмет блогов и видео по данной тематике. К счастью с тех пор ситуация постоянно изменяется в лучшую сторону: сегодня ещё больше инструментов автоматизации доступно «из коробки», а документация позволяет с нуля дойти до работающего решения за пару дней (для примера предлагаю вам ознакомиться с руководством, описывающим процесс конфигурации от начала и до конца, а также с обзорным материалом на MSDN)

В этой статье я покажу вам как быстро настроить основные этапы автоматического деплоймента, а также познакомлю вас с некоторыми инструментами, позволяющими наиболее эффективно справиться с этой задачей.

Запускайте деплоймент с билд-сервера

Вне зависимости от того, какой билд-сервер вы используете для непрерывной интеграции (CI — Continuous Integration), все они позволяют успешно запускать деплоймент и открывают обширные возможности по генерации отчетности и аудиту (вы всегда будете знать, кто и когда запустил деплоймент каждой конкретно взятой версии и чем всё закончилось). Для этого достаточно лишь настроить деплоймент билд-планы для каждой из ваших платформ. Количество разных деплоймент билд-планов в основном зависит от числа ветвей и вашей стратегии по управлению жизненным циклом приложения (ALM — Application Lifecycle Management). Например, у вас может быть что-то наподобие следующей схемы:

  • Integration. Сборки ветки master развертываются на интеграционную платформу, на которой выполняется тестирование пользовательского интерфейса последней версии исходного кода. Запуск происходит как только новый набор коммитов появляется в репозитории.
  • QA. Сборки ветки master развертываются на QA-платформу для доставки новых фич для тестирования, когда команда разработчиков и отдел QA решают, что необходимо провести валидацию новой версии. Запускается вручную.
  • Релиз. Сборка какого-то конкретного коммита ветки master (тега, релиз-бранча и т. п.) переносит версию, прошедшую валидацию тестированием, в продакшен-среду.

Пожалуй, вы также захотите сделать похожие билд-планы для релиз- и feature-веток, если, конечно, вы их используете. Вы также можете добавить план ночного билда для выпуска превью-версии вашего приложения (это, в свою очередь, поможет повысить видимость прогресса по проекту и ускорить получение обратной связи от пользователей без отрыва команды «от производства»).

Билд-сервер обеспечивает вам гарантию того, что билд-план будет всегда запускаться по исходному коду конкретного коммита, таким образом, избавляя вас от ошибок типа «развернута неверная версия исходного кода».

Деплоймент «из коробки» (настройка деплоймента в пару кликов мыши)

Команды Visual Studio и MSBuild последние несколько лет усиленно работали над тем, чтобы значительно облегчить жизнь разработчикам, использующим автоматический деплоймент. В результате появилось много полезных фичей и сейчас можно настроить простой автоматический деплоймент в несколько простых шагов.

У Visual Studio есть так называемые профили публикации (publish profiles). Говоря простым языком, профиль публикации — это версионируемый XML-файл (который вы должны хранить в репозитории), содержащий информацию о платформе и параметрах деплоймента. Как правило, у вас должен быть профиль публикации для каждой из платформ.

Кликните правой кнопкой мыши на вашем проекте в Visual Studio и выберите опцию publish (настройка профиля публикации — шаг 1). Вы можете добавить профиль публикации, используя диалог «manage profiles». Просто введите адрес сервера и пароль (настройка профиля публикации — шаг 2).

Для тех, кто использует Azure: готовые к использованию профили публикации можно скачать напрямую с Azure Management Portal, что, еще больше облегчит вам жизнь.

Теперь произведите чек-ин сгенерированного профиля в репозиторий и внесите изменения в ваш билд-план по деплойменту:

Msbuild.exe Web.csproj /p:DeployOnBuild=true /p:Configuration=Release/p:PublishProfile=nightly /p:Password=p0ssw0rd

Вот и все! MSBuild позаботится о сборке вашего приложения в нужной конфигурации (релизе) и опубликует его в указанную среду (в данном случае — стейджинг). Вы можете расширить/настроить упаковку под ваши конкретные нужды (например, запретить удаление папки /Uploads). Загляните в блог Саеда Хашими из команды MSBuild — там много интересных примеров!

Версионируйте ваши настройки

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

Трансформации конфигурационных файлов впервые появилась в Visual Studio 2010. По сути, файл трансформации — это упрощенная версия xslt-преобразования, позволяющая легко и понятно трансформировать ваши .config файлы. Трансформация — это такой же файл, как и .config, который располагается в том же месте и применяется к оригинальному конфигу при публикации. Синтаксис, используемый в файлах трансформации, невероятно прост, что выгодно отличает их от xslt (описание всего языка умещается в несколько статей на MSDN)

Трансформации могут быть:

  • специфичны конфигурации билда (Release/Debug)
  • специфичны профилю публикации (QA/Production)
При деплойменте MSBuild применит к оригинальному файлу их по очереди: сначала применятся трансформация, соответствующая выбранной конфигурации билдования, а затем — трансформация, соответствующая профилю публикации.

Например:

  • трансформация, соответствующая конфигурации билда (web.Release.config), включает кастомные ошибки для релиза (необходимые для релиза вне зависимости от используемой среды);
  • трансформация для профиля публикации изменяет строки подключения (которые изменяются от среды к среде).
Теперь процесс поддержки разной конфигурации на разных окружениях прост и понятен:
  • продакшен-конфигурация автоматически генерируется из dev-конфигурации;
  • трансформации версионируются в системе управления версиями и естественным образом эволюционируют наряду с исходным кодом и изменениями, вносимыми в dev-конфигурацию и исходный код

И больше никакого ручного мёржа dev- и продакшен-конфигурационных файлов. Никакого хранения изменений в конфигурации в e-mail’ах/wiki. Никакой головной боли!

Обновление базы данных

Ваша база данных изменяется вместе с вашим кодом, поэтому приходится версионировать и то и другое. Есть несколько способов как это можно сделать, но на сегодняшний день большая часть наших команд использует миграционные фреймворки (поскольку они предоставляют детализированный контроль над происходящим). Существует множество миграционных фреймворков для .NET (FluentMigrator, EntityFramework, MigratorDotNet) — выберите тот, который вам по вкусу.

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

О том как писать и настраивать миграции лучше всего прочитать в документации выбранного фреймворка. Например миграции Entity Framework’a запускаются исполнением вот такой консольной команды:

Migrate.exe MyMvcApplication.dll /startupConfigurationFile="..\web.config«

Скриптинг деплоймента с MSBuild

MSBuild — ваш лучший помощник в выполнении всех вышеперечисленных этапов деплоймента. У него есть ряд встроенных возможностей по копированию файлов, запуску исполняемых файлов и управлению настройками конфигурации. Например, вы можете использовать клиент WebDeploy для управления IIS (рестарт ApplicationPool, перевод приложения в офлайн-режим перед деплойментом и в онлайн-режим после деплоймента).

Для всего остального используйте библиотеки расширений (установки ACL, бэкапа базы данных и т. д.). Библиотек много, вот пара тех, которые мне довелось успешно использовать:

  • MSBuild community tasks
  • MSBuild Extension Pack
Например, вы можете использовать таск SqlExecute для того, чтобы сделать бэкап базы данных перед деплойментом. Или использовать таск для установки ACL для папки загрузок. Ознакомившись со списком готовых тасков в этих библиотеках, вы придете к выводу, что вы можете настроить вообще все что угодно для вашего процесса деплоймента без особых усилий и, таким образом, избавиться от какого-либо дальнейшего «ручного» труда.

Резюме

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

Автор статьи — старший .NET-разработчик компании Itransition.