3

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

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

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

4

2 回答 2

3

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

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

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

于 2013-07-25T05:39:55.027 回答
0

我执行以下操作：

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

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

于 2013-07-23T15:25:18.473 回答