测试 TFS 构建定义的最佳实践

Question

我搜索了高和低*，以寻找在 TFS 中测试构建定义更改的良好教程或最佳实践。在进行更改时，我不想淹没构建代理，但更重要的是，我不想继续创建包和向开发人员发送电子邮件，尤其是在构建失败时。

是否有开发和测试构建定义的最佳实践，以免干扰现有开发？

*问题是当你同时搜索“test”和“build”时，一切都是关于在构建中设置单元测试。

Answer 1

在我们的构建团队中，我们目前正在使用以下流程来推出构建流程模板的更新：

1. 创建一个专门用于此目的的测试构建定义。（我们称之为“TestBuild”）。
   • 克隆您将为其扩展构建过程模板的现有构建定义。
   • 或者：创建一个新的构建定义
   • 将触发器设置为仅手动
2. 或者（如果您有权限这样做）您可以设置测试构建定义的权限以对您的用户隐藏它们。
   • 在构建的安全页面中关闭继承。
   • 明确允许您或您的团队查看此构建定义，其他人不得查看
3. 在您的 VCS 中的某个位置创建一个文件夹，您可以将现有的生产构建过程模板分支到该文件夹​​中。
   • 我在 $/Project/Infrastructure/Users/d3r3kk/ 下有一个文件夹用于此类工作。
   • 将您的工作文件夹放在任何地方，确保它是在您签入时不会引发构建的地方
4. 将现有的构建过程定义分支到您的工作文件夹中并检查它以进行编辑。
5. 编辑构建过程定义的工作副本。
6. 完成功能后检查您的编辑。
7. 如果您还没有，请将您的 TestBuild 构建定义设置为使用工作副本构建过程模板，并模仿您的生产构建使用的工作区设置。
8. 从第 5 步开始重复，直到您获得正确的功能。

如果您或您的团队担心在迭代此类功能工作时必须执行多次签入，请在完成后删除+销毁工作副本，或者（更好）只是将工作副本放入一个没有人经常注意的文件夹。由于用于编辑构建过程的编辑/签入过程是 TFSBuild 中固有的，因此实际上无法绕过此类工作将导致的 VCS“噪音”。

Answer 2

我执行以下操作：

1. 创建特定于分支的构建定义。
2. 创建培训 TFS 项目/位置。我认为这是一种极端的处理方式。除非 TFS 中有大量可用空间，否则不要这样做。

我将创建新的构建定义/XAML 并将其添加到新分支。使用新的 XAML 副本创建新的生成定义，然后测试更改。