Team Foundation Server 2015 发行说明
| | 开发者社区系统要求和兼容性 | 许可条款 | TFS DevOps 博客 | SHA-1 哈希 | 最新 Visual Studio 2019 发行说明
注意
这不是 Team Foundation Server 的最新版。 要下载最新版本，请访问 Team Foundation Server 2018 Update 3 的最新发行说明。 可以更改此页面的语言，具体方法是单击页脚中的地球图标，然后选择所需语言。
本文将介绍 Team Foundation Server 2015 的相关信息。
若要了解有关 Team Foundation Server 2015 的详细信息，请参阅 Team Foundation Server 要求和兼容性 页。
请参阅 TFS 安装页以获取详细信息。
发布日期：2015 年 8 月 6 日
Team Foundation Server 2015 新增功能摘要
SKU 更改：
功能更新：
- 标识控件和虚拟形象
- 任务板：积压工作 (backlog) 和看板中的 Bug
- 产品积压工作 (backlog) 更新
- 冲刺 (sprint) 积压工作和任务板更新
- 自定义和配置您的卡
- 看板更新
- 关闭 CFD 图表上的第一列
- 对过程模板的 SAFe 支持
- 重命名了过程模板
- 当前迭代查询标记
- 查询渐进式公开
- 分支策略
- 分支策略 - 封闭生成
- 分支策略 - 代码评审
- 分支历史记录（推送和拉取请求）
- Git 项目的 Web 历史记录视图
- 快速代码编辑
- 历史记录控件
- 查看文件夹的历史记录
- 生成自动化系统
- 团队项目重命名
- REST API
- 服务挂钩
- 提高了合并性能
- 分配多个测试人员
- 基于云的负载测试
- 自动测试
- API 中的行为更改
Team Foundation Server 2015 中的新增功能的详细信息
扩展了基本许可证
以下功能目前可供具有“基本”许可证的所有 Team Foundation Server 用户使用：
- 基于 Web 的测试执行
- 敏捷项目组合管理
- 工作项图表创作
- 团队聊天室
这意味着：包含具有“基本”许可证的五个或更少成员的所有团队都有权免费使用 Team Web Access 访问这些功能，同时更大的团队可以按低得多的价格访问此功能。
对数据库中架构的更改
Team Foundation Server 2015 包括对其数据库中所用架构的大量更改，因此，从 TFS 2013 和较旧版本进行升级时，预计需要花费很长时间。 由于升级处于离线状态，因此 Microsoft 提供了一个工具 TfsPreUpgrade.exe，该工具可用于针对 TFS 2013 QU4 和 QU5 部署在线执行升级的最耗时部分。 升级向导包含一个准备情况检查，如果数据库足够大，则会向你发出警告，建议运行 TfsPreUpgrade.exe。
Project Server 扩展
Project Server 扩展现在是单独的下载。 有关详细信息，请查看下载页面的 TFS 部分。
SharePoint 扩展
过去，如果你希望 Team Foundation Server 与位于其他计算机上的 SharePoint 实例集成，则可以在 SharePoint 服务器上运行 Team Foundation Server 安装程序，然后配置适用于 SharePoint 的 TFS 扩展，或运行仅放置配置适用于 SharePoint 的 TFS 扩展所需的特殊安装程序 (tfs_sharePointExtensions.exe)。
我们删除了此特殊安装程序，因此，若要将 Team Foundation Server 与 SharePoint 集成，则必须在 SharePoint 服务器上运行 Team Foundation Server 安装程序，然后配置适用于 SharePoint 的 TFS 扩展。
标识控件和虚拟形象
这一新控件包括用户的全名、虚拟形象和电子邮件地址。
我们将此控件设计为可非常直观地进行使用。 将焦点置于该控件时，它首先为你提供最近向其分配工作项的人员的 MRU（最近使用）列表。 如果你寻找的人员不在该列表中，则只需单击“搜索”，该列表便会使用来自你帐户中用户的匹配结果进行填充。 我们不仅提供了新的标识控件，而且我们还重构了许多显示用户名称的位置，以便它现在包括虚拟形象。 你会在工作项、板等位置处的卡上看到虚拟形象。
任务版：积压工作 (backlog) 和看板中的 Bug
我们已使团队能够选择他们是否希望在其积压工作上显示 bug（与过程模板无关）。 我们扩展了此设置的功能。 团队现在可以选择在具有要求（用户情景或产品积压工作项）、任务或完全没有任何内容的积压工作和任务板上显示 bug。
产品积压工作 (backlog) 更新
积压工作 (backlog) 导航更新
我们全面修订了积压工作 (backlog) 的导航。 从每个积压工作 (backlog)，你可以向下钻取更多级别，一直到任务。 此外，从每个积压工作 (backlog) 中，可以使用父筛选器打开或关闭积压工作 (backlog) 以上的级别。 不归团队拥有，但基于关系拉入的项会使用空心颜色条进行显示。 你可以一目了然地区分你的团队拥有的项与其他团队拥有的项。
最后，你可以在每个视图中重新排序和重设父级！ 只需在任何视图中进行拖放即可对项重新排序和更改关系。
选择加入组合积压工作 (backlog) 级别
现在可以关闭团队未使用的积压工作 (backlog) 级别（与导航更新相关）。 在此更新之前，所有积压工作 (backlog) 级别都对每个团队强制执行。 每个积压工作 (backlog) 级别现在都“选择加入”，使你可以配置适用于你的团队的级别。 单击页面顶部的齿轮，选择要配置的团队，然后选择所需的积压工作 (backlog) 级别。
筛选的积压工作中的重新排序
上下文菜单现在提供用于将项移动到顶部或特定位置（即使是在筛选器应用于积压工作时）的选项。
对积压工作和查询进行的文本筛选
现在可以使用我们置于工具栏上的新筛选器文本框，来快速筛选积压工作和查询结果。 只需输入所查找的项中的文本，积压工作 (backlog)/结果便会立即进行筛选，以便仅显示包含匹配文本的那些项。 在较长积压工作 (backlog) 或查询结果中扫描查找特定项（或一组项）时，此功能非常方便。 请注意，匹配是对显示的列中的数据（包括标记）进行的。
冲刺 (sprint) 积压工作 (backlog) 和任务板更新
显示无父级任务
冲刺 (sprint) 中没有父情景的任务现在会显示在冲刺 (sprint) 积压工作和任务板上（在“无父级”类别下）。 无父级行会使用灰色条突出显示。 可以将任务从无父级行移动到任何用户情景中，反之亦然。 （注意：不允许拖放无父级行；它会始终显示在冲刺 (sprint) 积压工作 (backlog) 以及任务板顶部。）
折叠已完成情景
已完成情景会在任务板打开时自动折叠。 默认情况下，冲刺 (sprint) 积压工作 (backlog) 上的所有情景都会折叠。 处于折叠状态、但具有挂起的工作的情景会在任务板上显示警告。 任务板上的折叠行还会针对该用户情景显示挂起的工作的摘要。 而且，任务板上的 PBI 现在会显示为卡（如同任务一样）。
通过添加字段和标记来自定义和配置卡
你不仅可以自定义卡在看板上的显示方式，现在“自定义卡”对话框中还有用于卡上显示的数据的配置选项。
（类似的自定义对话框也可用于任务板。）
可以打开或关闭 ID，选择“分配给”字段的显示方式，然后选择直接在卡上显示标记。 大多数人在每张卡上都需要“标题”和“分配给”这类字段，但将更多的信息引入卡中可节省时间，以便可以对它们执行操作，而无需打开它们以获得更多详细信息。 例如，请注意，我们已将“Priority”和“Severity”添加到了以下 bug 卡：
添加到卡中的自定义字段可直接从板进行编辑。 而且，这些选项是基于团队（或积压工作 (backlog)）并基于工作项的，因此你可以获得最大的灵活性。
看板更新
直接从看板进行添加和编辑
我们更新了所有板以支持添加新卡和直接编辑。 看板现在有一个位于第一列顶部的“新建项”按钮，用于添加新卡。 添加新卡之后，卡上的所有数据可以直接从卡本身进行编辑。 了解有关看板内联添加和编辑的详细信息。
看板上的重新排序
我们实现了对板上的项重新排序。 现在可以在板上每列中按优先级向上和向下移动项。 在板上进行的任何更改也会直接反映在积压工作上。 事实上，进行此更改后，许多人可能会选择使用板而不是积压工作，因为板现在支持添加、内联编辑和重新排序。 了解有关看板重新排序的详细信息。
在看板上显示的所有数据中进行筛选
你现在可以筛选整个板。 在所有板筛选器中输入筛选术语，它会按卡上显示的任何信息进行筛选，包括可能已添加的任何字段、标记 或 ID。 我们还在第一列上提供了一个筛选器，因此你可以在积压工作 (backlog) 中找到该项以拉取到看板上。
看板上的拆分列
我们向看板添加了一个称为“拆分列”的新功能。 看板团队使用拉取模型推动工作穿过板。 为了有效地执行此操作，板上的每个列都拆分为两个子列 —“正在进行”和“完成”。 将卡移动到“完成”列中可提供一个明确信号，表示工作已准备好前进的，并且卡可以由拥有下一个阶段的人员/团队进行拉取。
若要拆分板上的任何列，只需单击工具栏上的“自定义列”链接。
详细了解 看板拆分列。
看板上的泳道
我们添加了使团队可以创建水平泳道以跟踪不同工作类的功能。 典型示例是加速通道。 现在，每个团队都可以创建自己的通道，并使板只以所需方式显示。
看板完成定义
在工作穿过板时，你和你的团队应处于有关“完成”针对每列的含义的相同页上，这至关重要。 此版本引入了一个新功能，它使你可以为板上的每列指定完成定义。 我们甚至支持 markdown，因此你可以设置文本格式或包含指向其他位置的超链接。现在，具有定义的列在标题中包含一个小图标，用于表示定义达成一致。
详细了解 看板 DoD (完成) 的定义 。
关闭 CFD 图表上的第一列
你现在可以省略看板的第一列并获得更有意义的 CFD 图表。 （第一列通常表示团队正在处理的项的较长积压工作 (backlog)，但不是看板上的活跃项。）
为此，请从 CFD 图表中选择“编辑”，然后取消选中“包括首列”复选框。 （请注意，对于所有现有积压工作 (backlog)/CFD 图表，此框在默认情况下处于选中状态。）
对过程模板的 SAFe 支持
我们非常高兴地使用现有 Scrum、Agile 和 CMMI 模板为 Scale Agile Framework (SAFe) 提供内置支持。
对长篇故事的支持
- 我们添加了长篇故事工作项类型和积压工作 (backlog)/板来跟踪长篇故事。 长篇故事的层次结构在功能之上。 功能映射到长篇故事，类似于积压工作 (backlog) 项映射到功能。
- 提供了完整积压工作 (backlog) 和版功能。 你可以像管理任何其他积压工作 (backlog) 一样管理长篇故事积压工作 (backlog)，还可以自定义看板列和卡以满足你的需求。 (默认情况下不启用长篇故事积压工作。若要启用此功能，检查“团队设置”页中的“长篇故事”复选框。)
- 可在团队级别打开或关闭长篇故事积压工作 (backlog)。 根据我们的白皮书，项目组合团队应启用长篇故事积压工作 (backlog)。 如果计划和功能团队不管理组织中的长篇故事，则这些团队可以禁用长篇故事积压工作 (backlog)。
对架构与业务积压工作 (backlog) 的支持
我们已将“值区域”字段添加到积压工作 (backlog) 中显示的所有工作项，即：长篇故事、功能，并且（根据过程模板）该字段还会显示在产品积压工作 (backlog) 项、用户情景和要求上。
“值”区域包含两个值：业务和架构。 默认情况下，所有长篇故事、功能和情景都是业务类型。 若要创建体系结构长篇故事、功能或情景，请将值设置为“架构”。
利用此功能，你可以定义架构长篇故事，这进而会细分为架构功能和情景，使你可以在组织中跟踪架构路线图。
重命名了过程模板
这些模板的名称会从包含版本名（例如，“MSF for Agile Software Development 2013.4”）的详细名更改为仅仅是“Scrum”、“Agile”和“CMMI”。 这些模板现在已锁定，这意味着你无法对已发布的模板进行更改。 若要基于已发布模板创建自定义过程模板，只需导出现有模板，为其提供新名称和版本，然后使用过程模板管理器重新导入它。 现有项目不受此更改的影响，这意味着它们可以继续使用 witadmin 自定义其过程。
当前迭代查询标记
此功能使你可以指定在基于迭代的查询中表示当前迭代的标记。 如你所知，迭代具有与之关联的日期。 在迭代之间移动时，更新用于跟踪下一个迭代的工作的所有查询是非常繁琐的。 此版本添加了一个新查询标记 @CurrentIteration，该标记会基于当天的日期返回当前迭代。 不过对于此新标记存在一些限制。 例如，它在 Excel 中不起作用。 该标记依赖于对团队上下文的了解，遗憾的是，Excel 并不具有确定当前迭代所需的所有信息。 了解有关当前迭代查询标记的详细信息。
查询渐进式公开
现在，大型查询列表不会在每次显示查询窗格时都打开。 仅加载前两个级别，你随后可以按需加载其余级别。
分支策略
为了帮助使用 Git 的团队提高进入其存储库的代码的质量，我们添加了一种对分支设置策略的新功能。 使用这些新策略，团队可以为在推送或合并拉取请求时服务器强制实施的开发分支配置要求。 通过使用生成策略来要求进入分支的所有更改都必须传递配置的生成，可以防止生成中断。 你还可以使用代码评审策略为拉取请求设置最少审阅者数量，甚至要求特定用户评审对基本代码的特定部分进行的更改。
分支策略 - 封闭生成
Git 项目现在可以设置分支策略以要求先成功生成，然后才能将任何代码提交到分支中。 启用生成策略会要求使用拉取请求将更改提交到配置的分支中，拉取请求的完成会在配置的生成成功时封闭。
分支策略 - 代码评审
Git 项目现在可以设置分支策略以对任何提交到分支中的代码进行代码评审。 为某个分支启用代码评审策略会强制所有代码都必须使用拉取请求提交到该分支。 这些策略提供用于要求最少数量的代码审阅者以及针对特定路径和/或文件类型要求特定审阅者的选项。
分支历史记录（推送和拉取请求）
在 Web 门户中，“代码”下的历史记录中心已更新为支持用于 Git 项目的新视图。 新的“分支更新”视图显示用于给定分支的所有更新，并按推送和拉取请求活动对提交进行分组。 此视图使开发人员可以通过新的方式深入了解其 Git 存储库随时间进行更新的方式，并提供从历史记录到拉取请求的可跟踪性。
Git 项目的 Web 历史记录视图
代码历史记录中心有一个新视图：分支更新。 此视图只能用于 Git 项目，会显示给定分支的所有更新，并按推送和拉取请求活动对提交进行分组。 此视图还使开发人员可以通过新的方式深入了解其 Git 存储库随时间进行更新的方式，并提供从历史记录到拉取请求的可跟踪性。
快速代码编辑
在此版本中，我们添加了以下功能：直接从 Web 浏览器对处于版本控制中的文件进行快速编辑，然后将这些更改直接提交回服务。 浏览源文件时，你现在可以使用将文件置于编辑模式的编辑命令。 随后可以采用内联方式进行更改（包括颜色编码和格式设置支持）。 你单击保存命令时，我们会立即使用你的更改创建新的提交/变更集。 使用差异视图可在提交更改之前精确查看所进行的更改。 如果文件是标记或 HTML 文件，则你还可以在保存它们之前预览更改。
你不仅可以编辑文件，我们还添加了直接从 web 添加、删除和重命名文件的功能。 若要添加新文件，请右键单击存储库中的文件夹，然后选择
“添加文件”，输入签入/提交注释，你已准备就绪。 你只是为了重命名或删除文件而必须下载整个基本代码的日子已经一去不复返。
新的编辑功能还会显示在欢迎中心中，从而使你可以轻松地为项目创建文档。 如果没有 README.md 文件，则可以从模板指南开始，并提交自己的文件。
我们还实现了根据语法创建指向现有（或新）markdown 文件的链接的功能。 如果页面不存在，请不要担心，因为当你单击链接（wiki 样式）时，可以编辑并提交新文件。
利用这些新功能，我们希望你可以轻松快速地创建和编辑项目文档！
了解有关快速代码编辑的详细信息。
历史记录控件
我们优化了历史记录控件以便更易于阅读讨论。 具体而言，我们减少了所需垂直空间，这样你便可以更快地到达要查看的讨论，我们是在未减少功能的情况下完成此工作的。
查看文件夹的历史记录
现在，可以在解决方案资源管理器、“更改”页或“提交详细信息”页中右键单击任何文件夹，便会获取对该文件夹中文件进行的更改的历史记录。
生成自动化系统
Team Foundation 2015 包括我们的新生成自动化系统。 若要了解有关新生成系统的详细信息，请单击消息标题中的链接（在“生成”选项卡中）。
团队项目重命名
我们实现了重命名团队项目的功能。 所有版本控制路径、工作项、查询和其他团队项目生成工件都会更新以反映新名称。 团队项目可以重命名多次，旧名称也可以重复使用。
详细了解重命名团队项目。
REST API
这是将 REST API 引入本地 TFS 的第一个版本。 JSON REST API 实现了一种从几乎任何设备、平台或技术堆栈（包括 Windows、Android、iOS、Node.js 及其他）使用 Team Foundation Server 的轻量级方式。 可以创建和查询工作项、对生成进行排队、获取最新团队聊天室消息、访问源代码以及完成几乎任何团队或代码管理任务。
服务挂钩
可以使用服务挂钩在 Team Foundation Server 中发生事件时立即通知应用或服务。 借助服务挂钩，应用或服务可以避免持续轮询以检查是否存在更改，如已完成的生成、提交/签入或工作项更改。 现在可以创建功能强大的集成方案，其中 Team Foundation Server 可以在发生更改时通知另一个服务，从而可将这两个服务一起使用。 可以在项目管理中找到作为新中心的服务挂钩。
服务挂钩的工作原理：服务挂钩订阅控制在发生特定类型的事件时对外部目标服务执行的操作。 与电子邮件警报订阅类似，服务挂钩订阅与创建它的用户相关联。 当事件发生并且服务挂钩尝试将配置的订阅与事件匹配时，会执行权限检查，以确保创建订阅的用户有权访问与事件关联的资源。 例如，用户（可能是项目管理员）可创建一个在所有“工作项已创建”事件时触发的服务挂钩订阅。 当在此用户无权访问的区域路径下创建新工作项时，权限检查会阻止订阅匹配，从而可避免通过此订阅发送任何外部通知。
但是，由于通过服务挂钩可以方便地与外部服务（如 Trello 或 Campfire）集成，因此你应确保订阅创建者有权访问的数据不可供可能没有相同访问级别的其他用户使用。 例如，定义为将所有“代码推送”事件发送到 Campfire 房间的订阅可能会导致将信息错误地泄露给无权访问与事件关联的存储库的用户（但能够查看信息，因为他们有权访问 Campfire 房间）。
提高了合并性能
我们改进了合并性能，这在大型存储库上尤为明显。
分配多个测试人员并邀请他们进行测试
如果在你的方案中必须邀请多个签字认可所有者运行同一组测试用例，则你现在可以向测试套件分配多个测试人员。 这样做会选取测试套件中的每个测试用例，并为添加到测试套件的每个测试人员都创建测试。 还可以发送电子邮件来邀请他们运行测试。 当测试人员单击电子邮件中的“查看测试”链接时，测试计划会打开，其中包含分配给该测试人员的测试的筛选列表。
基于云的负载测试
我们宣布推出用于在新生成系统中运行基于云的负载测试的新功能。 有两个部分：基于云的负载测试和基于云的 Web 性能测试：
list-style-type：无；
- 基于云的负载测试使你可以将现有负载测试项目作为 CI/CD 管道的一部分来执行。
- 基于云的 Web 性能测试使用在任务本身中配置的基本负载测试参数针对应用 URL 执行简单负载测试。
自动测试
我们宣布推出用于在生成计算机上运行单元测试的新功能，功能自动化在远程计算机上运行，可将测试结果作为新生成系统的一部分进行浏览。 可在此博客中阅读更多详细信息。
现在有两个测试任务 - Visual Studio 测试（VSTest 任务）和使用测试代理的 Visual Studio 测试（VSTest 远程任务）。
- VSTest 任务在生成计算机上本地运行测试，通常你只会使用此任务运行单元测试。
- VSTest 远程任务使用测试代理以分布式方式在远程计算机上运行测试，你可以运行功能测试、单元测试或 UI 测试。
此外，我们宣布推出计算机中心以及测试中心内的“运行”选项卡。
- 计算机中心。 你会使用计算机中心创建和管理远程计算机。
- “运行”选项卡。测试中心内的此选项卡充当用于系统中所有测试结果的单个存储库。 你不仅能够从 VSTest 和 VSTestRemote 任务浏览自动测试结果，还可以从旧工作流（如 XAML 生成和生成-部署-测试工作流）进行浏览。 此外，可以选择利用 REST API 发布测试结果，从而将发布测试结果集成到自定义任务中。 “运行”中心当前支持查询测试运行和测试结果、分配所有者以测试失败、跟踪分析以及归档 bug。
API 中的行为更改
适用于 IProcessTemplates.AddUpdateTemplate 方法的 API 的名称、说明和元数据参数值现在已由 zipFileName 中指定的过程模板数据重写。 此更改的原因是为了避免 ZIP 文件中的内容与作为参数传递给 API 的内容之间出现冲突。
以下屏幕截图显示在 ProcessTemplate.xml 中定义这些属性的位置。
Bug 修复和已知问题
有关该版本中的技术改进、Bug 修复和已知问题的完整说明，请参阅以下知识库文章。
我们做得怎么样？
我们期待你的宝贵意见和建议！ 可以通过开发者社区门户报告并跟踪问题，并能在 Stack Overflow 上了解相关建议。 和以往一样，若要向我们提供反馈意见，告诉我们要优先开展哪些工作，请前往开发者社区，添加反馈意见或为现有反馈意见投上一票。