时间戳

首页 > 解决方案 > 自动化 TFS 签入和合并的流程和文档

tfs - 自动化 TFS 签入和合并的流程和文档

问题描述

我最近承担了在我们的开发管道中简化和自动化流程的任务，并且我正在寻找其他人关于如何解决类似问题的建议/建议。

我们目前使用 TFS 2019/Azure Devops 和以下分支策略：

Master
└ Major Version 1 QA
└ Major Version 1 Release
└ Major Version 2 QA
└ Major Version 2 Release

我们使用 TFS 中的工作项并将它们链接到更改集到上面的分支。通常，所有工作都在 Master 中完成，并有选择地一个一个或两个版本中的一个或两个版本合并到 QA。

一旦经过测试/验证，这些更改通常会被整体合并到 Release 中，在那里它们会在向公众发布之前进行另一轮测试。

这些合并并不总是集体进行，有时它们会被一一完成，有时更改会从 Main>QA>Release 一次合并（一件事需要三个签入...）。

此外，我们有一个单独的错误跟踪系统，用于从 CSR 收集错误报告，该系统向外部成员（没有 TFS 访问权限的人）提供状态。此设置需要人工将数据从 TFS 复制到外部系统（反之亦然），这是我试图解决的主要低效率问题。

目前，TFS 工作项包含所有注释并提供与特定代码更改的关系。我想将所有内容都移入 TFS 并放弃存在以下挑战和问题的外部系统：

  1. 如何向外部非开发人员提供可搜索的、只读的工作项数据视图？另外，TFS 是否有一个简单的“报告错误”的角色？我觉得这样的东西应该已经存在，但似乎我需要创建或识别与 TFS 集成的东西。
  2. 整体合并更改时，与代码更改的单个工作项关联会丢失。看来这是对 TFS 的长期抱怨，我想我需要单独编写合并脚本以实现自动化。还有其他方法吗？
  3. 考虑到上面的分支策略，对文件的任何更改都需要至少 3 次签入才能使其生效。这是一个好策略吗？其背后的想法是在 Release 分支被冻结时可以不断地添加工作。

附加信息：

我们是一个由 5 名开发人员和 5 名 QA 组成的小型团队，围绕我们的产品构建了 20:1 更大的外部基础架构，这就是我寻求自动化的原因。

感谢您的建议/建议！

标签： tfsautomationazure-devopsbranching-and-merging

解决方案

1. 不推荐在 TFS 中使用。

TFS 并非旨在成为公共错误跟踪器。本地 TFS 使用 Windows AD 进行身份验证。Azure DevOps 服务（云）使用 Microsoft 帐户或组织帐户（由 Azure AD 提供支持）。

除此之外，没有将某些工作项限制给某些用户的概念——任何有权编辑给定区域中的工作项的用户都可以编辑该区域中的所有工作项。

来源链接：TFS 可以用作公共错误报告工具吗？

如果您坚持这样做，更好的方法是借助一些 3rd-party 工具来执行此操作。您可以在这个问题中查看我们的 PG 的Ewald Hofman的答案：处理 TFS 中客户提出的错误

2.你是对的。在 TFS 中，当您合并分支时，生成的变更集会链接到所有合并的变更集。TFS = 不提供在 Merge 对话框中选择关联工作项的选项，我们应该在 Pending Changes 窗口中手动添加工作项，然后单击 Check in 按钮对合并分支执行签入。

您可能需要自定义脚本来实现它。此外，您还可以使用或参考一些 3rd-party 工具/扩展，例如这个——TFS合并工作项插件

3.我们无法判断这是一个好还是坏的策略。如果完全符合您的要求，那就太好了。如果您担心签入时间和变更集的数量。首先，当您合并对 Release 的更改时。通常有多个变更集。如果文件只有很少的更改，则不需要这样做。换句话说，您不必经常签到。您还可以使用搁置集选择待处理的工作，而不需要检查每个更新。

此外，更多选择，您可以参考我们的官方链接： 了解 Team Foundation 版本控制 (TFVC) 的分支策略以及如何选择有效的策略

推荐阅读