TFS Build - Powershell还是自定义活动？

Question

我知道我可以编写自己的自定义活动（在C＃中）来在构建过程中执行自定义逻辑。我的理解是也可以使用Powershell，但我不确定它适合的位置。我确实理解Powershell用于执行命令行命令，但我如何以及在何处使用它来自定义构建过程？

由于

Answer 1

根据谁负责，决定是否使用Powershell或自定义活动。如果您有一个由构建主服务器（对于TFS）创建的活动，并且因此可以为组织中的所有团队重用，我将创建一个自定义活动。

如果项目团队负责（例如部署脚本），我使用powershell。我创建了一个参数，团队可以在其中输入需要执行部署的powershell脚本的路径。项目团队可以选择在该参数中输入值。项目团队还可以在没有构建主机帮助的情况下自行维护其PowerShell部署脚本。

简而言之：

• 可重复使用的活动：自定义活动
• 仅适用于团队的活动：Powershell

Answer 2

对我来说，powershell是要走的路。以下是我的原因：

1. 脚本独立：

使用此方法可以获得脚本独立性。示例：我有许多在构建（即编译）过程完成后运行的脚本：

• 实例化数据库
• 部署数据库代码
• 部署Web应用程序
• 验证部署
• 运行验收测试

以上所有内容都可以独立启动，调试和测试，无需为新版本排队。

1. Powershell易于使用：

自定义程序集往往会给解决方案带来很多复杂性和瑕疵。示例：从TFS 2010升级到TFS 2012非常痛苦，因为所有构建模板都已损坏。我们不得不重新编译所有自定义程序集，团队中只有一个开发人员知道如何设置TFS Build来运行我们的自定义活动。我最近从构建模板中删除了所有自定义程序集，并且仅使用Powershell。

我已经自定义了我的流程模板，以便在TFS Build完成后调用用户定义的powershell脚本。我通过在构建定义中使用path参数来完成此操作。这个参数只是一个指向脚本的字符串数组。我同意上面的Ewald，TFS没有将构建参数传递给脚本。为了解决这个问题，在我的工作流模板中，我解析了字符串数组中的每个脚本，并用构建参数替换了众所周知的标记 - 例如@（BuildNumber），@（SourcesDirectory）等我认为这是一个非常简单而可靠的解决方案。