1

我的任务是更新公司过时的构建过程。这一切都是在批处理和 perl 脚本中完成的。当前的构建过程是：

  1. 通过 Web 界面安排构建。
  2. 构建服务器将构建过程从队列中移除。
  3. 构建服务器从 TFS 源代码控制中检出所有文件。
  4. 构建服务器运行几个代码注入脚本，在构建之前修改源代码。
  5. 构建服务器更新版本并签署代码。
  6. 构建服务器使用 Visual Studio 编译项目。
  7. 完成后，构建服务器压缩输出并将其放在网络共享位置。

真正困难的部分是代码注入脚本。它们是 3 个修改大量代码的 perl 脚本。它们的设计方式也非常依赖机器。（所以我不能在没有大量修改的情况下将它们放在构建过程中）

我的最终目标是能够在本地开发机器上运行构建过程，并在 TFS 服务器上运行 CI。

在我的搜索中，似乎没有办法在本地机器上模拟 TFS 构建。那么我唯一的选择是在我的 cs.proj 文件中使用构建前/构建后的命令行脚本吗？或者有没有更好的方法在本地机器上进行复杂的构建并在 TFS 上运行相同的构建？

我已经看到在本地机器上使用 TFS 构建定义，但这对我来说似乎有点 hacky。如果没有更好的解决方案，我想这不会是一个可怕的解决方案。

4

1 回答 1

2

我过去曾尝试过自己做类似的事情。不幸的是，由于 TFS 构建工作流所需的一切，没有一个好的方法来解决它。我发现基本上有两种方法可以解决它。

  1. 创建将在服务器和本地上运行的 MSBuild 脚本
  2. 为服务器的本地和自定义活动创建 MSBuild 脚本。

如果您打算或要求您能够在开发人员机器和构建服务器上准确地重现构建，那么我会选择＃1。否则我会选择#2。第二个选项很好，因为这样您就可以在 TFS 工作流程中进行主要构建，这为您提供了许多您需要的对象，并为您提供了一个配置设置的好地方，而无需签出/签入文件来更改构建是如何发生的。

对于任何一种方法，您很可能都必须修改您的 Perl 脚本以接收参数，以说明您必须在系统之间进行的任何自定义。然后，您可以让用户在本地构建的 MSBuild 脚本中传入或默认它们，并将它们设置为 TFS 构建工作流中的参数。因此，如果需要，它们可以很容易地修改。不管采用哪种方法，唯一的好方法是标准化开发人员机器和构建服务器上的设置方式，这样您就不必提供太多定制。

如果您确实选择了第一个选项，那么您可以为 TFS 构建使用 Legacy 构建配置，它支持对所有内容使用 MSBuild 脚本，然后您可以在开发人员和构建服务器之间共享该脚本，但如果有人不小心更改了此脚本，那么它确实冒着破坏构建的风险。

于 2013-09-23T15:59:55.743 回答