Continuous Integration и Continuous Delivery де-факто являются неотъемлемой частью современной разработки проектов. Для автоматизации CI существует множество программ от различных вендоров, а вот с автоматизированием развертывания приложений дела обстоят скромнее. Одним из помощников развертывания является Octopus Deploy.

Введение

Давайте рассмотрим распространенный подход в процессе разработки. Разработчики пишут код, прогоняют unit-тесты по затронутому коду, делают commit. И делают это как можно чаще, согласно идеологии CI. Далее CI приложение (TeamCity, TFS, Jenkins, Bamboo, или другое любимое в вашей команде) собирает приложение и прогоняет автоматические тесты.
Наступает момент, когда пора отдать приложение на ручное тестирование и член команды (DevOps) развертывает приложение для тестеров.

А вот и следующий момент, пора отдавать на тестирование заказчику (User Acceptance Test или Staging).
Ну и после зеленого сигнала от заказчика наступает главный по значимости момент, публикация приложение в production. Причем часто заказчик ожидает, что если что-то пойдет не так в production'e, то ваша команда сможет откатить все изменения щелчком пальца, максимум в течение получаса.

На помощь в развертывании .NET приложений приходит Octopus Deploy. Octopus забирает пакет с приложением и развертывает его на сервере. Обычно первым идет Dev Environment сервер. Далее можно легко продвинуть приложение на Test, UAT/Staging, а затем и Production environment сервера. Но обо всем по порядку.

Устройство Octopus

Осьминожка использует Octopus Server, который забирает NuGet пакеты с приложениями. Забирать их может автоматически из NuGet репозитория, подписавшись на NuGet Feed CI сервера по http/https, или из обычной папки на сервере. Как правило NuGet пакет должен содержать полное приложение, например ваш полный ASP.NET Web сайт, или все файлы необходимые для установки Windows Service'a.

Дотягивается Octopus до серверов публикации с помощью щупалец. Tentacle Agent представляет собой легковесную программу, которая запускается в виде Windows Service'a, забирает Nuget пакет с Octopus Server'a и разворачивает приложение. Есть режим общения pull и push, т.е. Tentacle периодически опрашивает сервер на новые пакеты, или Tentacle ждет сигнала от сервера и сервер push'ит. Octopus Server также запускается в виде Windows сервиса, и общается со своими щупальцами через защищенной HTTPS (TLS и X.509 сертификат). Для большей безопасности при установке Octopus необходимо настроить каким Tentacle агентам доверяет сервер и наоборот.

В текущей версии 2.0 для хранения всех данных используется встроенная база данных RavenDB, но по ряду причин в новой версии 3.0 перейдут на MS SQL Server. Кстати новая версия выйдет в ближайшие месяцы, хотя согласно политике компании у вас будет возможность обновиться до новой версии в ближайший год после покупки, после года вас не бросает на полный произвол и дают скачать критические обновления бесплатно, но уже, конечно, без новых фитч.

Среда, роли и приложения

Остановимся немного подробнее на структуре, которая может получится.

У нас три environment'a (Test, Staging и Production). Шесть серверов, на которые установлены Tentacles и куда будет устанавливаться приложение. И две роли: octo-web и octo-app. Создание ролей очень удобно, например можно указать: установить сайт только на машины, у которых есть роль octo-web, а приложение только на машины с ролью octo-app. Заметьте, что для тестирования отведен один сервер, на котором будет находится и сайт, и приложение. А на production целых три сервера, один под приложение, и два под сайт. Это очень реалистичный сценарий с развертыванием двух копий сайта (без базы данных) и последующим запуском балансировщика.

Приложение OctoFX, с ролью octo-app, будет выглядеть следующим образом:

Жизненный цикл приложения будет заключаться в прохождении Test среды, далее Staging, а затем запуска на Production.
Настройки очень широкие и можно выбирать доступные среды для разных приложений.

Шаги и переменные

Шаги

Каждое развертывание делается пошагово. И в каждом шаге есть возможность:

• Скачать и разместить содержимое NuGet пакета в папке, FTP или MS Azure сервере
• Запустить Power Shell скрипт, передать в скрипт переменные
• Обновить config файлы с помощью специальных переменных
• Трансформировать config файлы. Как правило при сборке будет запускаться config.Release, но вы можете добавить еще одну XML трансформацию поверх, например config.Staging
• Отправлять сообщения по электронной почте
• Останавливать процесс развертывания и запросить действия пользователя.
• Запускать специальный шаг для удобного разворачивания Windows сервиса
• Запускать специальный шаг для разворачивания сайта, включая обновление binding'ов и портов

Переменные

Переменные вынесены в отдельный блок и позволяют модифицировать значение в зависимости от среды, роли или имени сервера.
Рассмотрим пример с Хабром, если нам необходимы разные значения для адреса нашего сайта и мы хотим поменять переменную в web config'e, то достаточно ее добавить в блок

Тогда config файл

<appSettings>
    <add key="HabrahabrSiteRoot" value="testkey"/>
  </appSettings>
  <deepConfigSection>
    <anotherTagExample someAttribute ="Site #{HabrahabrSiteRoot}" />
  <deepConfigSection>

может быть автоматически трансформирован в Dev среде в

<appSettings>
    <add key="HabrahabrSiteRoot" value="http://dev-habrahabr.local"/>
  </appSettings>
  <deepConfigSection>
    <anotherTagExample someAttribute ="Site http://dev-habrahabr.local" />
  <deepConfigSection>

Удобнее всего хранить в переменных пароли, так как Octopus их шифрует и не позволяет скопировать или увидеть в дальнейшем в панели Variables. Существует возможность создать пользователей и ограничить доступ в средам. Таким образом с помощью блока переменных и ограничения доступа пользователям можно сделать так, что только администратор или Release менеджер может развернуть приложение в Production и соответсвенно увидеть пароли в конечном варианте config файла.

Имеются и специальные системные переменные. Их можно использовать также, как и пользовательские переменные, т.е. в PowerShell скриптах или Config файлах. Например, один из наших клиентов использует Umbraco сайт. Конечно в NuGet пакет имеет смысл складывать только исполняемую часть сайта, а не Гигабайты медиа контента. При обновлении сайта Octopus создает новую папку, т.е. на самом деле новый сайт, например, кладет его в папку \Octopus\Applications\UmracoSite\1.20.0\. И мы копируем с помощью PowerShell скрипта и переменной Octopus.Deployment.PreviousSuccessful.Id весь media контент из старой версии сайта в новую.

Заключение

До сих пор я встречаю ручной бэкап базы данных перед развертыванием приложения, ручное изменение config файлов, множество вариантов самописных скриптов, которые хранятся локально и отличаются у программистов и системных администраторов, и даже ручное копирование папки приложения в production и test environment.
Попробуйте минимизировать человеческий фактор и рутину в этом процессе. И удачного вам deployment'a!

Полезные ссылки:

Проект
Видео уроки
Документация