【发布时间】:2012-01-19 07:29:10
【问题描述】:
我正在尝试在 TFS2010 上实现一次编译策略,我需要一些关于如何执行此操作的输入。在 CI 上,我想编译所有内容(例如调试版本和发布版本)并运行 unittest。在下一个构建定义中,我想在 CI 中编译的同一个二进制文件上运行集成测试。构建管道可能如下所示
checkin -> Step 1 CI:compile + unittest -> Step 2 Nightly:集成测试 -> Step 3 Release:配置和打包
我不确定是否可以从放置位置的另一个团队构建中获得最后一个成功的构建。当我需要从第 1 步获取预编译的二进制文件时,这将解决我在第 2 步中的问题。
关于从另一个构建定义中获取最后一个成功构建的任何一般性意见或建议?
【问题讨论】:
-
仅供参考,如果基于配置的构建之间存在显着差异,则此类事情将不起作用。例如,在 Web 应用程序中使用 web.config 转换,您希望构建不同的配置,因为它们会产生不同的配置设置。
-
另外,您的 CI 构建和发布构建之间真的存在一对一的映射关系吗?通常“n”个 CI 构建最终会为 QA 生成“m”个构建,这些构建会产生“1”个发布到生产环境。
-
出于同样的原因,我们不使用 web.config 转换。配置要么在打包应用程序时进行,要么在安装时进行。至于流水线的想法,当然不是1-1的映射。我想要实现的是,我测试 en dev、devtest、qa 等的二进制文件也是使用或发送给用户的二进制文件。这样我就可以自信地说发布包和这些确切的二进制文件已经被测试了。由于 TFS 的性质,似乎最常用的范例是在构建管道的每个步骤/阶段进行编译。
-
我以前也有同样的感觉,但我相信每次构建中都会构建所需的代码,这应该会产生相同的二进制文件,更多或少。 “或多或少”的部分是我可能决定我希望 QA 和生产版本之间的设置略有不同。
-
我同意它们应该是一样的,但是为什么每次都编译呢?我们有什么收获吗?关于配置,我们不会在编译时这样做。我们要么切换配置文件,要么在部署期间对其进行转换(MSBuild),或者让 WiX 在安装时配置设置。
标签: tfs build-automation