2013-09-23 167 views
1

我一直负责更新公司过时的构建过程。它全部在批处理和perl脚本中完成。目前的构建过程如下:TFS构建和本地构建

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

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

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

在我的搜索似乎没有办法模拟本地机器上的TFS生成。那么我的唯一选择是在我的cs.proj文件中使用pre/post-build命令行脚本吗?还是有更好的方法在本地机器上执行复杂的构建,并在TFS上运行相同的构建?

我看过Using TFS build definitions on a local machine,但这对我来说似乎有点不好意思。如果没有更好的解决方案,我想这不是一个可怕的解决方案。

回答

2

我曾试图在过去自己做类似的事情。不幸的是,由于TFS构建工作流程需要的一切,所以没有一个好方法可以解决这个问题。我发现基本上有两种方法可以解决这个问题。

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

如果您有意或者要求您能够在开发人员计算机和构建服务器上完全重现构建,那么我会选择#1。否则,我会去#2。第二种选择是好的,因为那样你就可以在TFS工作流程中进行主要构建,为你提供许多你需要的对象,并给你一个很好的地方来配置设置,而不必检出/更改文件来改变构建如何发生。

对于任何一种方法,您最有可能必须修改Perl脚本以引入参数来说明系统之间必须执行的任何自定义操作。然后,您可以让用户将这些内容传入,或者将它们默认放在MSBuild脚本中用于本地构建,并将它们设置为TFS构建工作流程中的参数。因此,如果需要,可以轻松修改它们。不管采用哪种方法,唯一的好办法就是标准化开发人员机器和构建服务器上需要设置的东西,以便您不必提供定制化功能。

如果你选择第一个选项,那么你可以使用Legacy构建配置TFS构建支持使用MSBuild脚本的一切,然后你可以在开发人员和构建服务器之间共享脚本,但如果有人意外更改这个脚本就会冒着破坏版本的风险。

+0

感谢您的回答。我认为我的游戏计划将会是1和2的混合体。我将创建一套通用的MSBuild脚本,这些脚本是应用程序基本构建所需的。这些常用脚本将在服务器和本地上运行。这将允许开发人员在本地机器上构建和调试应用程序。然后我将拥有一些只能在服务器上运行以进行发布类型任务的自定义活动。 (版本更新和代码签名等)除MSBuild脚本之外,还将运行这些脚本。 –