TFS2010及编译一次策略
我正在尝试在 TFS2010 上实现一次编译策略,我需要一些关于如何执行此操作的信息。在 CI 上,我想编译所有内容(例如调试版本和发布版本)并运行单元测试。在下一个构建定义中,我想在 CI 中编译的同一二进制文件上运行集成测试。构建管道可能类似于以下
签入 ->步骤1 CI:编译+单元测试->第 2 步每晚:集成测试 ->步骤 3 发布:配置和打包
我不确定是否可以从放置位置的另一个团队构建中获取最后成功的构建。当我需要从步骤 1 获取预编译的二进制文件时,这将解决我在步骤 2 中的问题。
有关从另一个构建定义获取最后一次成功构建的一般输入或建议吗?
I'm trying to implement a compile once strategy on TFS2010 and I need a little input on how to do this. On CI I want to compile everything (e.g. debug version and a release version) and run unittest. In the next build definition I want to run the integrationtests on the same sat of binaries compiled in CI. The build pipeline could look like the following
checkin -> Step 1 CI: compile + unittest -> Step 2 Nightly: integration tests -> Step 3 Release: configure and packaging
I'm not sure if it is possible to acquire the last successfull build from another team build from the drop location. This would resolve my problem in step 2, when I need to acquire the precompiled binaries from step 1.
Any general input or suggestions regarding getting the last successful build from another build def?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
可以说,Step 2 Nightly 不是构建定义,它是一个控制台应用程序:
这些操作也可以在高度定制的构建过程模板中进行,其中主要的构建步骤(例如 CreateWorkspace 和 Run MSBuild)被砍掉并重新生成。上述逻辑是手动实现的。
在你的位置,我会选择使用 TFS-SDK 的 C# 控制台应用程序,执行上述操作计划每天启动一次。
编辑
考虑到您的评论,我不明白为什么我的提案会让您远离构建管道。
无论如何,心与心!步骤2的灵魂(至少在我看来)是检索以前成功的构建和构建的放置位置。然后对驻留在此处的二进制文件执行一些操作。
此检索可能类似于以下内容:
检索到放置位置后,您应该能够开始您计划的任何活动。
您需要的所有详细信息都在
buildDetail
中。现在,这可以作为高度自定义的构建过程模板的自定义构建活动运行,或者作为单独的计划控制台应用程序运行。
就我个人而言,我会做后者&将使用 Windows 任务计划程序将其设置为每天在我的构建服务器中执行一次。
Arguably the Step 2 Nightly is not a build definition, it's a console application that:
Those actions can also be made in a heavily customized Build Process Template, where major build steps like CreateWorkspace and Run MSBuild are chopped off & the above logic is implemented by hand.
In your place I would go for a C# console application that uses TFS-SDK, does the above & is scheduled to kick-in once a day.
EDIT
Taking your comments into account, I can't see why my proposal is taking you away from your build pipeline.
In any case, the heart & sould of Step2 (at least in my understanding) is to retrieve the drop location of a former succeeded build & then execute some actions upon the binaries that reside there.
This retrieval could look similar to the following:
Having retrieved the drop location, you should be able to commence whatever activities you have planned.
All details you need are in
buildDetail
.Now, this could run as a custom build activity of a highly customized build process template, or as a separate scheduled console app.
Personally I would do the latter & would set it with Windows Task Scheduler to execute once a day in my buildserver.
一般来说,如果您想为构建提供输入,有两种方法:
将构建 1 的结果复制到正常构建文件夹之外的安全文件夹中。然后,构建 2 将其所需的内容复制回其工作文件夹中。
将构建1的结果签入tfs,为将来的构建获取和使用做好准备。
第二种策略是最好的,因为它意味着每个构建都有二进制输入的历史版本 - 您可以进行历史或分支构建,并且构建系统将使用所有内容的适当版本。
我想到的问题是:为什么要编译一次?对于 CI,您应该以增量构建为目标,这样您就可以尽快扭转构建。对于夜间测试和发布版本,您希望从头开始重建所有内容,而不是依赖增量构建来完美工作(但他们从来没有这样做 - 最终源代码和二进制文件会有点不同步,并且构建会产生损坏的结果,或者无法正常工作)完全的)。
Generally speaking, if you want to provide inputs to a build, there are two approaches :
copy the results of build 1 to a safe folder outside the normal build folder. Build 2 then copies what it needs back into its working folder.
check the results of build 1 into tfs, ready for future builds to get and use.
The second strategy is the best, as it means you have historical versions of the binary inputs for every build - you can do historical or branch builds and the build system will use the appropriate versions of everything.
The question that springs to my mind is: why do you want to do compile-once? For CI you should be aiming for an incremental build so you can turn builds around as quickly as possible. For nightly test and release builds you want to rebuild everything from scratch rather than relying on incremental builds to work perfectly (which they never do - eventually the source and binaries get a bit out of sync and the build produces a broken result, or fails to complete).