5

设置集成服务器时，我对使用多个任务完成构建的最佳方法表示怀疑。最好的办法是把所有的事情都集中在一项大工作上还是做一些小的依赖？

4

7 回答 7

3

你肯定想分解任务。这是 CruiseControl.NET 配置的一个很好的示例，每个步骤都有不同的目标（任务）。它还使用了一个 common.build 文件，该文件可以在几乎没有定制的项目之间共享。

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

于 2008-08-27T12:27:58.113 回答
1

我将 TeamCity 与 nant 构建脚本一起使用。TeamCity 可以轻松设置 CI 服务器部分，而 nant 构建脚本可以轻松完成报告生成方面的许多任务。

这是我写的一篇关于在 CruiseControl.NET 中使用 CI 的文章，它在评论中有一个 nant 构建脚本，可以跨项目重复使用：

与 CruiseControl 的持续集成

于 2008-08-27T12:22:15.957 回答
1

我喜欢的方法是以下设置（实际上假设您在 .NET 项目中）：

  • CruiseControl.NET。
  • 每个单独步骤的 NANT 任务。Nant.Contrib 用于替代 CC 模板。
  • NUnit 运行单元测试。
  • NCover 执行代码覆盖。
  • FXCop 用于静态分析报告。
  • 用于源代码控制的颠覆。
  • 所有开发箱上的 CCTray 或类似设备，以获取构建和失败等的通知。

在许多项目中，您会发现当有人签到时会发生不同级别的测试和活动。有时，这些可能会随着时间的推移而增加，以至于在构建之后很长一段时间，开发人员才能看到他们是否通过签入破坏了构建。

在这些情况下，我所做的是创建三个构建（或者可能是两个）：

  • CI 构建由签入触发，并执行干净的 SVN 获取、构建和运行轻量级测试。理想情况下，您可以将其保持在几分钟或更短的时间内。
  • 一个更全面的构建，可以每小时（如果更改）它与 CI 相同，但运行更全面和耗时的测试。
  • 一个通宵构建，它可以完成所有工作，还运行代码覆盖率和程序集的静态分析，并运行任何部署步骤来构建每日 MSI 包等。

任何 CI 系统的关键在于它需要有机并不断调整。CruiseControl.NET 有一些很棒的扩展，它们记录和图表构建时间等步骤，并让您进行历史分析，因此允许您不断调整构建以保持它们的敏捷性。经理们很难接受一个构建框可能会让你忙碌五分之一的工作时间，只是为了阻止它停止运转。

于 2008-08-27T13:05:02.703 回答
1

我们使用buildbot，将构建分解为离散的步骤。在以足够的粒度分解构建步骤和成为一个完整的单元之间存在平衡。

例如，在我目前的职位上，我们在各自的平台上为我们的每个平台（Mac、Linux、Windows）构建子部分。然后我们有一个步骤（带有几个子步骤）将它们编译成最终版本，最终将出现在最终发行版中。

如果这些步骤中的任何一个出现问题，则很容易诊断。

我的建议是尽可能用模糊的术语在白板上写下这些步骤，然后以此为基础。在我的情况下，这将是：

  1. 构建插件块
    1. 为 Mac 编译
    2. 为 PC 编译
    3. 为 Linux 编译
  2. 制作最终插件
  3. 运行插件测试
  4. 构建中间 IDE（我们必须引导构建）
  5. 构建最终 IDE
  6. 运行 IDE 测试
于 2008-08-27T17:30:39.053 回答
0

我肯定会分解工作。您可能会在构建中进行更改，如果您有较小的任务而不是搜索一个整体构建，那么跟踪问题会更容易。

无论如何，您应该能够从较小的部分创造出一项大工作。

于 2008-08-27T12:24:20.600 回答
0

天，

当您谈论集成测试时，我的大（明显）提示是使测试服务器的构建和配置尽可能接近部署环境。

</thebloodyobvious> (-:

干杯，罗伯

于 2008-08-27T12:43:03.443 回答
0

将您的任务分解为离散的目标/操作，然后使用更高级别的脚本将它们适当地捆绑在一起。

这使其他人更容易理解您的构建过程（您正在记录，以便团队中的任何人都可以拿起它，对吗？），以及增加重用的潜力。您可能不会重用高级脚本（尽管如果您有类似的项目，这可能是可能的），但您绝对可以很容易地重用（即使是复制/粘贴）离散操作。

考虑从存储库获取最新源的示例。您需要将用于检索代码的任务/操作与一些日志记录语句进行分组，并引用适当的帐户信息。这是一种很容易从一个项目重用到下一个项目的东西。

对于我团队的环境，我们使用 NAnt，因为它在开发机器（我们编写/调试脚本的地方）和 CI 服务器（因为我们只是在干净的环境中执行相同的脚本）之间提供了一个通用的脚本环境。我们使用 Jenkins 来管理我们的构建，但每个项目的核心只是调用相同的 NAnt 脚本，然后我们操纵结果（即归档构建输出、标记失败的测试等）。

于 2012-07-11T15:38:34.360 回答