我为什么要夜间构建？
答案 0 :(得分：44)
您应该进行夜间构建，以确保您的代码库保持健康。
做夜间构建的一个副作用是它迫使团队创建和维护一个完全自动化的构建脚本。这有助于确保您的构建过程记录在案并且可重复。
自动构建很擅长发现以下问题：
每晚进行此操作可确保您在发生问题后的24小时内发现此类问题。这比在你提供软件之前24小时找到所有问题更好。
当然，您还应该为每个每晚构建运行自动单元测试。
答案 1 :(得分：22)
我个人认为持续整合比夜间建设更好：
http://en.wikipedia.org/wiki/Continuous_integration
我甚至在一个人的项目中使用它，令人惊讶的是你能够多快地揭露问题并在那里照顾它们。
答案 2 :(得分：19)
我已经做了16年的构建工程（除其他事项外）。我坚信构建 - 早期，经常构建，持续集成。所以我对项目的第一件事就是确定如何构建它（Java：Ant或Maven; .NET：NAnt或MSBuild）以及它将如何构建管理（Subversion或其他一些版本控制）。然后我将根据平台添加持续集成（CruiseControl或CruiseControl.NET），然后让其他开发人员放松。
随着项目的发展，以及对报告和文档的需求不断增长，最终构建将需要更长的时间才能运行。在那时，我将构建拆分为连续构建（在checkin上运行），它只编译和运行单元测试和构建所有内容的每日构建，运行所有报告，并构建任何生成的文档。我还可以添加一个标记存储库的交付构建，并为客户交付做任何其他包装。我将使用细粒度的构建目标来管理细节，以便任何开发人员都可以构建系统的任何部分 - 持续集成服务器使用与任何开发人员完全相同的构建步骤。最重要的是，我们从未提供用于测试的构建版本或未使用构建服务器构建的客户。
这就是我所做的 - 这就是为什么我这样做（以及为什么你应该这样做）：
假设您有一个典型的应用程序，包含多个项目和多个开发人员。虽然开发人员可以从一个通用的，一致的开发环境（相同的操作系统，相同的补丁，相同的工具，相同的编译器）开始，但随着时间的推移，他们的环境将会出现分歧。一些开发人员将虔诚地应用所有安全补丁和升级，而其他人则不会。一些开发人员将添加新的（可能更好的）工具，其他人则不会。有些人会记得在建造之前更新完整的工作空间;其他人只会更新他们正在开发的项目部分。一些开发人员会将源代码和数据文件添加到项目中，但忘记将它们添加到源代码管理中。其他人会编写依赖于环境特定怪癖的单元测试。因此，您将很快看到流行的“嗯，它在我的机器上构建/工作”的借口。
通过拥有一个独立，稳定，一致，已知良好的服务器来构建应用程序，您可以轻松发现这些问题，并且通过运行每次提交的构建，您将能够确定何时出现问题进入系统。更重要的是，因为您使用单独的服务器来构建和打包应用程序，所以每次都会以相同的方式打包所有内容。没有什么比开发人员向客户提供自定义构建，使其工作，然后不知道如何重现自定义更糟糕的事情。
答案 3 :(得分：9)
当我看到这个问题时，首先我搜索了Joel Spolsky's个答案。有点失望，所以我打算在这里添加它。
希望大家都知道Joel Test on Careers。
来自The Joel Test: 12 Steps to Better Code
上的博客第3。你做日常构建吗？
当您使用源代码管理时，有时会使用一个程序员 意外地检查破坏构建的东西。 例如， 他们已经添加了一个新的源文件，所有内容都可以很好地编译 机器，但他们忘了将源文件添加到代码中 库。因此，他们锁定他们的机器，回家，忘记和 快乐。但是没有其他人可以工作，所以他们也必须回家，不开心。
破坏构建是如此糟糕（并且如此常见）以至于它有助于制作 每日构建，以确保不会忽视任何破损。 大 团队，确保破损立即得到解决的一个好方法是 每天下午，比如午餐时间，每天都要做。大家 在午餐前尽可能多地办理登机手续。当他们回来时， 构建完成。如果它工作，太棒了！每个人都检查出来 最新版本的源码，继续工作。如果构建失败， 你修复它，但每个人都可以继续使用预构建， 不间断的来源版本。
在Excel团队中，我们有一个规则，即谁破坏了构建，作为他们的 “惩罚”，负责照看建筑物直到有人 别的打破了。这是一个不打破构建的好动机，并且a 通过构建过程轮换每个人的好方法，以便每个人 了解它是如何运作的。
虽然我没有机会进行日常构建，但我非常喜欢它。
还是不相信？请查看Daily Builds Are Your Friend!!
中的摘要答案 4 :(得分：7)
你实际上并不是，你应该想要的是持续集成和自动测试（这比每晚构建更进一步）。
如果您有任何疑问，请阅读this article by Martin Fowler about Continuous Integration。
总而言之，您希望尽可能早地进行构建和测试，并尽可能立即发现错误，以便修复它们，而您在创建时所实现的目标仍然是新鲜的。
答案 5 :(得分：7)
我实际上建议您每次办理登机手续时都要进行构建。换句话说，我建议您建立一个持续集成系统。
此类系统的优势和其他细节可以在其他地方找到in Fowler's article和on the Wikipedia entry。
根据我的个人经验，这是质量控制的问题：每次修改代码（或测试，可以被视为一种需求形式）时，错误可能会逐渐消失。为了确保质量，您应该重新构建产品将被运送并执行所有可用的测试。这样做的次数越多，允许形成殖民地的可能性就越小。因此，每日（夜间）或连续循环是首选。
此外，无论您是将项目的访问限制为开发人员还是更大的用户群，每晚构建都可以让每个人都使用“最新版本”，从而最大限度地减少将自己的贡献合并到代码中的痛苦。 / p>
答案 6 :(得分：4)
您希望在常规计划上进行构建，以便发现开发人员之间的代码集成问题。你想要这样做 nightly ，而不是每周或更长的时间表，是因为你等待发现这些问题的时间越长，解决它们的难度就越大。在每次签入时进行构建（持续集成）的做法只是将夜间构建过程变为逻辑极端。
从长远来看，拥有可重复构建过程的附带好处也很重要。如果您在一个正在进行多个项目的团队中工作，那么在某些时候您将需要能够轻松地重新创建旧版本，可能用于创建补丁。 ：（
您可以越多地自动化构建过程，您为每个后续构建节省的时间就越多。它还使构建过程本身脱离了交付最终产品的关键路径，这应该让您的经理感到高兴。 ：）
答案 7 :(得分：3)
这还取决于您的项目团队的规模和结构。如果有不同的团队依赖于彼此的API，那么为夜间构建进行频繁集成可能会很有意义。如果你只与一两个队友进行黑客攻击，那么它可能也可能不值得。
答案 8 :(得分：3)
根据产品的复杂程度，持续集成可能会也可能无法运行完整的测试套件。
想象一下思科测试的路由器有1000个不同的设置进行测试。要在某些产品上运行完整的测试套件需要时间。有时几周。因此，您需要用于不同目的的构建。每晚构建可以作为更全面的测试套件的基础。
答案 9 :(得分：2)
嗯......我想当然，这很大程度上取决于你的项目。如果它只是你的爱好项目，没有发布，没有依赖，没有人，但你提交代码，它可能是过度的。
另一方面，如果有一组开发人员都提交代码，自动夜间构建将帮助您确保存储库中代码的质量。如果某人为所有其他人做了“破坏构建”的事情，很快就会被注意到。可以在不注意的情况下中断构建，例如忘记将新文件添加到存储库，并且在集中位置的夜间构建将很快检测到这些。
当然还有其他可能的好处，我相信其他人会提供这些好处。 ：）
答案 10 :(得分：2)
我认为它们非常重要，特别是对于超过1人的项目。如果有人，团队需要尽快知道：
答案 11 :(得分：2)
任何构建自动化都比没有构建自动化更好： - ）
就个人而言，我更喜欢每日构建 - 如果构建不起作用，那么每个人都可以修复它。
事实上，如果可能的话，持续集成构建是可行的方法（即在每次签入时构建），因为这样可以最大限度地减少构建之间的更改量，从而可以轻松判断谁破坏了构建并且还很容易修复构建。
答案 12 :(得分：1)
每夜构建仅对于大型项目是必需的（当它在一整天中经常构建它时需要很长时间）。如果你有一个不需要很长时间来构建的小项目，你就可以在你完成功能代码的过程中构建它，这样你就知道你没有弄乱任何程序。但是，对于较大的项目，这是不可能的，因此建立项目非常重要，以便您知道所有内容仍处于正常运行状态
答案 13 :(得分：1)
有几个原因，有些原因比其他原因更适用
答案 14 :(得分：0)
夜间构建并不总是必要的 - 我认为它们只对大型项目非常有用。但是，如果你是一个大项目，每晚构建是检查一切正常工作的好方法 - 你可以运行所有测试（单元测试，集成测试），构建所有代码 - 简而言之，验证没有什么是在你的项目中被打破。
如果你有一个较小的项目，你的构建和测试时间会更短，所以你可以负担得起更多的常规构建。
答案 15 :(得分：0)
每晚构建非常适合执行静态代码分析（请参阅qalab以及它从java世界中收集统计信息的项目）。不幸的是，这很少发生。