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

Джейсон Ли

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

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

Замечание

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

Обзор

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

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

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

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

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

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

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

Необходимые условия

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

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

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

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

• Создайте новый командный проект в 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 импортирует файл проекта для конкретной среды, чтобы создать полный набор инструкций по публикации для каждой целевой среды.

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

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

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

• 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 используются, когда Team Build выполняет сборку проектов в составе решения. Если проект является проектом веб-приложения, эти свойства указывают 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. Rob проверяет файлы журнала, чтобы определить последствия развертывания в промежуточной среде. В частности, Роб хочет проверить, что будет добавлено, что будет обновлено, и что будет удалено.
4. Если Роб удовлетворен тем, что развертывание не будет вносить нежелательные изменения в существующие ресурсы или данные, он ставит сборку в очередь, используя определение сборки DeployToStaging.
5. Определение сборки DeployToStaging запускает кастомизированные файлы проекта. Эти ресурсы развертывания загружаются на основной веб-сервер в промежуточной среде.
6. Контроллер веб-фермы (WFF) синхронизирует веб-серверы в промежуточной среде. Это делает приложение доступным на всех веб-серверах в ферме серверов.

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

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

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

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

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

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

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

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

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

Развертывание в эксплуатацию

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

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

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

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

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

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

Conclusion

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

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

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