Управление жизненным циклом приложения: от разработки до рабочей среды

Джейсон Ли

В этом разделе показано, как вымышленная компания управляет развертыванием веб-приложения ASP.NET через тестовую, промежуточную и рабочую среды в рамках непрерывного процесса разработки. В этом разделе приводятся ссылки на дополнительные сведения и пошаговые руководства по выполнению конкретных задач.

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

Примечание

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

Общие сведения

Процесс развертывания, показанный здесь, основан на сценарии развертывания Fabrikam, Inc., описанном в разделе Корпоративное веб-развертывание: обзор сценария. Прежде чем изучать этот раздел, ознакомьтесь с общими сведениями о сценарии. По сути, в сценарии рассматривается, как организация управляет развертыванием достаточно сложного веб-приложения, решения диспетчера контактов, на различных этапах в типичной корпоративной среде.

На высоком уровне решение Диспетчера контактов проходит следующие этапы в процессе разработки и развертывания:

1. Разработчик проверяет код в Team Foundation Server (TFS) 2010.
2. TFS создает код и выполняет все модульные тесты, связанные с командным проектом.
3. TFS развертывает решение в тестовой среде.
4. Команда разработчиков проверяет и проверяет решение в тестовой среде.
5. Администратор промежуточной среды выполняет развертывание "что если" в промежуточной среде, чтобы определить, вызовет ли развертывание какие-либо проблемы.
6. Администратор промежуточной среды выполняет динамическое развертывание в промежуточной среде.
7. Решение проходит пользовательское приемочное тестирование в промежуточной среде.
8. Пакеты веб-развертывания импортируются вручную в рабочую среду.

Эти этапы образуют часть непрерывного цикла разработки.

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

В оставшейся части этого раздела рассматриваются следующие ключевые этапы жизненного цикла развертывания:

• Предварительные требования. Как необходимо настроить серверную инфраструктуру, прежде чем использовать логику развертывания.
• Начальная разработка и развертывание. Что необходимо сделать перед первым развертыванием решения.
• Развертывание для тестирования. Как упаковывать и развертывать содержимое в тестовой среде автоматически, когда разработчик выполняет проверку нового кода.
• Развертывание в промежуточной среде: развертывание определенных сборок в промежуточной среде и выполнение развертываний "что если", чтобы гарантировать, что развертывание не вызовет никаких проблем.
• Развертывание в рабочей среде. Импорт веб-пакетов в рабочую среду, когда сетевая инфраструктура препятствует удаленному развертыванию.

Предварительные требования

Первой задачей в любом сценарии развертывания является обеспечение соответствия серверной инфраструктуры требованиям средств и методов развертывания. В этом случае компания Fabrikam, Inc. настроила серверную инфраструктуру следующим образом:

• TFS настроен для включения коллекции командных проектов, контроллеров сборки и агентов сборки. Дополнительные сведения см. в разделе Настройка Team Foundation Server для автоматического веб-развертывания .
• Тестовая среда настроена для приема удаленных развертываний с помощью службы веб-Deployment Agent ("удаленный агент"), как описано в разделах Сценарий: Настройка тестовой среды для веб-развертывания и Настройка веб-сервера для публикации веб-развертывания (удаленный агент) .
• Промежуточная среда настроена для приема удаленных развертываний с помощью конечной точки обработчика веб-развертывания, как описано в разделах Сценарий: Настройка промежуточной среды для веб-развертывания и Настройка веб-сервера для публикации веб-развертывания (обработчик веб-развертывания).
• В рабочей среде администратор может вручную импортировать пакеты веб-развертывания в службы IIS, как описано в разделах Сценарий: Настройка рабочей среды для веб-развертывания и Настройка веб-сервера для публикации веб-развертывания (автономное развертывание).

Начальная разработка и развертывание

Прежде чем команда разработчиков Fabrikam, Inc. сможет развернуть решение Диспетчера контактов в первый раз, ей необходимо выполнить следующие задачи:

• Создайте командный проект в TFS.
• Создайте файлы проекта Microsoft Build Engine (MSBuild), содержащие логику развертывания.
• Создайте определения сборки TFS, которые запускают процессы развертывания.

Создание нового командного проекта

• Администратор TFS Роб Уолтерс создает командный проект для приложения, как описано в разделе Создание командного проекта в TFS. Затем ведущий разработчик, Мэтт Хинк, создает решение для создания макета. Он проверяет свои файлы в новом командном проекте в TFS, как описано в статье Добавление содержимого в систему управления версиями.

Создание логики развертывания

Мэтт Хинк создает различные пользовательские файлы проекта MSBuild, используя подход с разделением файлов проекта, описанный в разделе Общие сведения о файле проекта. Мэтт создает:

• Файл проекта с именем Publish.proj , который запускает процесс развертывания. Этот файл содержит целевые объекты MSBuild, которые создают проекты в решении, создают веб-пакеты и развертывают пакеты в среде целевого сервера.
• Файлы проекта для конкретной среды с именами Env-Dev.proj и Env-Stage.proj. Они содержат параметры, относящиеся к тестовой среде и промежуточной среде соответственно, например строки подключения, конечные точки службы и сведения о удаленной службе, которая получит веб-пакет. Рекомендации по выбору правильных параметров для конкретных целевых сред см. в разделе Настройка свойств развертывания для целевой среды.

Чтобы запустить развертывание, пользователь выполняет файл Publish.proj с помощью MSBuild или Team Build и указывает расположение соответствующего файла проекта для конкретной среды (Env-Dev.proj или Env-Stage.proj) в качестве аргумента командной строки. Затем файл Publish.proj импортирует файл проекта для конкретной среды, чтобы создать полный набор инструкций по публикации для каждой целевой среды.

Примечание

Способ работы этих пользовательских файлов проекта не зависит от механизма, используемого для вызова MSBuild. Например, можно использовать командную строку MSBuild напрямую, как описано в разделе Общие сведения о файле проекта. Файлы проекта можно запустить из командного файла, как описано в разделе Создание и запуск командного файла развертывания. Кроме того, можно запустить файлы проекта из определения сборки в TFS, как описано в статье Создание определения сборки, поддерживающего развертывание.
В каждом случае конечный результат будет одинаковым — MSBuild выполняет объединенный файл проекта и развертывает решение в целевой среде. Это обеспечивает большую гибкость при запуске процесса публикации.

После создания пользовательских файлов проекта Мэтт добавляет их в папку решения и проверяет их в системе управления версиями.

Создание определений построений

В качестве окончательной задачи подготовки Мэтт и Роб совместно создают три определения сборки для нового командного проекта:

• DeployToTest. Это создает решение Диспетчера контактов и развертывает его в тестовой среде при каждом проверка.
• DeployToStaging. При этом ресурсы из указанной предыдущей сборки развертываются в промежуточной среде, когда разработчик помещает сборку в очередь.
• DeployToStaging-WhatIf. При этом выполняется развертывание "что если" в промежуточной среде, когда разработчик помещает сборку в очередь.

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

Развертывание для тестирования

Команда разработчиков в Fabrikam, Inc. поддерживает тестовые среды для проведения различных действий по тестированию программного обеспечения, таких как проверка и проверка, тестирование удобства использования, тестирование совместимости и нерегламентированное или исследовательское тестирование.

Команда разработчиков создала определение сборки в TFS с именем DeployToTest. В этом определении сборки используется триггер непрерывной интеграции. Это означает, что процесс сборки выполняется каждый раз, когда член команды разработчиков Fabrikam, Inc. выполняет проверка. При активации сборки определение сборки:

• Создайте решение ContactManager.sln. Это, в свою очередь, создает каждый проект в решении.
• Выполните все модульные тесты в структуре папок решения (если решение успешно создано).
• Запустите пользовательские файлы проекта, которые управляют процессом развертывания (если решение успешно выполняет сборку и пройдет какие-либо модульные тесты).

В результате, если решение успешно выполняет сборку и проходит модульные тесты, веб-пакеты и другие ресурсы развертывания развертываются в тестовой среде.

Как работает процесс развертывания?

Определение сборки DeployToTest предоставляет следующие аргументы в MSBuild:

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

Свойства DeployOnBuild=true и DeployTarget=package используются, когда командная сборка создает проекты в решении. Если проект является проектом веб-приложения, эти свойства указывают MSBuild на создание пакета веб-развертывания для проекта. Свойство TargetEnvPropsFile сообщает файлу Publish.proj , где найти файл проекта для конкретной среды для импорта.

Примечание

Подробное пошаговое руководство по созданию определения сборки, подобного этому, см. в разделе Создание определения сборки, поддерживающего развертывание.

Файл Publish.proj содержит целевые объекты, которые создают каждый проект в решении. Однако он также включает условную логику, которая пропускает эти целевые объекты сборки, если вы выполняете файл в team build. Это позволяет воспользоваться дополнительными функциями сборки, которые предлагает Team Build, например возможностью выполнения модульных тестов. Если сборка решения или модульные тесты завершаются сбоем, файл Publish.proj не будет выполнен и приложение не будет развернуто.

Условная логика выполняется путем оценки свойства BuildingInTeamBuild . Это свойство MSBuild, которое автоматически задается в значение true при использовании Team Build для сборки проектов.

Развертывание в промежуточном режиме

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

Определения сборки, используемые для развертывания решения в промежуточной среде DeployToStaging-WhatIf и DeployToStaging, имеют следующие характеристики:

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

Это высокоуровневый процесс развертывания в промежуточной среде:

1. Администратор промежуточной среды Роб Уолтерс помещает сборку в очередь с помощью определения сборки DeployToStaging-WhatIf . Роб использует параметры определения сборки, чтобы указать, какую сборку он хочет развернуть.
2. Определение сборки DeployToStaging-WhatIf выполняет пользовательские файлы проекта в режиме "что если". При этом создаются файлы журналов, как если бы Роб выполнял динамическое развертывание, но фактически не вносит никаких изменений в целевую среду.
3. Роб проверяет файлы журналов, чтобы определить влияние развертывания на промежуточную среду. В частности, Роб хочет проверка, что будет добавлено, что будет обновлено, а что будет удалено.
4. Если Роб удовлетворен тем, что развертывание не внесет нежелательных изменений в существующие ресурсы или данные, он помещает сборку в очередь с помощью определения сборки DeployToStaging .
5. Определение сборки DeployToStaging запускает пользовательские файлы проекта. Они публикуют ресурсы развертывания на основном веб-сервере в промежуточной среде.
6. Контроллер платформы веб-фермы (WFF) синхронизирует веб-серверы в промежуточной среде. Это делает приложение доступным на всех веб-серверах в ферме серверов.

Как работает процесс развертывания?

Определение сборки DeployToStaging предоставляет следующие аргументы в MSBuild:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

Свойство TargetEnvPropsFile сообщает файлу Publish.proj , где найти файл проекта для конкретной среды для импорта. Свойство OutputRoot переопределяет встроенное значение и указывает расположение папки сборки, содержащей ресурсы, которые требуется развернуть. Когда Роб помещает сборку в очередь, он использует вкладку Параметры , чтобы предоставить обновленное значение для свойства OutputRoot .

Примечание

Дополнительные сведения о создании такого определения сборки см. в разделе Развертывание конкретной сборки.

Определение сборки DeployToStaging-WhatIf содержит ту же логику развертывания, что и определение сборки DeployToStaging . Однако он включает дополнительный аргумент WhatIf=true:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

В файле Publish.proj свойство WhatIf указывает, что все ресурсы развертывания должны публиковаться в режиме "что если". Другими словами, файлы журналов создаются так, как если бы развертывание прошло, но в конечной среде фактически ничего не изменилось. Это позволяет оценить влияние предлагаемого развертывания, в частности, то, что будет добавлено, что будет обновлено и что будет удалено, прежде чем вносить какие-либо изменения.

Примечание

Дополнительные сведения о настройке развертываний "что если" см. в разделе Выполнение развертывания "Что если".

После развертывания приложения на основном веб-сервере в промежуточной среде WFF автоматически синхронизирует приложение на всех серверах в ферме серверов.

Примечание

Дополнительные сведения о настройке WFF для синхронизации веб-серверов см. в статье Создание фермы серверов с помощью платформы веб-фермы.

Развертывание в рабочей среде

После утверждения сборки в промежуточной среде команда Fabrikam, Inc. может опубликовать приложение в рабочей среде. Рабочая среда — это среда, в которой приложение переходит в режим реального времени и достигает своей целевой аудитории конечных пользователей.

Рабочая среда находится в сети периметра с выходом в Интернет. Она изолирована от внутренней сети, содержащей сервер сборки. Администратор рабочей среды Лиза Эндрюс должна вручную скопировать пакеты веб-развертывания с сервера сборки и импортировать их в IIS на основном рабочем веб-сервере.

Это высокоуровневый процесс развертывания в рабочей среде:

1. Команда разработчиков советует Лизе, что сборка готова к развертыванию в рабочей среде. Команда консультирует Лизу о расположении пакетов веб-развертывания в папке drop на сервере сборки.
2. Лиза собирает веб-пакеты с сервера сборки и копирует их на основной веб-сервер в рабочей среде.
3. Лиза использует диспетчер IIS для импорта и публикации веб-пакетов на основном веб-сервере.
4. Контроллер WFF синхронизирует веб-серверы в рабочей среде. Это делает приложение доступным на всех веб-серверах в ферме серверов.

Как работает процесс развертывания?

Диспетчер IIS включает мастер импорта пакетов приложений, который упрощает публикацию веб-пакетов на веб-сайте IIS. Пошаговое руководство по выполнению этой процедуры см. в разделе Установка веб-пакетов вручную.

Заключение

В этом разделе представлена иллюстрация жизненного цикла развертывания для типичного веб-приложения корпоративного уровня.

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

• Веб-развертывание на предприятии. В этом руководстве содержатся общие сведения о методах веб-развертывания с помощью MSBuild и средства веб-развертывания IIS (веб-развертывания).
• Настройка серверных сред для веб-развертывания. В этом руководстве содержатся рекомендации по настройке сред Windows Server для поддержки различных сценариев развертывания.
• Настройка Team Foundation Server для автоматического веб-развертывания. В этом руководстве содержатся рекомендации по интеграции логики развертывания в процессы сборки TFS.
• Расширенное корпоративное веб-развертывание. В этом руководстве содержатся рекомендации по решению некоторых из более сложных задач развертывания, с которыми сталкиваются организации.

Назад