部署组和生成完成触发器 - VSTS 冲刺 132 更新
Visual Studio Team Services (VSTS) 的 Sprint 132 更新提供了一些关键功能，可帮助你缩放生成和发布管道。 在 “生成”中，使用新的生成完成触发器将可能由不同团队拥有 的相关生成链接在一起 。 在 发布中，我们宣布部署 组正式发布，可用于跨具有高可用性的多个虚拟机（包括生产环境）缩放部署。
其他要点包括：
VSTS 中的新增功能
功能
代码
生成和发布
程序包
Wiki
报表
代码
使用提交消息快速描述拉取请求
编写描述性提交消息可任何 Git 存储库的历史记录增加价值。 为了鼓励编写高质量提交消息，具有多个提交的新拉取请求 (PR) 要求参与者手动输入标题。
拉取请求描述在默认情况下会继续为空，但通过一个新功能可更轻松地将来自 PR 提交的提交消息合并到 PR 描述中。 若要添加提交消息，只需单击添加提交消息以将提交消息追加到 PR 描述文本末尾。
从 Windows 资源管理器中直接执行 TFVC 命令
TFVC Windows Shell 扩展提供集成到 Windows 文件资源管理器中的轻型版本控制体验，现在支持 VSTS 和 TFS 2018。 此工具可直接在 Windows 资源管理器的上下文菜单中方便地访问许多 TFVC 命令。
该工具以前是 TFS Power 工具的一部分，现已在 Visual Studio Marketplace 上作为独立工具发布。
生成和发布
使用的生成完成触发器将相关生成链接在一起
大型产品具有多个相互依赖的组件。 这些组件通常独立生成。 当上游组件（例如库）发生更改时，下游依赖项必须重新生成并重新验证。 团队通常手动管理这些依赖项。
现在可以在一个生成成功完成时触发另一个生成。 上游生成生成的项目可以在以后的生成中下载和使用，还可以从以下变量中获取数据：Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName。 有关详细信息，请参阅 生成触发器 文档。
此功能的优先级基于当前第 2 位得票数最高的建议（票数为 1，129 票）。
请记住，在某些情况下，单个 多阶段生成 可以满足你的需求。 但是，如果要求包括不同配置设置、选项或拥有依赖进程的不同团队，则生成完成触发器十分有用。
使用部署组将部署缩放到 VM
部署组现已正式发布，提供可靠、现成可用的多计算机部署。 使用部署组，可以安排跨多台服务器进行部署，并执行滚动更新，同时确保整个应用程序的高可用性。 也可以在本地对服务器进行部署或在 Azure 或任何云中对虚拟机进行部署，此外，对向服务器级别部署的项目版本具有端到端可跟踪性。
基于代理的部署功能依赖已使用的相同的生成和部署代理。 在部署组阶段，可以在目标计算机上使用完整的任务目录。 从扩展性角度来看，也可以为部署组使用 REST API 和为编程访问使用目标。
共享部署目标
如果使用同一服务器来托管多个应用程序，则可以使用部署池跨团队项目共享服务器 (也称为部署目标) 。
新模板
现在，使用新的发布定义模板可以轻而易举地部署到多个目标。 现成提供了用于 IIS 网站的多个模板、带数据库的 IIS 网站和用于 SQL DB 的多个部署模板。
预配 VM
使用增强的 Azure 资源组任务在 Azure 上新预配或预先存在的虚拟机上动态启动代理。
当我们在去年 5 月推出部署组时，我们发布了一个针对几个关键方案的简单用户界面。 现在，你将找到一个更一致的界面，它感觉与产品的其余部分类似。
有关入门的详细信息，请参阅 部署组 文档。
生成以 Go 编写的应用程序
现在，可以在 VSTS 中生成 Go 应用程序！
使用 Go 工具安装程序任务可动态安装一个或多个版本的 Go 工具。 此任务获取项目所需的特定版本 Go 工具，并将它添加到生成代理的路径。 如果代理上已安装了目标 Go 工具版本，则此任务会跳过下载并再次安装它的过程。
Go 任务可帮助下载依赖项、生成或测试应用程序。 还可以使用此任务运行所选择的自定义 Go 命令。
使用任务扩展扩展发布入口
发布入口 将运行状况信号信息直接引入发布管道。 入口在部署之前或之后重复收集一组运行状况信号，以确定发布是否应进入下一阶段。 提供了一组内置入口，到目前为止，建议使用 “调用 Azure 函数 ”选项来集成其他服务。
现在，入口可以采用扩展的形式，这使你（或扩展作者）能够更轻松地集成新的或自定义服务并配置入口。
有关详细信息，请参阅 创作入口任务 文档。
程序包
在 VSTS 中从其他位置使用上游 npm 包
我们将继续投资上游源，使你能够将所有包依赖项集中到单个源中，并保留你使用的所有包的已保存副本。 如果有多个包含 npm 包的 VSTS 源，现在可以在同一 VSTS 帐户中添加一个源作为另一个源的上游源。 由于 npm 主要限制项目配置中的单个源/注册表，因此上游源使你能够灵活地使用多个 npm 源，例如每个团队或产品一个源。
我们还致力于尽快为 VSTS NuGet 源启用上游源。 有关详细信息，请参阅上游源文档。
使用保留策略保持源查询速度
随着时间的推移，包版本的数量可能会变得很大，旧版本将不可用。 对于频繁发布包的作者来说，这可能会导致 NuGet 包管理器和其他客户端中的源查询速度较慢，除非手动删除某些版本。
现在可以对源启用保留策略。 一旦满足保留阈值，保留策略将自动删除最旧版本的包。 升级到视图的包将无限期地保留下来，从而能够保护在生产中使用的版本或在组织中广泛使用的版本。
要启用保留策略，请编辑源并在“保留策略”部分中的“每个包的最大版本数”中输入一个值 。
Wiki
将 Git 存储库中的 Markdown 文件发布为 Wiki
开发人员为代码存储库中的“API”、“SDK”和“解释代码的帮助文档”创建文档。 读者随后需要筛查代码以找到正确文档。 现在，只需从代码存储库发布 Markdown 文件并将其托管在 Wiki 中。
在 Wiki 中，首先单击将代码发布为 wiki。 接下来，可以指定 Git 存储库中应提升的文件夹。
单击“ 发布”后，所选文件夹下的所有 Markdown 文件都将发布为 Wiki。 这还会将分支的标头映射到 wiki，以便可立即反映对 Git 存储库进行的任何更改。
如果产品有多个版本，并且想要轻松浏览这些版本的文档，还可以使用不同的分支将新版本的文档发布到 Wiki。
发布 Markdown 文件后，页面也可以在 Wiki 搜索中心进行搜索。
如果发布了错误的存储库，只需取消发布 Wiki，这会使基础存储库保持不变。
还可以更改存储库中页面的顺序，甚至可以将文件夹转换为类似于 Wiki 页面。
有关详细信息，请参阅 产品文档博客文章 。 此功能已根据建议设置优先级。
保留 Wiki 页面标题中的特殊字符
现在，可以使用特殊字符（例如 : < > * ? | -）创建 Wiki 页面。 现在，可以在 Wiki 中创建标题为“常见问题解答”或“设置指南”的页面。 以下字符会转换为其 UTF-8 编码字符串：
| 字符 | 编码字符串 |
|---|---|
| : | %3A |
| < | %3C |
| > | %3E |
| * | %2A |
| ? | %3F |
| | | %7C |
| - | %2D |
此功能已根据建议设置优先级。
使用 REST API 扩展 Wiki
Wiki REST API 现已公开。 有关详细信息，请参阅 Wiki 函数 和 Wiki 搜索 文档。
报表
使用视图将 Power BI 与 VSTS Analytics 集成
分析视图适用于 VSTS Power BI 数据连接器。 它们共同提供了一种将 VSTS 数据引入 Power BI 的简单方法，以便你可以开始创建自定义报表。
安装 VSTS Analytics 扩展时，我们将创建一组可在 Power BI 中开始使用 的默认分析视图 。 现在，可以编辑默认视图并 创建新视图 ，以微调返回到 Power BI 的记录、字段和历史记录。
后续步骤和反馈
我们很想听听你对这些功能的看法。 如果你对希望我们确定优先顺序的事情有想法，请通过反馈菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获取社区的建议和问题解答。
此致
Gopinath Chigakkagari