为什么要自动化构建？答案

【问题标题】：Why automate builds?为什么要自动化构建？
【发布时间】：2010-12-04 05:17:58
【问题描述】：

因此，我坚信每晚（甚至更频繁地）运行自动化构建，尤其是在项目的后期阶段。今晚我试图说服一位同事，我们需要做出一些改变来促进这一点，他首先挑战了自动化构建的整个前提。星期五晚上很晚，我已经度过了漫长的一周，我很累，老实说，我想不出一个好的答案。所以，非常棒的 Stack Overflow 社区的好人，我带着一个简单的问题来找你：

为什么要有自动构建（或为什么不）？

【问题讨论】：

这样你下周五就不用熬夜看房了吗？
老实说，我不记得我上次参与一个没有在每次签入时运行自动构建并运行所有单元测试的项目是什么时候。人们仍然在专业发展环境中使用更少的东西？
@cfeduke，我遇到过没有 SCM 的公司。 CI 和自动化测试，对很多公司来说仍然是新事物，非常陌生。桌面 UI 世界的状况非常糟糕，因为大多数团队都无法使用这些工具和技术。最新的 MS 框架终于改变了这一点。
这要了我的命。这就像我开始一个项目时总是做的第一件事。 Hudson 很容易设置和免费。 TeamCity 对 20 个项目是免费的，而且很容易设置。如果您真的喜欢 MS 并信任他们进行源代码控制，TFS 实际上会强制执行它。 CruiseControl 及其 .NET 版本是免费的。然后我猜想有 Java 的 Maven，但那是另一种我知之甚少的野兽。
这不是一个答案，真的，但是排除人为错误对于良好的构建至关重要。今天，因为我们没有 Phonegap/Android/iOS 构建服务器，我已经搞砸了三个构建，因为我错过了 hg pull 或构建步骤。计算机一旦给出指令，就不会像人类那样犯错误。

标签： process build build-process build-automation

【解决方案1】：

我在模拟我的生产环境的 VM 中设置了持续集成服务器；通过运行自动构建，当我做了一些事情来搞砸代码时，我会更快地知道很多，并且可以采取行动来修复它。

在一个多人的项目中，尤其是大型项目，不能保证每个用户都在运行测试并进行完整的构建。没有完整构建的时间越长，当每个开发人员都在自己的分支上工作时，一些错误潜入系统的可能性就越大。自动化构建通过确保整个团队在一天左右的时间内知道什么时候出了问题以及谁负责来解决这个问题。

如需更多备份，尤其是在疲倦时，您可以发送我们自己的 Jeff Atwood 的 this article 或 Joel Spolsky 的 this one。从这最后：

这里有一些好处每日构建：

修复错误后，测试人员将获得新版本很快，可以重新测试看看这个错误是否真的被修复了。

开发人员可以比他们所做的改变不会破坏系统的 1024 个版本中的任何一个得到生产，实际上没有在他们的办公桌上放一个 OS/2 盒子测试。

签入他们的开发人员在预定时间之前更改日常构建知道他们不是去管别人检查“中断”的东西构建”——也就是说，导致没有人能够编译。这相当于蓝整个死屏编程团队，并且发生了很多当程序员忘记添加新的他们创建的文件到存储库。构建在他们的机器上运行良好，但是当其他人退房时，他们获取链接器错误并停止冷不做任何工作。

外部团体像营销、测试版客户网站、等等谁需要使用不成熟的产品可以选择一个构建已知相当稳定并保持用了一段时间。

通过维护所有日常构建的存档，当你发现了一个非常奇怪的新错误你不知道是什么原因造成的它，您可以在历史档案以查明何时该错误首先出现在代码中。结合良好的源代码控制，您大概可以追踪到哪个签到导致问题。

当测试人员报告程序员的问题认为是固定的，测试人员可以说他们在哪个版本中看到了问题。然后程序员看他什么时候检查修复并找出是否真的修好了。

【讨论】：

是的，我打算在我的帖子中链接到 Joel 的一些文章，但出于某种原因我决定不这样做。

【解决方案2】：

首先请允许我blatantly ripping off Wikipedia. 请记住，这些是持续集成的一般好处，其中夜间构建应被视为部分实现。显然，如果您将夜间构建与自动化（单元、功能等）测试结合起来，您的系统将会更加强大。

优点：

当单元测试失败或出现错误时，开发人员可以将代码库恢复到无错误状态，而不会浪费时间调试
开发人员不断检测和修复集成问题 - 避免发布日期的最后一分钟混乱（当每个人都试图签入他们稍微不兼容的版本时）。
损坏/不兼容代码的早期警告
冲突更改的早期警告
立即对所有更改进行单元测试
“当前”构建的持续可用性，用于测试、演示或发布目的
立即向开发人员反馈他们正在编写的代码的质量、功能或系统范围的影响
频繁的代码签入促使开发人员创建模块化、不太复杂的代码
自动化测试和 CI 生成的指标（例如代码覆盖率、代码复杂性和功能完整指标）让开发人员专注于开发功能强大的高质量代码，并帮助在团队中发展动力

如果我们只是孤立地谈论夜间构建策略，您会得到一个持续的完整性检查，以确保您的代码库在测试平台上编译，以及及时详细说明责任人的快照。将此与自动化测试和合理的持续集成策略相结合，突然之间，您拥有了一个强大的套件，除了谁破坏了构建之外，还可以为您提供测试失败的人。好交易，如果你问我。

您可以在 remainder of the article, 中了解缺点，但请记住，这是我们在这里讨论的维基百科。

【讨论】：

鉴于后续答案，我假设您已经了解持续集成，并且确实在询问独立构建日常构建的好处。 stackoverflow.com/questions/4352091/why-automate-builds/… 是最好的答案。

【解决方案3】：

我觉得……

这样你就知道你什么时候坏了尽快并且可以的东西在它还新鲜的时候修复它头，而不是几周后。

很容易成为我的最爱，但是当我只是在寻找你不使用 CI 的原因时，这里是 some other reasons 公然被盗：

无法部署的代码是无用的代码。
将您的代码更改与团队中其他人的代码更改集成。
我有时会忘记在签入之前运行所有单元测试。我的 CI 服务器永远不会忘记。
代码的集中状态，有助于沟通。（如果我签入了损坏的代码并且必须由其他人进行部署......这又回到了我最喜欢的原因。）

【讨论】：

只是一个小问题：您无法部署的代码实际上可以是非常有用的代码。您没有部署所有测试，是吗？一些打算稍后开发的副业通常也不会部署。还有一些您需要自己保留的部分，例如生成许可证密钥或类似内容，因此也不会部署。
这意味着如果你不能部署你的代码库，你所有的工作都是徒劳的。测试、签名、实用程序等等，如果你没有部署的东西，这一切都毫无意义。

【解决方案4】：

因为，

自动测试单元测试的完整性。所以你不必担心你的程序的功能不会因为别人的改变而被破坏。
自动获取最新的Checked-In文件并编译，所以任何其他引起的编译错误都会报。
关于构建失败和成功执行的即时电子邮件确认。因此，您可以了解构建失败的人。
可与 FX cop、Style Cop for .Net 等代码标准工具集成。因此，在构建时它会自动检查编码标准。

【讨论】：

这很好，但你没有说为什么你应该使用“巡航控制”或自动构建......只有它的功能，这显然不够好原因。

【解决方案5】：

如果不定期进行完整构建，最终可能会出现以下情况，即本应重新编译的程序的某些部分没有被重新编译，无法编译该部分程序隐藏了一个突破性的变化。部分构建将继续正常工作，但下一个完整构建将导致事情无缘无故地中断。在那之后让事情正常工作可能是一场噩梦。

【讨论】：

【解决方案6】：

一个潜在的社会效益：自动化构建可以减少团队成员之间的毒性。如果开发人员每天重复执行一个或多次的多步骤过程，错误就会蔓延。对于手动构建，队友可能会有这样的态度，“我不称职的开发人员不记得如何每天正确地进行构建. 你会认为他们现在已经搞定了。使用自动构建，出现的任何问题都是程序的问题 - 理所当然，有人编写的程序，但仍然存在。

【讨论】：