如果没有Teamcity，我会将所有内容都放在一个大的.fsx脚本中，而且只是＆＃34;解雇并忘记＆＃34;它。可以为构建创建一个脚本，完成所有工作。
但是当我们将.fsx脚本放入Teamcity时，一切都改变了。 Teamcity具有良好的构建日志和构建步骤功能，但将所有逻辑放入相同的脚本和构建步骤会导致巨大构建日志。
我们在单个.fsx脚本中构建和测试，并且我将把分布式构建放入其中。但现在我不认为这是一个好主意。也许最好将这个构建脚本拆分成几个构建脚本并在几个构建步骤中运行它们？
但是如果需要的话，使用多个脚本在本地运行构建并不太方便，没有Teamcity。或者我们可以为每个任务提供几个小的构建脚本和一个用于本地构建的构建脚本，调用所有这些小脚本。
最佳解决方案是什么？
答案 0 :(得分：2)
这是我的个人意见，而不是“最佳解决方案”：我不会在Teamcity中使用多个构建步骤或构建管道，因为这会导致供应商锁定。
如果您仍然想使用构建管道，那么使用单个构建文件并大量使用FAKE的构建目标和条件依赖项。
if isLocalBuild then
A
==> B
==> C
所以你仍然可以像以前一样在本地运行它。 在TeamCity中定义一个构建管道，在每个构建步骤中只调用一个目标（使用FAKE.exe目标= A）。
答案 1 :(得分：2)
好吧，我想我已经做了类似于@ forki23建议的事情。我已将所有内容放入单个.fsx中，定义了几个彼此不相关的目标链，如下所示：
Clean ==> Build
BuildTests ==> RunTests
SignExes ==> PackDistr
在每个构建步骤中，我都会调用一个＆＃34; leaf＆＃34;目标，即
Step1: fake build.fsx target=Build
Step2: fake build.fsx target=RunTests
Step3: fale build.fsx target=PackDistr
在本地，我创建了几个用于本地构建的.bat个文件，并且我已在这些.bat文件中定义了目标的呼叫顺序。但是我认为使用isLocalBuild值作为@ forki23建议真的会更好。这会使构建逻辑更加封装到单个.fsx脚本中，这太棒了！