Team Foundation Services 2015 简介





5.00/5 (5投票s)
使用 Team Foundation Services 2015 配置一个简单的构建
引言
最近我写了一篇简短的博客,介绍了我发现 Team Foundation Services (TFS) 2015(也称为 vNext)中构建工具的优点。正如我在那篇文章中所述,我之前对 TFS 中的构建工具并不太热衷。直到我开始使用 TFS 2015 中的构建工具。不同构建工具和版本控制平台之间的集成程度令我非常惊喜。以前版本的 TFS 构建工具只真正支持 Microsoft 生态系统,而 TFS 2015 附带的新构建工具支持各种不同的平台和工具。
本文旨在为任何希望使用 TFS 2015 中构建工具的人,或任何希望将其当前 TFS 用途扩展到仅仅作为版本控制系统 (VCS) 之外的人提供入门介绍。
为了使本文简洁明了,我将为一个网站创建一个简单的构建过程,然后将该网站发布到测试服务器。希望这能提供足够的信息,让您能够将这些想法扩展到您自己的特定构建过程中。
背景
本文假定读者对 Team Foundation Services 和构建软件的基本原理有基本的了解。
入门
首先,您需要在您选择的浏览器中打开您的 TFS 2015 主页。URL 应类似于 http://tfsroot:8080/tfs,您应该会看到类似于下面的屏幕截图。这是 TFS 2015 仪表板。
选择您想要构建的项目,您将看到类似于下面屏幕截图的 TFS 项目仪表板。
通过单击顶部菜单中的 BUILD 菜单项,您将打开构建资源管理器仪表板。您将在这里为当前选定的项目创建构建。
创建我们的构建过程
您会注意到 TFS 2015 的第一件事是其支持的构建平台和工具的数量之多。这可能会使您的第一次构建设置变得相当混乱。如前所述,为了保持简单,我们将为一个简单的网站创建一个构建,该网站还会将该网站发布到测试服务器。
首先,点击菜单下方的加号(+)来创建我们的构建。当您这样做时,您将看到一个像下面这样的对话框。选择 Visual Studio 选项并点击确定。此选项用于选择您打算构建的项目类型。如果您是 Visual Studio 开发人员并正在构建 Visual Studio 解决方案,那么这将是您选择的选项。在本例中,我们正在构建一个 ASP.NET Web 项目,因此我们将选择 Visual Studio 选项。
但请注意 Xamarin 构建模板的选项。显然,如果您正在构建 Xamarin 解决方案,您会选择其中一个。如果使用 Mac,也请注意 Xcode 选项。
选择 Visual Studio 构建选项后,您将看到 Build 菜单。该菜单项用于配置构建的不同部分,包括必要的构建步骤、我们要连接的版本控制仓库(提供 Team Foundation Services 和 Git 选项)、任何所需的构建编号、构建历史记录以及构建应如何触发,即通过持续集成和/或按计划进行。
我们将逐一介绍菜单项,所以让我们从“仓库”菜单项开始。这允许我们配置构建过程将使用的版本控制仓库。如果没有仓库,我们就没有什么可以构建的,所以这似乎是一个很好的起点。
配置仓库
TFS 2015 构建过程主要支持两种仓库类型。要么是 Team Foundation Version Control,要么是 Github,尽管如果您使用 Subversion 作为您的仓库,也提供了支持。出于本文的目的,我将使用 Team Foundation Version Control。根据需要为 Repository type 选择相应的值。
在 Repository name 字段中选择此构建应使用的仓库名称。
选择是否在构建过程中 Clean 仓库。将其设置为 true 会在从仓库中获取代码之前清空签出文件夹。如果您想要一个增量构建过程,请将此值设置为 false,这样可以避免每次调用构建时都获取整个仓库,从而提高构建过程的性能。如果使用 Visual Studio Build 或 MSBuild 选项(稍后会详细介绍),也可以在 Build 选项卡上为 Visual Studio 项目设置 Clean 选项。
映射是您定义哪些文件夹应该包含/排除在构建过程中的地方。要包含一个文件夹,它应该定义为 Map。要将一个文件夹排除在构建过程之外,它应该定义为 Cloak。例如,您可能希望 Cloak 您的文档文件夹,使其不属于构建过程。
构建解决方案
“构建”菜单项是配置构建将执行的步骤的地方。重要的是要理解,构建解决方案可能涉及多个构建步骤,特别是如果我们想要发布该解决方案。当最初面对一个没有定义任何步骤的空白构建时,这可能是一项艰巨的任务,尤其是当有许多不同的构建步骤可供选择时。
从下面的屏幕截图中可以看出,有大量的构建步骤可供选择。对每个步骤的解释超出了本文的范围,只需说无论您的特定构建环境包含什么,都可能有一个合适的选项。
请注意,在左侧您可以选择您感兴趣的构建步骤类型,例如构建、测试、打包、部署等。默认是 构建,但如果您想部署或单元测试您的解决方案,则还有其他选项可供选择。
在构建 Visual Studio 解决方案时,我们有两种关键选项(请记住我们现在保持简单)。Visual Studio Build 和 MSBuild。Visual Studio Build 的功能与您在 Visual Studio 中右键单击解决方案并从上下文菜单中选择 Build Solution 选项完全相同。这显然既简单又方便,并且以很少的复杂性构建解决方案。一个主要区别是,此选项通过自动代表您传递 /p:VisualStudioVersion
来设置 Visual Studio 版本号。这确保了您的构建更有可能成功。如果您想要一个简单且成功的构建,请使用此选项。
MSBuild 选项提供了更大的灵活性,并且不向构建过程提供任何默认参数。因此,构建将只使用您提供的参数。当您有特定需求并希望完全控制构建过程时,此选项非常有用。
对于本文,我打算使用这两个选项。Visual Studio 构建将使我们能够快速轻松地构建解决方案,而无需过多麻烦。然后,我们将使用 MSBuild 选项提供发布解决方案的特定参数。
所以让我们从点击 Add build step... 开始,选择 Visual Studio Build 选项,然后点击右侧的 Add 按钮。现在我们应该看到一个空的 Visual Studio Build 步骤,如下图所示。
提供构建所需的必要信息。这将根据您的构建的具体要求而有所不同,但请参阅下面的示例,其中包含可以输入的信息类型。如果您以前使用过构建过程,特别是如果您以前了解 MSBuild,那么应该很容易弄清楚在哪里需要哪些信息。
- 解决方案 - 提供您要构建的解决方案的名称。可以使用选择器控件选择,该控件将打开当前选定的解决方案。
- MSBuild 参数 - 在此处添加您需要的任何选项。这些参数与您在命令行中运行 MSBuild 时添加的参数相同。例如,根据需要指定任何 Targets、Properties 等。在屏幕截图中,我指定了
Clean
和Rebuild
目标。 - 平台 - 选择您的构建所需的平台,例如
x86
、x64
或any cpu
。 - 配置 - 根据需要将其设置为
release
、debug
或自定义平台。 - 清理 - 勾选此选项以强制构建为每次构建获取仓库的全部内容。换句话说,取消勾选此选项以强制进行增量构建。后者可能会提高性能。
- 启用 - 如果您想快速禁用构建脚本中的某个步骤而无需删除它,这是一个有用的选项。如果您想诊断构建问题并想隔离特定步骤,或者如果您是第一次配置构建并想在此过程中测试特定部分,这会很有用。
- 出错时继续 - 勾选此选项以即使此步骤中发生错误也继续运行构建
- 始终运行 - 勾选此选项可确保即使在另一个步骤中遇到错误,此步骤也始终运行
发布解决方案
我们构建完解决方案的下一步是发布它。为此,我们需要向我们的构建过程添加另一个步骤。我们将使用 MSBuild 步骤来完成此操作。尽管我们也可以使用另一个 Visual Studio Build 步骤来完成此操作,但为了演示目的,我想使用不同的构建步骤。
点击 Add build step...,选择 MSBuild 选项,然后点击右侧的 Add 按钮。
现在我们应该看到一个空的 MSBuild 步骤,如下图所示。您应该注意到这些选项与之前的 Visual Studio Build 步骤的选项相同。
由于这些选项是相同的,我将不再重复它们的定义(参见上面)。但值得重申的是,Visual Studio 版本不会通过 /p:VisualStudioVersion
传递给 MSBuild 步骤,而之前的 Visual Studio Build 步骤会。
发布解决方案时,我们需要确定要发布的项目。我们需要将此项目作为解决方案名称输入到构建步骤中。
我们需要输入的关键信息是 MSBuild Arguments。由于我们现在是发布项目而不是构建它,因此我们需要指定目标 /t:Publish,package
。这将创建必要的构建工件,然后可以将其发布到测试服务器进行测试。
尽管为了清晰起见,屏幕截图中没有指定,但我发现另一个有用的 MSBuild Arguments 是 /p:AutoParameterizationWebConfigConnectionStrings=false
。这是因为 TFS 2015 构建默认情况下会针对不同的环境(例如生产、开发等)对 web.config 进行参数化。添加此参数到构建脚本会禁用此行为。
如果您查看以下文件夹,您将看到已发布的构建工件。
{{Solution}} 文件夹\obj\{{Platform}}\{{Configuration}}\Package\PackageTmp\
- 解决方案 文件夹 - 是您通过 解决方案 输入的项目所在的文件夹
- 平台 - 您为 平台 输入的值
- 配置 - 您为 配置 输入的值
例如 C:\TFSRoot\MySolution\MyProject\obj\any cpu\release\Package\PackageTmp\
此时,我们已经发布了可以部署到我们选择的位置(例如,测试服务器)的构建工件。我们可以通过向我们的构建过程添加另一个步骤来完成此操作。
点击 添加构建步骤...,选择 发布构建工件 选项,然后点击右侧的 添加 按钮。
TFS 2015 可以将我们的构建工件发布到 服务器 或 文件共享。
- 服务器 - 在 TFS 根文件夹下将创建一个名为 artifacts 的文件夹(如果它尚不存在),并在其下创建一个以您指定的 Artifact Name 命名的子文件夹,例如 C:\TFSRoot\artifacts\myprojectartifacts
- 文件共享 - 网络上任何位置的文件共享,并且 必须 使用 UNC 路径指定,例如 \\myshare\mypublishfolder\
您可以创建多个发布构建步骤。创建一个基于 Server 的构建步骤,在服务器上创建已发布构建工件的副本,然后创建一个 File Share 构建步骤,将已发布构建工件复制到您的测试 Web 服务器。
指定构建编号
在 General 菜单项下,您可以指定构建的 Build number format。默认情况下,这将是一个唯一的整数。因此,留空以调用默认行为。要指定不同的构建编号,请使用 Build number format 来进行。您可以使用任何令牌、变量和下划线字符的组合。
与 MSBuild 一样,您需要使用 $
符号并在大括号中包含变量/令牌来为变量和令牌添加前缀,例如 $(BuildID)
是分配给每个构建的内部不可变 ID。
示例令牌
- $(BuildDefinitionName) - 构建定义的名称
- $(BuildID) - 内部不可变 ID
- $(TeamProject) - 团队项目名称
- $(SourceBranchName) - 分支名称,例如 master
示例变量
- $(Build.BuildNumber) - 已完成构建的名称
- $(Build.DefinitionVersion) - 构建定义的版本
- $(Build.Repository.Name) - 仓库的名称
- $(Build.DefinitionName) - 构建定义的名称
这是一篇非常有用的文章,介绍如何在 TFS 2015 中管理版本号。
启用持续集成
最后一步是启用 持续集成,这样每次有代码签入到仓库时,我们的构建步骤都会被触发。这只需在 Triggers 菜单上勾选 Continuous Integration (CI) 复选框。
或者,您还可以配置计划构建。例如,您可能只希望在非工作时间部署到测试服务器,或者每小时运行单元测试(如果它们执行时间较长),并且只在每次签入时运行构建步骤。您可以根据需要配置任意数量的不同构建,并且每个构建都可以有任意数量的步骤来实现所需的目标。
要运行您的构建过程而无需等待签入,只需单击菜单下方出现的 队列构建... 菜单项。这将把您的构建添加到构建队列中,并在下一个可用机会运行它。
后续步骤
到目前为止,我们已经创建了一个构建过程,它在每次签入时构建并发布一个 Web 项目。因此,每次开发人员签入代码时,我们都会自动构建它并将其发布到我们的测试服务器。这非常强大,并且都以最少的麻烦或难度实现。我们还可以用我们的构建做什么呢?
如果您想将已发布的文章复制到特定的 Web 服务器,您可以使用 Powershell 脚本或命令行脚本来自定义您的构建。例如,您可以使用 FTP 来实现此目的。我以前使用过的一个很好的 FTP 客户端是 WinSCP,因为它很容易从构建脚本中自动化。
您可以通过添加以下任何一项来扩展您的构建。
- 单元测试和/或自动化测试
- 设置/拆除数据库
- 配置发布管理构建,例如预生产和生产构建
- 配置额外的构建代理以扩展您的构建过程
摘要
就这些了。TFS 2015 是一个高度可定制、灵活的构建系统,可以与许多不同的构建工具和平台集成。TFS 2015 还有更多功能本文未涵盖。希望这能为您提供足够的信息,让您能够创建自己的构建并将其扩展到我在此处涵盖的范围之外。如果您希望我进一步阐述本文中的任何内容,请随时发表评论。