Process 为什么要自动化构建？

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

---

为什么有一个自动构建（或者为什么没有）？

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

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

要获得更多的支持，尤其是在疲劳时，您可以从我们自己的杰夫·阿特伍德（Jeff Atwood）或乔尔·斯波尔斯基（Joel Spolsky）那里发送。从这最后：

以下是该计划的诸多好处中的一些 每日构建：

当一个bug被修复时，测试人员得到 新版本快速，可以重新测试到 看看这个bug是否真的被修复了

开发人员可以感觉到 他们所做的改变不会被打破 系统的1024个版本中的任何一个 那是生产出来的，实际上没有 在他们的办公桌上有一个OS/2盒 测试

签入他们的 更改正好在计划的 每日构建知道它们不是 我要用水管把其他人都冲过去 检查“坏”的东西 “构建”——也就是说 导致没有人能够编译。 这相当于蓝色 一整晚的死亡画面 编程团队，并且经常发生 当程序员忘记添加新的 将他们创建的文件保存到存储库中。 构建在他们的机器上运行良好， 但当其他人退房时，他们 获取链接器错误并被冷停止 不要做任何工作

外部团体 像营销，测试版客户网站， 等等，谁需要使用 不成熟的产品可以选择 被认为是相当稳定和保持 使用它一段时间

通过维持 所有每日生成的存档，当 你发现了一个非常奇怪的新bug 你不知道是什么引起的 它，你可以使用二进制搜索在 历史档案，以确定何时 这个bug首先出现在代码中。 结合良好的源代码控制，您可以 可能能查到哪个登记处 造成问题的原因

当一名测试人员 报告程序员发现的问题 认为是固定的，测试人员会说 他们在哪个建筑中发现了问题。 然后程序员看他什么时候 签入修复并计算出 是否真的修好了

因为

单元测试的完整性将自动测试。所以您不必担心您的程序的功能不会因为其他人的更改而中断

自动获取最新签入文件并进行编译，以便报告由其他原因导致的任何编译错误

生成失败和成功执行时的即时电子邮件确认。因此，您可以找到构建失败的用户

可以与FX cop、Style cop for.Net等代码标准工具集成。因此，在构建时，它会自动检查编码标准

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

优点：

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

如果我们只是孤立地谈论夜间构建策略，那么您得到的是一个持续的健全性检查，检查您的代码库是否在测试平台上编译，以及一个及时的快照，详细说明应该归咎于谁。再加上自动化测试和持续集成的明智策略，突然间，您就拥有了一个强大的套件，可以让您知道谁在测试中失败，谁破坏了构建。好交易，如果你问我的话

---

您可以阅读中的缺点，但请记住，这是我们在这里讨论的维基百科。

如果一个人不定期进行完整构建，那么最终可能会出现一种情况，即程序中本应重新编译的部分没有被编译，未能编译该部分程序会隐藏一个破坏性的更改。部分构建将继续正常工作，但下一个完整构建将导致无明显原因的崩溃。使事情运转起来