为什么有自动构建(或为什么不)？
我在VM中设置了一个模拟我的生产环境的连续集成服务器;通过运行自动化构建,当我完成某些操作以纠正代码时,我会更早地知道一个LOT,并可以进行修复.在具有多个人,特别是较大项目的项目中,不能保证每个用户正在运行测试并进行全面的构建.没有一个完整的建设,你走的时间越长,每个开发人员都将他的分支机构堵塞,那么一些bug会潜入系统的机会就越大.自动化构建通过确保整个团队知道,在一天内出现错误,谁负责的时候,就可以否定这个问题.
为了更多的备份,特别是在累了的时候,你可以从我们自己的Jeff Atwood发送this article,或者从Joel Spolsky发送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.