使用 Team Foundation Build Server 部署 Web 应用程序 – 第 1 部分

引言

本文介绍了使用 Team Foundation Server 进行自动化 Web 部署。它提供了从安装到配置再到部署的分步指南。

我想指出，我使用了最简单的配置向导来配置 TFS 并接受了默认设置，这对于本次演示目的来说是没问题的。一般来说，TFS 的设置简单明了，但我想尽可能地保持其简单性。

接受默认设置还意味着 **Team Foundation 应用程序服务器**在 **NT AUTHORITY/LOCAL SERVICE** 帐户下运行，而 **构建服务**在 **NT AUTHORITY/System** 帐户下运行。在生产（域）环境中，最佳实践是为两者创建具有最低可能权限的独立服务帐户（例如，应用程序服务器使用 tfs_app，构建服务使用 tfs_build）。

另一个重要信息是，为了本次演示目的，我将所有内容都安装在一台机器上——SQL Server、Team Foundation Server、构建服务。此外，我们还将 Web 应用程序及其数据库部署/发布到同一台机器上——所以我们将使用安装 TFS 的同一台机器上运行的 SQL Server 和 IIS。

使用的产品：Windows Server 2008 R2、SQL Server 2008 R2、Team Foundation Server 2010、Visual Studio 2012。

Content

1. Team Foundation Server – 安装和配置
2. 构建/部署先决条件安装
3. 从 Visual Studio 2012 连接到 Team Foundation Server
4. 创建新的团队项目
5. 将源代码添加到 TFS 源代码管理
   1. 如何确保我们的解决方案在源代码管理中
   2. 签入解决方案
6. 创建新的构建定义
7. 部署 Web 应用程序 – 触发手动构建
   1. 问题 1
   2. 问题 2
   3. 检查已发布的 Web 应用程序
   4. 部署已发布 Web 应用程序的新版本

Team Foundation Server - 安装和配置

让我们运行 TFS 安装程序。在安装向导的功能选择页面，选择所有组件，如下图所示。

Team Foundation Server – 源代码控制（工作项跟踪、版本历史维护）

Team Foundation Server Proxy – 在本地缓存文件 = 更少的带宽，提高性能（通常安装在远程位置）

Team Foundation Build Service – 自动化构建。最佳实践是将此功能安装在不同的服务器上，但为了简单起见，我们将它安装在与 Team Foundation 应用程序服务器相同的机器上。

产品安装成功完成后，点击 **配置** 以启动 TFS 配置向导。

TFS 配置向导出现，我们将在这里配置 **Team Foundation 应用程序服务器**和 **Team Foundation 构建服务**。您可以从多个配置向导中选择——选择最适合您需求的向导。

对于我们的需求，**基本**向导就足够了（这是最简单的设置选项），因此选择 **基本** 并点击 **启动向导**。**基本配置向导**出现——在这里您只能设置 SQL Server 实例。您可以选择 **安装 SQL Server Express**，或者如果您已经安装了某个版本的 SQL Server（支持 Standard 和 Enterprise 版本），则可以选择 **使用现有 SQL Server 实例**。

我已经在同一台机器上安装了 SQL Server（Team Foundation Server 所在机器），所以我选择了第二个选项。

在下一个向导页面中指定 **SQL Server 实例名称**。点击 **下一步** 完成向导，如果通过所有验证检查（在就绪性检查页面），点击 **配置**。

配置进度完成后，点击 **下一步**

配置结果页面出现——在这里您可以看到 **配置结果**、**Team Foundation Server** URL 和 **Web 访问** URL，如下图所示。点击 **关闭** 完成向导。

现在，您应该再次看到 **配置中心**。点击 **配置 Team Foundation 构建服务**，然后点击 **启动向导**，启动配置构建服务的向导。

“构建服务配置向导”出现 - 在每个向导页面上单击“下一步”并接受选定的默认值。它将此计算机设置为构建机器，配置构建控制器和构建代理。

重要的是要了解 **每个构建控制器都专用于单个团队项目集合**。更多信息请参阅 此 MSDN 文章。

现在让我们看看我们在 **TFS 管理控制台**中进行的配置

点击 开始 – 所有程序 – Microsoft Team Foundation Server 201x – Team Foundation Administration Console

出现 **Team Foundation Server 管理控制台**，您可以在其中管理所有配置设置。

在 **应用程序层** 下，**团队项目集合** 中有一个 **DefaultCollection**，它是在配置 TFS 应用程序服务器时由配置向导创建的。如下图所示，此集合中没有 **团队项目**。我们将在本教程的后面使用 Visual Studio 创建一个团队项目。

构建/部署先决条件安装

为了能够使用 Team Build Service 构建您的 Web 应用程序，它必须拥有您的 Web 项目所需的所有 .targets 文件。TFS 的安装不包括所有必要的文件，因此您有 2 种选择

1. 在安装 TFS 的同一台机器上安装 Visual Studio

或者

2. 将文件夹 %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v10.0（如果您使用 Visual Studio 2012，则为 v11.0）从您的开发机器复制到 Team Build Server 上的相同位置

我们希望我们的 Web 应用程序不仅能由 TFS 构建服务构建，而且还能部署/发布——所以我们必须安装 **Web Deploy 3.5**。Web 应用程序将使用 **.NET Framework 4.5**，所以我们也必须安装它（两者都在安装 TFS 的机器上）

1. 下载并启动 **Web 平台安装程序**：http://go.microsoft.com/?linkid=9805118
2. 在 **Web Platform Installer 5.0** 顶部，点击 **产品**
3. 在导航窗格（左侧）中，点击 **框架**
4. 在 **Microsoft .NET Framework 4.5** 行，点击 **添加**（如果 **.NET Framework 4.0** 尚未安装，也在该行点击 **添加**）
5. 在导航窗格中，点击 **服务器**
6. 在 **Web Deploy 3.5** 中，点击 **添加**
7. 点击 **安装**

从 Visual Studio 2012 连接到 Team Foundation Server

1. 打开 **Visual Studio 2012**，并在启动页面点击 **连接到 Team Foundation Server**（或者首先点击顶部菜单中的 **团队**）
   
   “连接到 Team Foundation Server”对话框打开。
2. 如果您的 TFS 未在服务器下拉列表中列出，请点击 **服务器...**，然后点击 **添加**
3. 输入安装 TFS 的机器的名称或 IP 地址，然后点击 **确定**。
   然后系统会提示您输入凭据。
   

   注意：我使用管理员帐户连接到 TFS。我在此帐户下安装并配置了 TFS，因此它也设置为 TFS 管理员。对于真实环境，这绝对不好。因此，请确保为适当的用户设置适当的权限。

   我们已经连接到 TFS。中间是项目集合（我们只有一个 `DefaultCollection`），左下角是您用于连接 TFS 的用户帐户名。
4. 点击 **连接** 按钮

创建新的团队项目

在与 Team Foundation Server 建立连接后，您应该在 Visual Studio 的右侧（在 **Team Explorer 选项卡**中）看到您已连接到指定 TFS 的 **DefaultCollection**。

如果您没有打开 Team Explorer 或不小心关闭了它，您可以通过点击顶部菜单中的 **视图** 和 **Team Explorer** 来将其重新打开。

现在我们将在 DefaultCollection 中创建一个团队项目

1. 在 **Team Explorer 选项卡**中点击 **DefaultCollection**，选择 **项目** 并点击 **新建团队项目...**
2. 在出现的 **新建团队项目** 向导的第一页上，输入 **项目名称**（如果需要，还可以添加描述），然后点击 **下一步**
3. 选择您想要用于创建此团队项目的 **流程模板**，然后点击 **下一步**（模板的解释超出了本教程的范围——只需接受所选的默认值）
4. 在 **指定源代码控制设置** 中接受默认值，点击 **下一步**
5. 查看您所做的设置，然后点击 **完成** 以创建团队项目
6. 项目成功创建后，您应该在向导的最后一页看到消息。然后点击 **关闭**
   
7. 检查 **Team Explorer 选项卡**——您应该已连接到刚刚创建的团队项目（在我的示例中是 **FirstProj**）
   

将源代码添加到 TFS 源代码管理

现在是时候打开您想要添加到源代码管理并稍后自动构建和部署的 Web 应用程序的源代码（或创建一个新的——我的情况）。

所以，请打开您的 Web 应用程序项目/解决方案或创建一个新的。我创建了一个名为 **TFSTest** 的 **ASP.NET MVC 4 Web 应用程序**（Internet 应用程序模板，**不带** 单元测试项目）。

要将您的源代码添加到源代码管理，您需要

1. 右键单击 **您的解决方案名称**（在 **解决方案资源管理器选项卡**中），然后选择 **将解决方案添加到源代码管理...
   **
2. **将解决方案 <解决方案名称> 添加到源代码管理** 对话框打开——接受默认值，点击 **确定**

解决方案已添加到源代码管理。

如何确保我们的解决方案在源代码管理中

1. 您可以在解决方案中（在 **解决方案资源管理器选项卡**中）每个项目旁边看到一个小加号

或者

1. 转到 **Team Explorer 选项卡**，点击 **源代码管理资源管理器**
2. **源代码管理资源管理器**在 Visual Studio 中间打开——在这里您可以浏览添加到源代码管理中的解决方案
   在这里，您也可以在每个项目旁边看到加号。这意味着，项目已添加到源代码管理，但尚未签入。

签入解决方案

1. 右键单击 **您的解决方案名称**（在 **解决方案资源管理器选项卡**中），然后选择 **签入...**
2. “挂起的更改”出现（在 Team Explorer 中）——您可以在此处输入签入注释，然后单击“签入”按钮
   
3. “签入确认”对话框打开 - 点击 **是** 以确认签入
   
   
   现在您的解决方案已添加到源代码管理并已签入。在解决方案资源管理器中，您可以在每个项目旁边看到一个小锁。
   
   

创建新的构建定义

构建定义指示 TFS

• 什么操作触发构建
• 要编译哪些项目
• 放置文件夹位置（构建副本和包应存放在哪里）
• 应该运行哪些测试

1. 在 **Team Explorer 选项卡**（在 Visual Studio 中）中，如果处于 **Team Explorer 的主页选项卡**，则点击 **构建**
   
   
   如果您不在 **主页选项卡** 上，只需单击项目名称（在我的情况下是 **FirstProj**），然后单击 **构建
   
   **
2. **Team Explorer** 中的 **Build tab** 打开，点击 **New Build Definition**
3. **构建定义对话框** 打开 – 为此构建定义输入一个名称（或保持不变），如果需要，还可以添加描述
   
4. 点击 **触发器**，然后选择最适合您需求的触发器——它指示 TFS 在哪个操作上触发构建。对于我们的演示，我将使用 **手动触发器**，所以稍后我们将看到如何操作。
5. 点击 **源设置** – 在这里您可以指定要构建的内容 = 源代码管理中的哪个工作文件夹
6. 点击 **构建默认值** – 在这里您可以指定要用于此构建定义的控制器，以及构建输出应复制到的文件夹的 UNC 路径
   
   如果您希望将构建输出复制到某个文件夹，请创建该文件夹并确保它具有正确的权限，以便 TFS 构建可以写入其中。在我们的例子中，构建在 **SYSTEM** 帐户下运行，正如我们在 **Team Foundation Server 管理控制台** – **构建配置** – **构建服务属性** 中所看到的。
   

7. 点击 **过程** – 我想说，这是构建定义中最重要的配置部分。我们希望部署成为构建的一部分，因此我们必须将适当的参数传递给 **MSBuild 参数**。不幸的是，没有用于配置 TFS Web 发布的漂亮界面 – 我们必须知道这些参数及其可能的值，才能根据我们的喜好实现 Web 应用程序的部署。
   因此，为了实现我们的目标——构建解决方案/项目，创建其包（zip 文件），将 Web 应用程序部署/发布到 localhost，我们需要使用以下参数
   
   /p:DeployOnBuild=True;DeployTarget=MSDeployPublish;CreatePackageOnPublish=True;MSDeployPublishMethod=InProc;MsDeployServiceUrl=localhost;DeployIisAppPath="Default Web Site/TFSTest";VisualStudioVersion=11.0;UserName=
   
   无论您是像上面那样编写参数，还是像这样编写参数，都无关紧要
   
   /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=InProc /p:MsDeployServiceUrl=localhost /p:DeployIisAppPath="Default Web Site/TFSTest" /p:VisualStudioVersion=11.0 /p:UserName=
   
   
   让我们稍微解释一下这些论点
   
   DeployOnBuild – True = 成功构建后部署
   
   DeployTarget – MSDeployPublish = 使用 **Web Deploy** 发布（我们已作为先决条件安装）
   
   CreatePackageOnPublish – True = 在发布前创建一个包（包含所有正确运行 Web 应用程序所需文件的 zip 文件）。包可以作为部署历史记录（您已发布内容的存档）。您可以在我们在创建构建定义时在步骤 6 中指定的放置文件夹中找到它们。
   
   MSDeployPublishMethod – 告诉使用何种部署方法，InProc = 本地部署 – 部署到与构建服务在同一台机器上运行的 IIS
   
   MsDeployServiceUrl – 指示应用程序应部署到哪个服务器，localhost = 与构建服务运行的同一台机器
   
   DeployIisAppPath – 指定在 IIS 中发布的位置（IIS 站点名称/应用程序名称），Default Web Site/TFSTest = 将发布到 Default Web Site（它是 IIS 站点名称），应用程序名称将为 TFSTest
   
   VisualStudioVersion – 告知我使用的 Visual Studio 版本，11.0 = 告知我正在使用 Visual Studio 2012，因此 MSBuild 将在 %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v11.0 中查找 .targets 文件，而不是 ...\v10.0（Visual Studio 2010），这是我使用 Team Foundation Server 2010 时的默认值。
   
   UserName – 是具有访问权限的域\用户，可以访问我们要发布应用程序的 Web 服务器。如果您不提供用户名（我们的情况），您将使用 Windows 身份验证。
   
   Password – 是上述用户的密码。在我们的情况下，我们使用了 Windows 身份验证，所以我们根本不需要提供此参数。
   
   
   在远程服务器上部署
   如果您想将应用程序部署到远程 IIS（在与构建服务运行的机器不同的机器上运行），您的 MSBuild 参数应如下所示
   
   /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl=ServerName /p:DeployIisAppPath="Default Web Site/TFSTest" /p:VisualStudioVersion=11.0 /p:UserName=
   
   或者
   
   /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=WMSVC /p:MsDeployServiceUrl=https://ServerName:8172/MsDeploy.axd /p:DeployIisAppPath="Default Web Site/TFSTest" /p:VisualStudioVersion=11.0 /p:UserName=
   
   请注意，在这些场景中，您也必须在远程服务器上安装 **Web Deploy** 工具。

8. 点击工具栏中的 **保存图标**（在 Visual Studio 中）以保存刚刚创建的构建定义
9. 创建的构建定义（在我们的例子中是 **TFSTest**）出现在 **Team Explorer** **选项卡** 的 **构建** 下**

部署 Web 应用程序 - 触发手动构建

在创建构建定义时，我们将触发器设置为手动，因此手动调用构建是我们唯一的选择。

1. 右键单击 **构建定义名称** 并选择 **队列新构建...**
2. “队列构建”对话框打开 - 接受默认值并点击“队列”
3. 在 **Team Explorer** 中，您可以看到一个 **新构建** 已 **排队** – 双击它会打开一个对话框以查看构建的进度和结果
   

问题 1

我们的第一次构建因以下错误而失败

原因

我们的 Web 应用程序（如果您像我一样创建它）使用 **.NET Framework 4.5**。这意味着应用程序运行的应用程序池需要 **.NET Framework 4.0**。由于我们使用了 *Default Web Site*，其应用程序池（*DefaultAppPool*）默认使用 **.NET Framework 2.0**，因此我们遇到了这个错误。

分辨率

将 *DefaultAppPool* 的 .NET Framework 更改为 4.0

现在您可能会问自己——为什么我们要将应用程序池更改为 4.0 而不是 4.5，因为我们的 Web 应用程序使用的是 4.5？原因是目前没有 4.5 应用程序池。您可以在 4.0 应用程序池中运行任何 4.5 应用程序。.NET Framework 4.5 是一个就地更新，而不是一个新的主要版本。

1. 在您想要部署应用程序的服务器上，转到 *开始* – *管理工具* – *Internet 信息服务 (IIS) 管理器*
2. **IIS 管理器控制台**打开 – 点击 **应用程序池**，双击 **DefaultAppPool**，选择 **.NET Framework v4.0.30319**，点击 **确定**

​如果您在下拉列表中没有 **.NET Framework v4.0.30319**，请运行以下命令以安装/注册 .NET Framework 版本
"%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i" – *开始* – *运行* 并粘贴此命令，不带引号。

现在重复步骤 1、2 和 3，再次调用新构建。

问题 2

如果您像我一样创建了同名（TFSTest）的 Web 应用程序，您可能会遇到另一个错误。

原因

构建部分成功——应用程序已构建并发布，但在尝试测试应用程序时，构建过程遇到了上述错误——MSTest 加载所有程序集试图查找任何单元测试。原因是我们在创建 **构建定义**（**过程** **选项卡**）时接受了 **自动化测试** 的默认设置，并且我们的 Web 应用程序名称包含单词“test”。

这意味着 MSTest 将递归搜索所有程序集，并两次找到我们的 *TFSTest.dll*。

分辨率

将 **Automated Tests** 的属性更改为 *\*test*.dll 以禁用递归搜索。

1. 右键单击 **构建定义名称**（**Team Explorer 选项卡** – **构建**）并选择 **编辑构建定义...**
2. “构建定义”打开，点击“过程”并通过点击“...”打开“自动化测试”属性
3. **自动化测试** 属性打开，点击 **编辑** 并将 ***\*test*.dll* 更改为 **\*test*.dll*，然后点击 **确定** 和 **确定
   **
4. 点击工具栏中的 **保存图标**（在 Visual Studio 中）以保存修改后的构建定义

现在，再次通过重复步骤 1、2 和 3 来调用新的构建。

正如我们在构建进度对话框中看到的，构建现在已成功。

检查已发布的 Web 应用程序

1. 转到您刚刚发布 Web 应用程序的服务器（在我们的例子中，它是安装 TFS 的同一台服务器）
2. 打开 *Internet 信息服务 (IIS) 管理器*，如我们在 *问题 1* 中所做
3. 在 **连接** 窗格中展开 **站点** 和 **默认网站** – 如您所见，我们的 Web 应用程序以 **TFSTest** 的名称发布，正如我们在 MSBuild 参数中指定的那样
   
4. 要检查应用程序是否工作，点击 **TFSTest**，然后点击 **IIS 管理器** 右侧 **操作** 窗格中的 **浏览 *:80 (http)**
5. **Internet Explorer** 打开，我们看到了我们的 Web 应用程序
6. 您可以在我们创建构建定义时指定的放置文件夹中找到由构建服务生成的应用程序包
   在指定共享放置文件夹所在的服务器上打开 **Windows 资源管理器**（在我们的例子中仍然是同一台机器），然后找到 **Drops** 文件夹——在其中您不仅可以找到包（zip 文件），还可以找到包含应用程序设置和部署参数的 2 个 XML 文件以及一个用于部署的 Windows 命令脚本 (.cmd)。

部署已发布 Web 应用程序的新版本

现在我们将更改例如 Web 应用程序中的一些文本，这样我们就可以看到更改，将新解决方案签入源代码管理，调用手动构建并检查它是否在 IIS 中成功更新。

例如，我们可以更改主页上的这段文本

1. 在 **解决方案资源管理器** 中，展开项目 **TFSTest** – **视图** – **共享**，然后双击 **_Layout.cshtml** – 这就是我们在 Web 窗体应用程序中称之为主页面的内容
   
2. 将文本“**your logo here**”更改为例如“**This is my logo**” – 当您开始编写时，项目会自动为您签出以进行编辑
3. 右键单击 **_Layout.cshtml**，选择 **签入...**，将其签入源代码管理**
4. 如果需要，输入注释，点击 **签入**，并通过点击 **是** 确认签入对话框 - **_Layout.cshtml** 已签入源代码管理
5. 调用手动构建（与我们之前做的完全一样）
6. 成功构建后，检查 Web 应用程序——与我们之前的方式相同，或者如果您尚未关闭 Internet Explorer，只需点击刷新按钮（或按 F5）
7. 正如我们所见，我们的 Web 应用程序的新版本已发布

结论

自动化 Web 部署是 Team Foundation Server 的一个很棒的功能。如果有一个漂亮的构建定义创建用户界面，那么设置它就不会那么简单。我希望有人会发现这篇文章有用。我尝试尽可能详细地描述整个过程。如果您有任何问题或发现任何重要信息缺失，请随时回复。

在下一部分中，我们将讨论如何设置数据库部署。

历史

2014 年 7 月 8 日 - 初始版本