Nightly Builds：我为什么要这样做？ [关闭]

Question

我为什么要夜间构建？

Answer 1

您应该每晚进行构建以确保您的代码库保持健康。

进行夜间构建的一个副作用是它迫使团​​队创建和维护一个完全自动化的构建脚本。这有助于确保您的构建过程记录在案且可重复。

自动化构建擅长发现以下问题：

• 有人签入了破坏物品的东西。
• 有人忘记签入必要的文件或更改。
• 您的构建脚本不再起作用。
• 你的构建机器坏了。

每晚执行此操作可确保您在此类问题发生后的 24 小时内发现问题。这比在交付软件前 24 小时发现所有问题要好。

当然，您还应该为每个夜间构建运行自动化单元测试。

Answer 2

我个人发现持续集成比夜间构建更好：
http://en.wikipedia.org/wiki/Continuous_integration

我什至在一个人的项目中使用它，令人惊讶的是，您可以如此快速地发现问题并立即处理它们。

Answer 3

我从事建筑工程（除其他外）已有 16 年了。我坚信尽早构建、经常构建、持续集成。所以我对一个项目做的第一件事就是确定如何构建它（Java：Ant 或 Maven；.NET：NAnt 或 MSBuild）以及如何管理它（Subversion 或一些其他版本控制）。然后我会根据平台添加持续集成（CruiseControl 或CruiseControl.NET），然后让其他开发人员放松。

随着项目的增长以及对报告和文档的需求的增长，最终构建将需要更长的时间来运行。那时，我会将构建拆分为仅编译和运行单元测试的连续构建（在签入时运行）和构建所有内容、运行所有报告并构建任何生成的文档的每日构建。我还可以添加一个交付构建，用于标记存储库并为客户交付进行任何额外的打包。我将使用细粒度的构建目标来管理细节，以便任何开发人员都可以构建系统的任何部分——持续集成服务器使用与任何开发人员完全相同的构建步骤。最重要的是，我们从不交付用于测试的构建，也不会交付不是使用构建服务器构建的客户。

这就是我所做的——这就是我这样做的原因（以及为什么你也应该这样做）：

假设您有一个典型的应用程序，其中包含多个项目和多个开发人员。虽然开发人员可能从一个通用的、一致的开发环境开始（相同的操作系统、相同的补丁、相同的工具、相同的编译器），但随着时间的推移，他们的环境会有所不同。一些开发人员会虔诚地应用所有安全补丁和升级，而另一些则不会。一些开发人员会添加新的（也许更好的）工具，而另一些则不会。有些人会记得在构建之前更新他们的完整工作空间；其他人只会更新他们正在开发的项目的一部分。一些开发人员会将源代码和数据文件添加到项目中，但忘记将它们添加到源代码控制中。其他人将编写依赖于他们环境的特定怪癖的单元测试。结果，您很快就会看到流行的“嗯，它在我的机器上构建/工作”的借口。

通过使用单独的、稳定的、一致的、已知良好的服务器来构建您的应用程序，您将很容易发现这类问题，并且通过从每次提交运行构建，您将能够查明问题何时出现进入系统。更重要的是，因为您使用单独的服务器来构建和打包您的应用程序，它每次都将始终以相同的方式打包所有内容。没有什么比让开发人员向客户交付定制版本、让它工作，然后不知道如何重现定制更糟糕的了。

Answer 4

当我看到这个问题时，我首先搜索了Joel Spolsky's的答案。有点失望，所以我打算在这里添加它。

希望大家都知道Joel Test on Careers。

来自他的博客The Joel Test: 12 Steps to Better Code

3。您每天都进行构建吗？

当您使用源代码控制时，有时需要一名程序员 不小心签入了破坏构建的东西。 例如， 他们添加了一个新的源文件，一切都在他们的 机器，但他们忘记将源文件添加到代码中 存储库。于是他们锁上机器回家，浑然不觉 快乐的。但是没有其他人可以工作，所以他们也不得不回家，不高兴。

破坏构建是如此糟糕（而且如此普遍），它有助于 每日构建，以确保没有破损被忽视。 大 团队，确保立即修复破损的一种好方法是 每天下午（比如午餐时间）进行每日构建。每个人 午餐前尽可能多地办理登机手续。当他们回来时， 构建完成。如果它有效，那就太好了！每个人都检查 最新版本的源代码并继续工作。如果构建失败， 你修复它，但每个人都可以继续使用预构建， 源的完整版本。

在 Excel 团队中，我们有一条规则，任何破坏构建的人，作为他们的 “惩罚”，负责照看构建直到有人 否则把它弄坏了。这是不破坏构建的一个很好的激励，并且 在构建过程中轮换每个人的好方法，以便每个人 了解它是如何工作的。

虽然我没有机会进行日常构建，但我是它的忠实粉丝。

仍然不相信？在Daily Builds Are Your Friend!!查看简介

Answer 5

实际上，您不需要的是持续集成和自动测试（这比夜间构建更进一步）。

如果您有任何疑问，请阅读this article by Martin Fowler about Continuous Integration。

总而言之，您希望尽可能早地、经常地构建和测试，以便立即发现错误，以便在您想实现的目标仍然记忆犹新时修复它们。

Answer 6

我实际上建议您每次签到时都进行构建。换句话说，我建议设置一个持续集成系统。

这种系统的优点和其他细节可以在in Fowler's article和on the Wikipedia entry等地方找到。

根据我的个人经验，这是一个质量控制问题：每次修改代码（或测试，可以看作是一种形式的需求）时，错误可能会逐渐出现。为确保质量，您应该重新构建产品，因为它将被运送并执行所有可用的测试。这样做的次数越多，虫子形成群落的可能性就越小。因此，优选每天（每晚）或连续循环。

此外，无论您将项目的访问权限限制为开发人员还是更多用户，每晚构建都可以让每个人都使用“最新版本”，从而最大限度地减少将自己的贡献合并回代码中的痛苦。

Answer 7

您希望定期进行构建，以便发现开发人员之间的代码集成问题。您希望每晚执行此操作，而不是每周或更长的计划执行此操作的原因是，您等待发现此类问题的时间越长，解决它们的难度就越大。在每次签入时进行构建（持续集成）的做法只是将夜间构建过程推向了一个合乎逻辑的极端。

从长远来看，具有可重复构建过程的附带好处也很重要。如果您在一个有多个项目的团队工作，那么在某些时候您将需要能够轻松地重新创建旧版本，也许是为了创建补丁。 :(

构建过程自动化程度越高，每次后续构建所节省的时间就越多。它还使构建过程本身脱离了交付最终产品的关键路径，这应该会让您的经理感到高兴。 :)

Answer 8

这还取决于为您的项目工作的团队的规模和结构。如果有不同的团队相互依赖 API，那么为频繁集成进行夜间构建可能会很有意义。如果你只和一两个队友一起玩，那可能值得，也可能不值得。

Answer 9

根据您产品的复杂性，持续集成可能会也可能不会运行完整的测试套件。

想象一下，Cisco 使用 1000 多种不同的设置来测试路由器。在某些产品上运行完整的测试套件需要时间。有时几周。因此，您需要针对不同目的进行构建。每晚构建可以成为更全面的测试套件的基础。

Answer 10

我认为他们非常重要，尤其是在超过 1 人的项目中。团队需要尽快知道是否有人：

• 签入错误文件
• 不签入文件
• ...

Answer 11

任何构建自动化都比没有构建自动化要好:-)

就个人而言，我更喜欢每日构建 - 这样，如果构建不起作用，那么每个人都会在附近修复它。

事实上，如果可能的话，持续集成构建是可行的方法（即在每次签入时构建），因为这可以最大限度地减少构建之间的更改量，因此可以很容易地判断谁破坏了构建并且也很容易修复构建。

Answer 12

嗯...我想这在很大程度上取决于你的项目，当然。如果它只是你的爱好项目，没有发布，没有依赖，除了你提交代码之外没有其他人，这可能是矫枉过正。

另一方面，如果有一个开发人员团队都在提交代码，那么自动夜间构建将帮助您确保存储库中代码的质量。如果有人为所有其他人做了“破坏构建”的事情，它很快就会被注意到。可能会在不注意的情况下中断构建，例如忘记向存储库添加新文件，而集中位置的夜间构建会很快检测到这些。

当然还有其他可能的好处，我相信其他人会提供它们。 :)

Answer 13

只有大型项目才需要每晚构建（当经常在一天中构建它需要很长时间时）。如果您有一个不需要很长时间构建的小项目，您可以在完成功能代码片段时构建它，这样您就知道您没有在过程中搞砸任何事情。但是，对于较大的项目，这是不可能的，因此构建项目很重要，以便您知道一切仍在正常工作中

Answer 14

有几个原因，有些会比其他的更适用

• 如果您的项目由两个或更多人处理
• 这是获取您未处理的最新版本代码的好方法
• 每晚构建提供代码当前状态的时间片
• 如果您需要将代码发送给他人，夜间构建将为您提供稳定的构建

Answer 15

并非总是需要每晚构建 - 我认为它们仅在大型项目中真正有用。但是如果你在一个大项目上，每晚构建是检查一切是否正常的好方法——你可以运行所有的测试（单元测试、集成测试），构建你的所有代码——简而言之，验证一切正常你的项目坏了。

如果您有一个较小的项目，您的构建和测试时间会更短，因此您可能有能力进行更多常规构建。

Answer 16

夜间构建非常适合执行静态代码分析（如果您在 Java 世界中，请参阅 qalab 和它收集统计信息的项目）。不幸的是，这是很少做的事情。