持续集成与夜间构建答案

【问题标题】：Continuous Integration vs. Nightly Builds持续集成与夜间构建
【发布时间】：2010-09-29 20:23:11
【问题描述】：

阅读this 的帖子让我感到疑惑；每晚构建比持续集成更好吗？答案的共识似乎很不平衡地支持持续集成，这是传福音还是当持续集成是一种选择时，真的没有理由使用夜间构建吗？

【问题讨论】：

根据答案，问题在某种程度上演变为“除了持续集成之外的夜间构建？”

标签： build-process continuous-integration

【解决方案1】：

如果您真的要与所有可用测试进行持续集成，那么每晚构建将是多余的，因为当天检查的最后一项内容已经经过测试。

另一方面，如果您的 CI 制度只涉及运行所有可用测试的子集，例如因为您的某些测试需要很长时间才能运行，那么您可以另外使用 nightlies 来运行 all强>测试。这样可以让你及早发现很多 bug，如果不能早发现，至少可以在一夜之间发现。

不过，我不知道这在技术上是否仍然是 CI，因为您每次都只是在进行“部分”构建，而忽略了一些测试。

【讨论】：

应用程序可能具有可能会中断的外部依赖项，知道何时发生这种情况会很有用。还有一些耗时的任务，例如代码分析或性能测试，可以使用按需版本控制来运行，但这可能需要一段时间。如果每天都在开发，那么 CI 服务器可以处理其中的大部分，但有时由于假期、其他项目、谈判等原因，开发会停止一段时间。
对于更大的开发，“夜间构建”也可以具有比“CI 构建”更广泛的范围。典型的 CI 只构建一个开发线（“分支”），通常在本地 PC 上。每天晚上，所有变化都在哪里建立。例如，用于许多平台和/或产品和/或配置的所有功能分支。通常在更受控的构建环境中。

【解决方案2】：

在我们的组织中，夜间构建和 CI 构建有两个不同的目的。 CI 构建是一个“最新代码”构建，其中单元测试按照您所期望的最后一次签入运行。我们还在 CI 构建上运行了几个代码指标。

但是，对于每晚构建，我们只包含已通过同行评审流程并被视为已准备好进行测试的源代码。

这样，夜间构建始终包含“功能准备就绪”以进行测试的构建，而 CI 构建包含功能（在单元测试通过的情况下）可能尚未准备好发送到测试的功能组。

测试组专门从夜间版本之一编写新的 CR，而不是 CI 版本，尽管这些也可用于非正式的探索性类型测试。

【讨论】：

您如何区分功能就绪代码和正在积极开发的代码？这两个分支是否在存储库中，并且 cl 代码在成为“功能就绪”时被合并到“功能就绪”分支？
我也喜欢这个；但我认为您应该澄清 VCS 方面如何实现“功能就绪”的这种分离。

【解决方案3】：

是的，如果您有一个想要附加到构建的进程，但它会占用大量资源。例如，在我的团队中，我们在夜间构建期间运行 JTest。我们不能在白天运行它，因为：

需要大量资源，可能不可用
每次完成需要 4 小时

【讨论】：

在这种情况下，您能否进行连续构建，然后在计划的夜间构建期间运行 JTest？

【解决方案4】：

如果您有一个很好的健壮 CI 流程，“夜间”仍然有用。

如前所述，“夜间”构建可以进行详尽的测试，也许还可以进行一些高级系统测试。端到端的东西。
组织中的每个人都容易理解“夜间”构建的概念。如果您在将 CI 构建与其他组（例如，QA 组在敏捷方面的处理能力与开发组可能不同）交流时遇到困难，“夜间”是一个强大而简单的概念。
如果您的 nightly 是一组单独的资源，则可以单独管理它并用于剪切“黄金”图像，并声称具有软件完整性。例如，开发人员编写代码，一些开发人员无法接触的可信构建系统构建它，QA 测试黄金构建并对其进行签名。在这种情况下，夜间构建功能类似于生产构建系统。

只是一些想法。

【讨论】：

【解决方案5】：

在我的专业意见中，使用夜间构建的唯一原因是构建过程需要很长时间以致无法在“合理”的时间内完成。

例如，如果您的构建过程需要 5 小时才能完成，那么确实没有理由在签入时进行构建。

除此之外，在构建失败时尽快知道它是否会覆盖其他问题非常有价值。

【讨论】：

“合理”并不一定意味着很多小时。这意味着在签入之间不够快，无法可靠地完成。如果一天通常有五六次签到，那么任何超过两个小时的事情对于 CI 来说显然是太多了。

【解决方案6】：

这取决于每个构建的目的和长度。基本上，您应该确定您想从 CI 中学习什么，并决定是否值得将资源用于运行多个构建。

在我上一份工作中，我们出于几个不同的目的使用了持续集成。

首先，我们使用它来确保存储库以及开发人员始终拥有已编译的代码版本。对于团队成员来说，没有什么比通过注释、取消注释、还原和合并来管理另一个人的破坏性更改更糟糕的了，因为一个人签入了错误的代码。为此，我们有一个无需测试或其他验证即可立即运行的构建，因此我们可以尽快知道代码是否可以安全更新。构建通常需要大约 10 分钟，并且机器在正常工作日可能运行大约 50%。这里没有生成任何文档，只是安静的通过或响亮的失败警报。

其次，我们想尽快知道是否违反了任何规则。越快发现违规规则，就越容易修复。为此，我们有一台单独的机器来运行代码的完整构建和验证。这台机器在正常工作日每天连续运行 12-14 小时。已发送构建的电子邮件状态，描述损坏的单元测试、代码合规性等。

就自动触发的构建而言，我们停在那里。在此基础上的夜间构建对我们来说似乎有点极端。但我想如果您想每天存档快照构建，您可能需要安排第三次构建，其中包含所需的额外步骤。虽然，我们确实有另一个构建，它封装并存档了我们的 QA 部署工件，以便快速轻松地部署，但我们只是手动触发了那个。

【讨论】：

【解决方案7】：

我认为其他帖子涵盖了常见原因，例如构建过程需要“太长时间”或在 CI 构建期间必须只运行一部分测试。但还有另一个政治原因。

在某些组织中，官方构建由响应最小的构建/基础架构/发布管理/SCM 团队处理。在这些情况下，您可以让他们负责夜间构建，然后在开发之外运行 CI 构建。这样可以避免争吵，因为他们的构建仍然是“官方构建”，而您的 CI 构建会为您提供所需的反馈。

【讨论】：

【解决方案8】：

我们有持续集成和夜间构建。它们有两种不同的用途。

我们的持续集成机制在持续集成套件下构建软件并运行单元测试。

我们的夜间构建在版本控制下标记源代码，构建软件，在夜间构建套件下运行单元测试。然后将这里构建的软件用于各种系统测试和压力测试。

我认为夜间构建的主要区别之一是系统测试。

【讨论】：