持续集成与夜间构建

Question

阅读this帖子让我感到疑惑;对于一种情况而言，夜间建筑是否比持续整合更好？答案的共识似乎是偏向于持续整合，是传福音还是在没有理由使用夜间构建时，持续整合是一种选择？

Answer 1

如果你真的在与所有可用的测试进行持续集成，那么夜间构建将是多余的，因为那天检查的最后一件事已经过测试。

另一方面，如果您的CI制度仅涉及运行所有可用测试的子集，例如因为您的某些测试需要很长时间才能运行，那么您可以使用夜间运行全部测试。这可以让你及早发现许多错误，如果你不能及早发现它们，你至少可以在一夜之间捕获它们。

我不知道，如果这在技术上仍然是CI，因为你每次只做一个“部分”构建，忽略了一些测试。

Answer 2

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

但是，对于夜间构建，我们只包含已通过同行评审过程的源代码，并且已准备好进行测试。

这样，每晚构建总是包含用于测试的“功能就绪”的构建，而CI构建包含功能（在单元测试通过的范围内）可能尚未准备好发送到测试的功能基。

测试组仅从其中一个夜间构建中编写新CR而不是CI构建，尽管这些CR也可用于非正式探索型测试。

Answer 3

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

1. 需要大量资源，而这些资源可能无法使用
2. 每次完成需要4个小时

Answer 4

在我的专业观点中，使用夜间构建的唯一原因是构建过程需要很长时间才能在“合理”的时间内完成。

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

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

Answer 5

这取决于每个构建的目的和长度。基本上，您应该确定您要从CI中学习的内容，并确定在运行多个构建时花费资源是否值得。

为了一些不同的目的，我在上一份工作中使用了持续集成。

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

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

就自动触发的构建而言，我们停在那里。对我们来说，每晚构建一点似乎有点极端。但是我想如果你想每天都有一个快照构建存档，你可能想要安排第三个构建，并需要额外的步骤。虽然，我们确实有另一个构建包裹和存档我们的QA部署工件，以便快速轻松地部署，但我们只是手动触发了那个。

Answer 6

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

1. 如上所述，“夜间”构建可以进行详尽的测试，也许还可以进行一些高级系统测试。端到端的东西。
2. 组织中的每个人都很容易理解“夜间”构建的概念。如果您在将CI构建传递给其他组时遇到问题（例如，与开发组可能没有相同的敏捷句柄的QA组），“夜间”是一个强大且简单的概念。
3. 如果你的夜间是一组独立的资源，它可以单独管理并用于剪切“黄金”图像，并声称软件完整性。例如，开发人员编写代码，某些可信赖的构建系统无法触及构建它，QA测试黄金构建并签名。在这种情况下，每晚构建的功能就像生产构建系统一样。

只是一些想法。

Answer 7

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

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

Answer 8

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

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

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

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