TFS 构建过程工作流中的自定义活动、脚本或项目？

Question

目前我正在将 TFS 2012 更新到 2013。我的计划是使用默认的构建过程模板并尽可能坚持下去。现有的构建定义使用带有 TFSBuild.proj 文件的旧 TFS 方法。在这些 proj 文件中，一切都会发生。初始化解决方案目录、构建、清理、运行单元测试、删除文件等。与 2013 年构建过程模板相比，这是不正确的，因为工作流具有构建、清理、运行测试、删除文件等活动。以及它似乎 TFSBuild.proj 文件中使用的目标文件是以前的 TFS 版本，尚未更新到 2013 版本。

问题在于，除了构建、清理、运行测试和放置文件活动之外，还需要其他活动。在某些文件中更改版本号、混淆 dll、检查源是否不包含任何不需要的文件的过程、压缩 pdb 文件等。

当然可以使用 PowerShell 脚本执行这些任务/活动。另一方面，在项目文件中处理任务似乎也是合乎逻辑的。我对在项目文件中执行额外任务的担忧是，在调用 MSBuild 活动之后，TFS 正在运行测试、删除文件等活动。

有人能指出我正确的方向吗？我是否需要可以在构建过程模板中使用的自定义开发活动？还是使用 PowerShell 脚本的最佳实践？

Answer 1

我想你已经回答了你自己的问题！ Poweshell 是前进的方向！

我会说，只有当 powershell 不适合您，或者您的脚本变得如此庞大且难以调试以至于将它们转换为代码时才应考虑修改 XAML 和编写自定义活动.正如您所提到的，其中一些任务需要在 MSbuild 活动完成后很好地执行，这样就行不通了。

您似乎想在流程中的定义点执行一些相当简单的步骤，而 Powershell 可扩展点非常适合此操作。

在预构建步骤中用于版本控制的简单脚本。检查不需要的文件的来源也可以在这里进行。

混淆、压缩和复制内容可能会在测试后发生。

从可维护性的角度来看，我会说 powershell 的用户群比 Windows Workflow 和 MSBuild 大得多，因此这是这种方法的另一个优势。