应用程序生命周期管理：从开发到生产

  • 项目

作者 ：Jason Lee

本主题说明虚构公司如何在持续开发过程中通过测试、过渡和生产环境来管理 ASP.NET Web 应用程序的部署。 在整个主题中，提供了指向有关如何执行特定任务的详细信息和演练的链接。

本主题旨在提供有关企业中 Web 部署 的一系列教程的高级 概述。 如果不熟悉此处所述的一些概念，请不要担心，以下教程提供了有关所有这些任务和技术的详细信息。

注意

为简单起见，本主题不讨论在部署过程中更新数据库。 但是，对数据库功能进行增量更新是许多企业部署方案的要求，可以在本教程系列的后面部分找到有关如何完成此操作的指南。 有关详细信息，请参阅 部署数据库项目。

概述

此处演示的部署过程基于 企业 Web 部署：方案概述中所述的 Fabrikam， Inc. 部署方案。 在学习本主题之前，应先阅读方案概述。 从本质上讲，该方案检查组织如何通过典型企业环境中的各个阶段管理相当复杂的 Web 应用程序（ 即联系人管理器解决方案）的部署。

在高级别上，Contact Manager 解决方案在开发和部署过程中会经历以下阶段：

  1. 开发人员将某些代码签入 Team Foundation Server (TFS) 2010。
  2. TFS 生成代码并运行与团队项目关联的任何单元测试。
  3. TFS 将解决方案部署到测试环境。
  4. 开发人员团队在测试环境中验证并验证解决方案。
  5. 过渡环境管理员对过渡环境执行“what if”部署，以确定部署是否会导致任何问题。
  6. 过渡环境管理员对过渡环境执行实时部署。
  7. 该解决方案在过渡环境中接受用户验收测试。
  8. Web 部署包手动导入生产环境。

这些阶段是持续开发周期的一部分。

这些阶段是持续开发周期的一部分。

实际上，此过程稍微复杂一些，当我们更详细地查看每个阶段时，你将看到这一点。 Fabrikam， Inc. 为每个目标环境使用不同的部署方法。

Fabrikam， Inc. 为每个目标环境使用不同的部署方法。

本主题的其余部分将探讨此部署生命周期的以下关键阶段：

  • 先决条件：在部署逻辑到位之前，需要如何配置服务器基础结构。
  • 初始开发和部署：首次部署解决方案之前需要执行的操作。
  • 要测试的部署：当开发人员签入新代码时，如何自动将内容打包并部署到测试环境。
  • 部署到过渡：如何将特定生成部署到过渡环境，以及如何执行“假设”部署，以确保部署不会导致任何问题。
  • 部署到生产环境：当网络基础结构阻止远程部署时，如何将 Web 包导入生产环境。

先决条件

任何部署方案中的第一项任务是确保服务器基础结构满足部署工具和技术的要求。 在本例中，Fabrikam， Inc. 已配置其服务器基础结构，如下所示：

初始开发和部署

Fabrikam， Inc. 开发团队首次部署 Contact Manager 解决方案之前，需要执行以下任务：

  • 在 TFS 中创建新的团队项目。
  • ) 包含部署逻辑的项目文件创建Microsoft 生成引擎 (MSBuild。
  • 创建触发部署过程的 TFS 生成定义。

创建新的团队项目

创建部署逻辑

Matt Hink 使用了解项目文件中所述的拆分项目文件方法创建各种自定义 MSBuild 项目文件。 Matt 创建：

  • 一个名为 Publish.proj 的项目文件，用于运行部署过程。 此文件包含 MSBuild 目标，这些目标在解决方案中生成项目、创建 Web 包并将包部署到目标服务器环境。
  • 特定于环境的项目文件，名为 Env-Dev.proj 和 Env-Stage.proj。 这些设置分别包含特定于测试环境和暂存环境的设置，例如连接字符串、服务终结点以及将接收 Web 包的远程服务的详细信息。 有关为特定目标环境选择正确设置的指导，请参阅 配置目标环境的部署属性。

若要运行部署，用户使用 MSBuild 或 Team Build 执行 Publish.proj 文件，并将 env-Dev.proj 或 Env-Stage.proj) (相关环境特定项目文件的位置指定为命令行参数。 然后 ，Publish.proj 文件导入特定于环境的项目文件，为每个目标环境创建一组完整的发布说明。

注意

这些自定义项目文件的工作方式与用于调用 MSBuild 的机制无关。 例如，可以直接使用 MSBuild 命令行，如 了解项目文件中所述。 可以从命令文件运行项目文件，如 创建和运行部署命令文件中所述。 或者，可以从 TFS 中的生成定义运行项目文件，如 创建支持部署的生成定义中所述。
在每种情况下，最终结果都是相同的 - MSBuild 执行合并的项目文件并将解决方案部署到目标环境。 这为触发发布过程的方式提供了极大的灵活性。

创建自定义项目文件后，Matt 会将其添加到解决方案文件夹，并将其签入源代码管理。

创建生成定义

作为最后的准备任务，Matt 和 Rob 合作为新团队项目创建三个生成定义：

  • DeployToTest。 这会生成 Contact Manager 解决方案，并在每次发生检查时将其部署到测试环境。
  • DeployToStaging。 当开发人员将生成排队时，这会将资源从指定的上一个生成部署到过渡环境。
  • DeployToStaging-WhatIf。 当开发人员将生成排队时，这会对过渡环境执行“what if”部署。

以下各节提供了有关其中每个生成定义的更多详细信息。

要测试的部署

Fabrikam， Inc. 的开发团队维护测试环境，以执行各种软件测试活动，例如验证和验证、可用性测试、兼容性测试以及临时或探索性测试。

开发团队已在 TFS 中创建名为 DeployToTest 的生成定义。 此生成定义使用持续集成触发器，这意味着每次 Fabrikam， Inc. 开发团队的成员执行检查时，生成过程都会运行。 触发生成时，生成定义将：

  • 生成 ContactManager.sln 解决方案。 这反过来又生成解决方案中的每个项目。
  • 如果解决方案) 成功生成， (解决方案文件夹结构中运行任何单元测试。
  • 如果解决方案成功生成并通过任何单元测试) ， (运行控制部署过程的自定义项目文件。

最终结果是，如果解决方案成功生成并通过单元测试，Web 包和任何其他部署资源将部署到测试环境。

最终结果是，如果解决方案成功生成并通过单元测试，Web 包和任何其他部署资源将部署到测试环境。

部署过程如何工作？

DeployToTest 生成定义向 MSBuild 提供以下参数：

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

当团队生成在解决方案中生成项目时，将使用 DeployOnBuild=true 和 DeployTarget=package 属性。 当项目是 Web 应用程序项目时，这些属性指示 MSBuild 为项目创建 Web 部署包。 TargetEnvPropsFile 属性指示 Publish.proj 文件在何处查找要导入的特定于环境的项目文件。

注意

有关如何创建如下所示的生成定义的详细演练，请参阅 创建支持部署的生成定义。

Publish.proj 文件包含生成解决方案中每个项目的目标。 但是，如果正在 Team Build 中执行文件，它还包括跳过这些生成目标的条件逻辑。 这使你可以利用 Team Build 提供的其他生成功能，例如运行单元测试的功能。 如果解决方案生成或单元测试失败，则不会执行 Publish.proj 文件，也不会部署应用程序。

条件逻辑是通过评估 BuildingInTeamBuild 属性来实现的。 这是使用 Team Build 生成项目时自动设置为 true 的 MSBuild 属性。

部署到过渡

当生成满足测试环境中开发人员团队的所有要求时，团队可能需要将同一生成部署到过渡环境。 过渡环境通常配置为尽可能匹配生产环境或“实时”环境的特征，例如，在服务器规格、操作系统和软件以及网络配置方面。 过渡环境通常用于负载测试、用户验收测试和更广泛的内部评审。 生成直接从生成服务器部署到过渡环境。

生成直接从生成服务器部署到过渡环境。

用于将解决方案部署到过渡环境的生成定义 DeployToStaging-WhatIf 和 DeployToStaging 共享以下特征：

  • 他们实际上不会生成任何东西。 当 Rob 将解决方案部署到过渡环境时，他想要部署已在测试环境中验证和验证的特定现有生成。 生成定义只需运行控制部署过程的自定义项目文件。
  • 当 Rob 触发生成时，他使用生成参数来指定哪个生成包含要从生成服务器部署的资源。
  • 不会自动触发生成定义。 Rob 想要将解决方案部署到过渡环境时，手动将生成排队。

这是部署到过渡环境的高级过程：

  1. 过渡环境管理员 Rob Walters 使用 DeployToStaging-WhatIf 生成定义将生成排队。 Rob 使用生成定义参数来指定要部署的生成。
  2. DeployToStaging-WhatIf 生成定义在“what if”模式下运行自定义项目文件。 这会生成日志文件，就像 Rob 正在执行实时部署一样，但它实际上不会对目标环境进行任何更改。
  3. Rob 查看日志文件，以确定部署对过渡环境的影响。 特别是，Rob 希望检查要添加的内容、要更新的内容以及要删除的内容。
  4. 如果 Rob 确信部署不会对现有资源或数据进行任何不需要的更改，则会使用 DeployToStaging 生成定义将生成排队。
  5. DeployToStaging 生成定义运行自定义项目文件。 它们将部署资源发布到过渡环境中的主 Web 服务器。
  6. Web 场框架 (WFF) 控制器同步过渡环境中的 Web 服务器。 这使应用程序在服务器场中的所有 Web 服务器上都可用。

部署过程如何工作？

DeployToStaging 生成定义向 MSBuild 提供以下参数：

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

TargetEnvPropsFile 属性指示 Publish.proj 文件在何处查找要导入的环境特定项目文件。 OutputRoot 属性替代内置值，并指示包含要部署的资源的生成文件夹的位置。 当 Rob 将生成排队时，他使用“ 参数 ”选项卡为 OutputRoot 属性提供更新的值。

当 Rob 将生成排队时，他使用“参数”选项卡为 OutputRoot 属性提供更新的值。

注意

有关如何创建如下所示的生成定义的详细信息，请参阅 部署特定生成。

DeployToStaging-WhatIf 生成定义包含与 DeployToStaging 生成定义相同的部署逻辑。 但是，它包含其他参数 WhatIf=true：

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

在 Publish.proj 文件中， WhatIf 属性指示应在“what if”模式下发布所有部署资源。 换句话说，日志文件的生成方式与部署进行一样，但在目标环境中实际不会更改任何内容。 这使你可以在实际进行任何更改之前评估建议的部署的影响，特别是要添加的内容、将更新的内容和删除的内容。

注意

有关如何配置“what if”部署的详细信息，请参阅 执行“What If”部署。

将应用程序部署到过渡环境中的主 Web 服务器后，WFF 会自动跨服务器场中的所有服务器同步应用程序。

注意

有关配置 WFF 以同步 Web 服务器的详细信息，请参阅 使用 Web 场框架创建服务器场。

部署到生产环境

在过渡环境中批准生成后，Fabrikam， Inc. 团队可以将应用程序发布到生产环境。 生产环境是应用程序“上线”并到达最终用户的目标受众的位置。

生产环境位于面向 Internet 的外围网络中。 这与包含生成服务器的内部网络隔离。 生产环境管理员 Lisa Andrews 必须手动从生成服务器复制 Web 部署包，并将其导入主生产 Web 服务器上的 IIS。

生产环境管理员必须手动从生成服务器复制 Web 部署包，并将其导入主生产 Web 服务器上的 I I S。

这是部署到生产环境的高级过程：

  1. 开发人员团队建议 Lisa 生成已准备好部署到生产环境。 团队建议 Lisa 在生成服务器上的放置文件夹中放置 Web 部署包的位置。
  2. Lisa 从生成服务器收集 Web 包，并将其复制到生产环境中的主 Web 服务器。
  3. Lisa 使用 IIS 管理器在主 Web 服务器上导入和发布 Web 包。
  4. WFF 控制器同步生产环境中的 Web 服务器。 这使应用程序在服务器场中的所有 Web 服务器上都可用。

部署过程如何工作？

IIS 管理器包含一个导入应用程序包向导，使你可以轻松地将 Web 包发布到 IIS 网站。 有关如何执行此过程的演练，请参阅 手动安装 Web 包。

结论

本主题演示了典型的企业级 Web 应用程序的部署生命周期。

本主题是一系列教程的一部分，这些教程提供有关 Web 应用程序部署的各个方面的指导。 实际上，部署过程的每个阶段都有大量的附加任务和注意事项，不可能在单个演练中全部介绍这些任务和注意事项。 有关详细信息，请参阅以下教程：

上一篇