持续集成与夜间构建
阅读这篇文章让我想知道； 对于某种情况来说，夜间构建是否比持续集成更好？ 答案的共识似乎相当不平衡地支持持续集成，这是福音还是当持续集成是一种选择时真的没有理由使用夜间构建？
Reading this post has left me wondering; are nightly builds ever better for a situation than continuous integration? The consensus of the answers seems to be pretty lopsided in favor of continuous integration, is that evangelism or is there really no reason to use nightly builds when continuous integration is an option?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
如果您确实对所有可用测试进行持续集成，则夜间构建将是多余的，因为当天签入的最后一个内容已经过测试。
另一方面，如果您的 CI 制度仅涉及运行所有可用测试的子集，例如因为某些测试需要很长时间才能运行，那么您可以另外使用 nightlies 来运行所有测试。 这会让你尽早发现很多错误，如果你不能尽早发现它们，你至少可以在一夜之间发现它们。
不过，我不知道这在技术上是否仍然是 CI，因为你每次只是通过忽略一些测试来进行“部分”构建。
If you're really doing continuous integration with all available tests, nightly builds would be redundant, since the last thing checked in that day would already have been tested.
On the other hand, if your CI regime only involves running a subset of all available tests, for example because some of your tests take a long time to run, then you can use nightlies additionally to run all tests. This'll let you catch many bugs early, and if you can't catch them early, you can at least catch them overnight.
I don't know, though, if that's technically still CI, since you're only doing a "partial" build each time, by ignoring some of the tests.
在我们的组织中，夜间构建和 CI 构建有两个不同的目的。 CI 构建是“最新代码”构建，其中单元测试按照您所期望的最后一次签入运行。 我们还在 CI 构建上运行了几个代码指标。
然而，对于夜间构建，我们仅合并已通过同行评审流程并被视为已准备好进行测试的源代码。
这样，夜间构建始终包含已为测试“功能准备就绪”的构建，而 CI 构建包含虽然功能正常（在单元测试通过的范围内）可能尚未准备好发送到测试组的功能。
测试组专门从夜间构建之一（而不是 CI 构建）编写新的 CR，尽管这些也可用于非正式的探索性类型测试。
In our organization, nightly builds and CI builds have two distinct purposes. The CI build is a 'latest code' build in which the unit tests are run against the last check in as you would expect. We also run several code metrics on the CI build.
For nightly builds, however, we only incorporate source code that has been through the peer review process and is deemed ready for testing.
This way, the nightly build always contains build that is 'feature ready' for testing, while the CI build contains features that while functional (to the extent that the unit tests pass) may not be ready to send the to the test group.
The test groups writes new CRs exclusively from one of the nightly builds as opposed to the CI build, although those are also available for informal exploratory type testing.
是的，如果您有一个想要附加到构建的进程，但它占用大量资源。 例如，在我的团队中，我们在夜间构建期间运行 JTest。 我们无法在白天运行它，因为：
Yes, if you have a process you want attached to a build, but it is resource heavy. For example, on my team we run JTest during the nightly build. We can't run it during the day because:
如果您有一个强大的 CI 流程，“每晚”仍然有用。
只是一些想法。
If you have a nice robust CI process in place a "nightly" is still useful.
Just some thoughts.
在我的专业观点中，使用夜间构建的唯一原因是构建过程花费的时间太长以至于无法在“合理”的时间内完成。
例如，如果您的构建过程需要 5 小时才能完成，那么确实没有理由在签入时进行构建。
除此之外，尽快了解构建失败的时间非常有价值，这可以忽略其他问题。
In my professional opinion, the only reason to use nightly builds is when the build process takes so long that it can't complete in a "reasonable" amount of time.
For example, if your build process takes 5 hours to complete there is really no reason to do a build on check in.
Beyond that, there is so much value in knowing as soon as possible when a build fails that it overrides other concerns.
这取决于每个构建的目的和长度。 基本上，您应该确定您想从 CI 中学习什么，并决定在运行多个构建上花费资源是否值得。
在我上一份工作中，我们出于几个不同的目的使用了持续集成。
首先，我们使用它来确保存储库以及开发人员始终拥有已编译的代码版本。 对于团队成员来说，没有什么比因为一个人签入了错误代码而必须通过注释、取消注释、恢复和合并来管理另一个人的破坏性更改更糟糕的了。 为此，我们有一个无需测试或其他验证即可立即运行的构建，因此我们可以尽快知道代码是否可以安全更新。 构建通常需要大约 10 分钟，并且机器在正常工作日可能运行 50% 左右。 这里没有生成任何文档，只有安静的通过或响亮的失败警报。
其次，我们想尽快知道是否违反了任何规则。 越快发现违规规则，修复起来就越容易。 为此，我们有一台单独的机器来运行代码的完整构建和验证。 该机器在正常工作日每天连续运行 12-14 小时。 构建的电子邮件状态已发送，描述了损坏的单元测试、代码合规性等。
至于自动触发的构建，我们就到此为止了。 在此基础上每晚进行一次构建对我们来说似乎有点极端。 但我想如果您想每天存档快照构建，您可能需要安排第三次构建并执行所需的额外步骤。 虽然，我们确实有另一个版本来包装并存档我们的 QA 部署工件，以便快速轻松地部署，但我们只手动触发了该版本。
It depends on the purpose and length of each of your builds. Basically, you should identify what you are trying to learn from CI and decide if it is worth while spending the resources on running multiple builds.
We used continuous integration at my last job for a few different purposes.
First, we used it to make sure that the repository and thus the developers always had a version of the code that compiled. Few things are worse for team members than having to manage another person's broken changes through commenting, uncommenting, reverting and merging, because one person checked in bad code. For this, we had a build that ran instantaneously with no tests or other validation so we knew as soon as possible if the code was safe to update. Builds usually took about ten minutes and the machine was probably running around 50% on a normal workday. No documentation was generated here, just a quiet pass or a loud fail siren.
Second, we wanted to know as soon as possible whether or not any rules were broken. The quicker that you find a broken rule, the easier it is to fix. For this purpose, we had a separate machine that ran a full build and validation of the code. This machine was running 12-14 hours a day continuously on a normal workday. Email status of the build was sent out describing broken unit tests, code compliance, etc.
We stopped there as far as automatically triggered builds go. A nightly build on top of that seemed a bit extreme for us. But I suppose if you wanted to have a snapshot build archived daily, you may want to schedule a third build with the extra steps required for that. Though, we did have another build that wrapped up and archived our QA deployment artifacts for quick and easy deployment, but we only ever manually triggered that one.
我认为其他帖子涵盖了常见原因，例如构建过程花费“太长”或在 CI 构建期间仅运行一部分测试。 但还有另一个政治原因。
在某些组织中，官方构建由最低限度响应的构建/基础设施/发布管理/SCM 团队处理。 在这些情况下，您可以让他们负责夜间构建，然后在开发之外运行 CI 构建。 这可以避免冲突，因为他们的构建仍然是“官方构建”，而您的 CI 构建会为您提供所需的反馈。
I think the other posts cover the common reasons, like having a build process that takes "too long" or having to run only a subset of tests during the CI build. But there's another reason which is political.
In some organizations the official builds are handled by a minimally responsive build/infrastructure/release management/SCM team. In these cases you might put them in charge of the nightly build and then run the CI build out of development. This avoids a fight because their build remains "the official build" and your CI build give you the feedback you need.
我们有持续集成和夜间构建。 它们有两个不同的目的。
我们的持续集成机制构建软件并在持续集成套件下运行单元测试。
我们的夜间构建在版本控制下标记源，构建软件，在夜间构建套件下运行单元测试。 此处构建的软件随后用于各种系统测试和压力测试。
我认为夜间构建的主要区别之一是系统测试。
We have both continuous integration and nightly builds in place. They serve two different purposes.
Our continuous integration mechanism builds the software and runs unit tests under the continuous integration suite.
Our nightly build tags the source under version control, builds the software, runs the unit tests under nightly build suite. The software built here is then used in various system tests and stress tests.
I think that one of the main differentiator for nightly build is system tests.