为什么自动化构建？

Question

因此,我坚信每晚运行(甚至更频繁)的自动化构建,特别是在项目的后期阶段.我试图让今天的同事说服我们需要进行一些改动来促进这一点,他挑战了首先实现自动化构建的整个前提.星期五晚上已经很晚了,我度过了漫长的一周,我累了,老实说,我无法得到一个好的答案.所以,非常棒的Stack Overflow社区的优秀人才,我带着这个简单的问题来找你:

为什么要自动构建(或者为什么不)？

Answer 1

我在虚拟机中设置了一个持续集成服务器,模仿我的生产环境; 通过运行自动构建,当我做了一些搞砸代码的事情时,我知道很多,并且可以采取措施来修复它.

在具有多个人(尤其是大型项目)的项目中,无法保证每个用户都在运行测试并进行完整构建.没有完整构建的时间越长,当每个开发人员插入他的分支时,某些bug会潜入系统的可能性越大.自动化构建通过确保整个团队在一天左右的时间内知道出现问题以及谁负责来否定此问题.

有关更多的备份,特别累的时候,你可能会在发送这篇文章从我们自己的杰夫阿特伍德,或者这一次乔尔Spolsky的.从这最后:

以下是每日构建的许多好处:

修复错误后,测试人员可以快速获取新版本,并可以重新测试以查看错误是否已得到修复.

开发人员可以感觉更安全,他们所做的更改不会破坏生成的系统的1024个版本中的任何一个,而实际上没有桌面上的OS/2盒可以进行测试.

在预定的每日构建之前检查他们的更改的开发人员知道他们不会通过检查"破坏构建"的东西来阻止所有其他人 - 也就是说,导致没有人能够编译的东西.这相当于整个编程团队的蓝屏死机,当程序员忘记将他们创建的新文件添加到存储库时,会发生很多事情.构建在他们的机器上运行良好,但是当其他任何人检出时,他们会遇到链接器错误,并且不会做任何工作.

需要使用不成熟产品的营销,测试版客户网站等外部群体可以选择已知相当稳定且一直使用它的构建.

通过维护所有每日构建的存档,当您发现一个非常奇怪的新错误并且您不知道是什么导致它时,您可以在历史存档上使用二进制搜索来查明错误最初出现在代码中的时间.结合良好的源代码控制,您可以跟踪导致问题的签入.

当测试人员报告程序员认为已修复的问题时,测试人员可以说出他们看到问题所在的构建.然后程序员查看他何时检查了修复程序并确定它是否真的已修复.