nightly-build - 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 的答案。有点失望，所以我打算在这里添加它。

希望每个人都知道乔尔职业测试。

来自他关于 Joel 测试的博客：12 步更好的代码

3. 你每天构建吗？

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

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

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

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

还是不服气？查看每日构建是您的朋友中的简介！

Answer 5

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

如果您有任何疑问，您应该阅读Martin Fowler 撰写的这篇关于持续集成的文章。

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

Answer 6

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

这种系统的优点和其他细节可以在 Fowler 的文章和其他地方的 Wikipedia 条目中找到。

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

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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

Answer 11

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

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

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

Answer 12

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

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

Answer 13

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

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

Answer 14

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

Answer 15

每夜构建是执行静态代码分析的理想选择（如果您在 java 世界中，请参阅 qalab 和它收集统计信息的项目）。不幸的是，这是很少做的事情。

Answer 16

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

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