process - 为什么要自动化构建？

Question

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

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

Answer 1

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

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

如需更多备份，尤其是在疲倦时，您可以发送 this article来 self 们自己的 Jeff Atwood，或 this one来自乔尔·斯波尔斯基。从这最后:

Here are some of the many benefits of daily builds:

When a bug is fixed, testers get the new version quickly and can retest to see if the bug was really fixed.

Developers can feel more secure that a change they made isn't going to break any of the 1024 versions of the system that get produced, without actually having an OS/2 box on their desk to test on.

Developers who check in their changes right before the scheduled daily build know that they aren't going to hose everybody else by checking in something which "breaks the build" -- that is, something that causes nobody to be able to compile. This is the equivalent of the Blue Screen of Death for an entire programming team, and happens a lot when a programmer forgets to add a new file they created to the repository. The build runs fine on their machines, but when anyone else checks out, they get linker errors and are stopped cold from doing any work.

Outside groups like marketing, beta customer sites, and so forth who need to use the immature product can pick a build that is known to be fairly stable and keep using it for a while.

By maintaining an archive of all daily builds, when you discover a really strange, new bug and you have no idea what's causing it, you can use binary search on the historical archive to pinpoint when the bug first appeared in the code. Combined with good source control, you can probably track down which check-in caused the problem.

When a tester reports a problem that the programmer thinks is fixed, the tester can say which build they saw the problem in. Then the programmer looks at when he checked in the fix and figure out whether it's really fixed.