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

Question

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

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

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

Answer 1

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

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

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

Answer 2

我执行以下操作：

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

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