没有Teamcity,我会将所有内容都放在一个大的.fsx脚本中,然后“解雇”。可以有一个单独的脚本来完成所有工作。
但是,当我们将.fsx脚本放入Teamcity时,一切都变了。Teamcity具有不错的构建日志和构建步骤功能,但是将所有逻辑放入同一脚本和构建步骤中会产生巨大的构建日志。
我们已经在单个.fsx脚本中进行了构建和测试,我也打算将分布式构建放入其中。但是现在我不认为这是个好主意。也许最好将此构建脚本拆分为多个构建脚本并在多个构建步骤中运行它们?
但是使用多个脚本,如果需要,在没有Teamcity的情况下在本地运行构建不太方便。或者,对于每个任务,我们可以有几个小型构建脚本,而本地构建的一个构建脚本将调用所有这些小型脚本。
最好的解决方案是什么?
这是我个人的观点,而不是“最佳解决方案”:我不会在 Teamcity 中使用多个构建步骤或构建管道,因为这将导致供应商锁定。
也就是说,如果您仍然想使用构建管道,则使用单个构建文件并大量使用 FAKE 的构建目标和条件依赖项。
if isLocalBuild then
A
==> B
==> C
Run Code Online (Sandbox Code Playgroud)
所以你仍然可以像以前一样在本地运行它。在 TeamCity 中定义一个构建管道,该管道在每个构建步骤中仅调用一个目标(使用 FAKE.exe target=A)。
| 归档时间: |
|
| 查看次数: |
478 次 |
| 最近记录: |