每日构建的重要性如何？[关闭]

乔尔测试的标准之一是日常构建。想法是，如果构建已损坏，则无论谁破坏了它，都可以修复它。如果无法修复该版本，则每个人都必须签出旧版本并进行处理。我可以理解，这对于集中式版本控制而言可能是非常糟糕的，在集中式版本控制中，尽可能避免合并和分支很重要，但这听起来像是分布式版本控制的一个小麻烦。你同意吗？还有其他原因使每日构建很重要吗？

我认为在这里要注意的重要一点是，常规构建有助于更快地发现错误，而不是稍后。它不必每天都需要，但经常需要。理想情况下，它也可以运行单元测试。

目标是在最终测试阶段之前找出构建何时中断，并尽快找到它们。

只需设置它即可构建您的主要开发分支。

我们在工作中使用它（尽管我们每小时创建一次），并且常常在忘记设置时，我们会在发布前几个小时发现问题。

需要添加一些（和@GoodEnoughs）：

但这听起来像是分布式版本控制的一个小麻烦。

完全不可以-“服务器”构建的作用是告诉您，您的中继将或多或少从干净的地方构建并通过其测试（需要对环境进行的配置数量越少）。

我正在考虑切换到DVCS，但是即使这样做了，您也会将我的持续集成从冷冷的人手里拖了下来。

举一个简单的例子-您正在开发功能“ a”，而他正在开发功能“ b”，则有时需要将它们缝合在一起-如果在提交时忘记添加应用程序将要构建的文件，在您的计算机上，但不会在其他任何地方。因此，当您将构建推送到“主干”时，持续集成将触发并且构建将失败，并且您将知道并且希望在有人提出您不太完全的代码之前，您可以采取步骤。

如果您正在与多个开发人员一起进行项目，则必须能够定义发行版本的来源-有效的主干-无论版本控制如何工作，这都是正确的。

如果您添加了一项功能，尤其是其他人依赖的功能，则可以确信，当该功能被“发布”时，它会在开发环境以外的其他地方构建并通过测试。不仅如此，我还从我的构建服务器的构建中进行部署-一种如何指定“确定的”构建的方式。最终，我将拥有用户触发的部署版本。它没有很好的说，你可以工作轮-你可以，如果你需要的不是（我已经炒轮dev的箱子在办公室找到并提交丢失的文件）。

有点强吗？不知道-但是我的构建服务器是我不想回馈的那些东西之一。

我认为每日构建非常重要。如果您的团队分布在不同的时区，那么最好找到大多数团队的“时间即将结束”的时间。另外，如果日常构建具有自动测试组件，则更理想。

在中央源代码控制系统时代，我建议在源代码发生任何更改时，每5-10分钟运行一次连续构建。由于编译错误可能会拖慢整个团队的工作。对于运行分布式源代码控制系统的组织，由于开发人员不太直接接触“原始”代码库，因此可能不需要连续构建。

理想情况下，除非您要构建耗时超过半天的大型建筑，否则您每天将构建不止一次。设置好连续的集成服务器（例如Hudson或TeamCity）后，构建将自动进行，通常每小时进行一次或每次提交，如果有任何问题，您将得到通知。

这是一种尽早发现错误的好方法，尤其是当您还在构建过程中运行自动化测试时。这对于在配置可以在一个开发人员的机器上工作但不能在其他地方工作的情况下发现配置错误特别有用，因为从存储库或环境中省略了某些内容。

更高级的持续集成服务器还允许您随时间跟踪指标（例如，代码覆盖率，构建时间，代码行等）。

每日构建都可以。如果您别无选择，那么您绝对需要它们，但老实说，我认为这些天Joel的测试有些过时了。

我认为您应该整天不断地构建，运行您的单元，系统和功能级别的测试用例，并且理想情况下同时打包和部署到类似环境的阶段，同时还要验证您是否已建立任何数据库和环境版本控制机制正在按预期工作。

如果构建或部署时间过长，则可以考虑通过物理或软件ram磁盘，更快的Internet连接，并行化构建等方式来解决其中的一些问题。通过快速识别构建中断而节省的时间将很快使硬件成本降低。 。

每日构建并不重要。每日构建总是成功的（或仅中断一个小时的构建）。在构建中断70％的时间时使用CI并不是很有用，因为如果事情大部分都中断了，那将无法帮助您识别错误。

我认为应该每天进行构建，测试和部署到登台服务器。

“每日构建”背后的思想是始终准备好一些东西，以便测试人员和项目经理可以运行，以便每个人都可以了解项目的真实状态。

过去，在“每日构建”之后使用桌面应用程序时，测试人员或项目经理可以立即运行该应用程序，因此无需提及部署步骤。