关于自动化：自动执行TFS签入和合并的流程和文档


Automating processes and documentation for TFS checkins and merges

我最近承担了简化和自动化开发流程中流程的任务，并且我正在寻找其他人对类似问题进行处理的建议/建议。

我们当前使用的是TFS 2019 / Azure Devops，其分支策略为：

1
2
3
4
5
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并放弃存在以下挑战和问题的外部系统：

  • 如何为外部非开发人员提供工作项数据的可搜索只读视图？从理论上讲，TFS是否具有简单的"报告错误"角色？我觉得类似的东西应该已经存在，但是似乎我需要创建或识别与TFS集成的东西。
  • 在合并更改时，将丢失单个工作项与代码更改的关联。看来这是对TFS的长期抱怨，我想我需要单独编写合并脚本以实现自动化。还有其他方法吗？
  • 考虑到上述分支策略，对文件的任何更改都需要至少3个签入才能进入世界。那是个好策略吗？其背后的想法是，可以在冻结"发布"分支的同时连续添加工作。

    • 其他信息：

    我们是一个由5个开发人员和5个质量检查人员组成的小型团队，围绕我们的产品构建了20：1的大型外部基础架构，这就是我希望实现自动化的原因。

    谢谢您的建议/建议！

    1。在TFS中不建议使用此方法。

    TFS is not intended to be a public bug tracker. On-prem TFS uses
    Windows AD for authentication. Azure DevOps Service(cloud) uses
    Microsoft accounts or Organizational accounts (backed by Azure AD).

    Beyond that, there is no concept of restricting certain work items to
    certain users -- any user who has access to edit work items in a given
    area can edit all work items in that area.

    Source Link: Can TFS be used as a public bug reporting tool?

    如果您坚持要执行此操作，则更好的方法是借助某些第三方工具来执行此操作。您可以看一下我们的PG Ewald Hofman的答案：处理客户在TFS中引发的错误

    2。您是正确的。在TFS中，当您合并分支时，结果变更集将链接到所有合并的变更集。 TFS =不提供在"合并"对话框中选择关联工作项的选项，我们应在"签入更改"窗口中手动添加工作项，然后单击"签入"按钮在合并分支上执行签入。

    您可能需要自定义脚本才能实现。此外，您还可以使用或引用一些第三方工具/扩展名，例如TFS合并工作项插件

    3。我们无法断定这是好是坏的策略。如果完全符合您的需求，那就很好。如果您担心变更集的签入时间和数量。首先，当您合并对Release的更改时。通常有多个变更集。如果对文件的更改很少，则无需执行此操作。换句话说，您不必经常检查。您也可以选择具有架子集的待处理工作，而无需检入每个更新。

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