【问题标题】:How to better split FAKE build script for Teamcity如何更好地拆分 Teamcity 的 FAKE 构建脚本
【发布时间】:2014-06-20 15:42:03
【问题描述】:

如果没有 Teamcity,我会将所有内容都放入一个大的 .fsx 脚本中,然后“一劳永逸”。有一个构建脚本来完成所有工作是可以的。

但是当我们将 .fsx 脚本放入 Teamcity 时,一切都变了。 Teamcity 有很好的构建日志和构建步骤功能,但是将所有逻辑放到同一个脚本和构建步骤中会产生 HUGE 构建日志。

我们在单个 .fsx 脚本中构建和测试,我也打算将分布式构建放入其中。但现在我不认为这是一个好主意。也许将这个构建脚本拆分成几个构建脚本并在几个构建步骤中运行它们会更好?

但是有几个脚本,在本地运行构建不太方便,如果我们需要的话,不用 Teamcity。或者,我们可以为每个任务设置几个小的构建脚本,以及一个用于本地构建的构建脚本调用所有这些小脚本。

什么是最好的解决方案?

【问题讨论】:

    标签: teamcity f#-fake


    【解决方案1】:

    这是我个人的意见,并不是“最佳解决方案”:我不会在 Teamcity 中使用多个构建步骤或构建管道,因为这会导致供应商锁定。

    也就是说,如果您仍想使用构建管道,请使用单个构建文件并大量使用 FAKE 的构建目标和条件依赖项。

    if isLocalBuild then
      A 
      ==> B
      ==> C
    

    所以你仍然可以像以前一样在本地运行它。 在 TeamCity 中定义一个构建管道,它在每个构建步骤中仅调用一个目标(使用 FAKE.exe target=A)。

    【讨论】:

      【解决方案2】:

      好吧,我想我已经做了类似于@forki23 建议的事情。我把所有东西都放在了一个.fsx中,定义了几个彼此不相关的目标链,像这样:

      Clean ==> Build
      BuildTests ==> RunTests
      SignExes ==> PackDistr
      

      在每个构建步骤中,我都会调用一个“叶子”目标,即

      Step1: fake build.fsx target=Build
      Step2: fake build.fsx target=RunTests
      Step3: fale build.fsx target=PackDistr
      

      在本地,我创建了几个.bat 文件用于本地构建,并在这些.bat 文件中定义了目标的调用顺序。但我想按照@forki23 的建议使用isLocalBuild 值真的会更好。这将使构建逻辑更加封装到单个 .fsx 脚​​本中,这很棒!

      【讨论】:

        猜你喜欢
        • 2015-01-27
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-05-22
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多