为什么要自动化构建？
因此，我坚信每晚（甚至更频繁）运行自动化构建，尤其是在项目的后期阶段。今晚我试图说服一位同事，我们需要做出一些改变来促进这一点，而他首先对自动化构建的整个前提提出了挑战。星期五晚上很晚了，我度过了漫长的一周，我很累，老实说我无法想出一个好的答案。那么，令人惊叹的 Stack Overflow 社区的好人们，我向你们提出这个简单的问题：
为什么要进行自动化构建（或者为什么不进行自动化构建）？
So, I'm a firm believer in having automated builds that run nightly (or even more often), especially during the late phases of a project. I was trying to convince a colleague tonight that we need to make some changes to facilitate this, and he challenged the whole premise of having automated builds in the first place. It is late on a Friday night, I've had a long week, I'm tired, and I honestly couldn't come up with a good answer. So, good people of the amazingly awesome Stack Overflow community, I come to you with this simple question:
Why have an automated build (or why not)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我在模仿我的生产环境的虚拟机中设置了一个持续集成服务器；通过运行自动化构建，当我做了一些搞砸代码的事情时，我可以更快地知道很多，并且可以采取措施来修复它。
在多人的项目中，尤其是较大的项目中，无法保证每个用户都在运行测试并进行完整的构建。没有完整构建的时间越长，当每个开发人员都在自己的分支上埋头苦干时，某些错误潜入系统的可能性就越大。自动化构建通过确保整个团队在一天左右的时间内知道何时出现问题以及责任人来解决这个问题。
如需更多备份，尤其是在疲劳时，您可以发送 这篇文章来自我们自己的 Jeff Atwood，或这篇文章 来自乔尔·斯波尔斯基。从这最后：
I have a continuous integration server set up in a VM that mimics my production environment; by running automated builds, I know a LOT sooner when I've done something to screw up the code, and can make moves to fix it.
In a project with multiple people, especially larger projects, there are no guarantees that every user is running the tests and doing a full build. The longer you go without a full build, the greater the chances that some bug will sneak its way into the system while each dev is plugging away at his branch. Automated builds negate this issue by making sure the whole team knows, within the day or so, when something went wrong, and who was responsible.
For more backup, especially when tired, you might send over this article from our own Jeff Atwood, or this one from Joel Spolsky. From this last:
请允许我首先公然抄袭维基百科。请记住，这些是持续集成的一般好处，其中夜间构建应被视为部分实现。显然，如果您将夜间构建与自动化（单元、功能等）测试结合起来，您的系统将会更加强大。
优点：
如果我们只是孤立地讨论每晚构建策略，那么您得到的就是对您的代码库在测试平台上编译的持续健全性检查，以及及时详细说明责任人的快照。将其与自动化测试和持续集成的合理策略结合起来，突然间您就拥有了一个强大的套件，除了谁破坏了构建之外，还可以为您提供谁未通过测试。 好交易，如果你问我的话。
您可以在本文的其余部分中了解其缺点，但请记住，这我们在这里谈论的是维基百科。
Allow me to begin by blatantly ripping off Wikipedia. Bear in mind, these are the general benefits of continuous integration, of which nightly builds should be considered a partial implementation. Obviously, your system will be more powerful if you couple nightly builds with your bed of automated (unit, functional, etc.) tests.
Advantages:
If we're just talking about a nightly build strategy in isolation, what you get is a constant sanity check that your codebase compiles on the test platform(s), along with a snapshot in time detailing who to blame. Couple this with automated testing and a sane strategy of continuous integration, and suddenly you have a robust suite that gives you who failed the tests in addition to who broke the build. Good deal, if you ask me.
You can read about the disadvantages in the remainder of the article, but remember, this is Wikipedia we're talking about here.
我认为...
很容易是我的最爱，但这里有一些其他原因当我只是在寻找你不使用 CI 的原因时，它被公然窃取：
I think that...
is easily my favorite, but here are some other reasons blatantly stolen when I was just searching for reasons why you wouldn't use CI:
因为，
单元测试的完整性是自动测试的。因此，您不必担心您的程序的功能不会因为其他人所做的更改而被破坏。
自动获取最新的签入文件并编译，因此报告由其他引起的任何编译错误。
构建失败和成功执行时的即时电子邮件确认。这样您就可以知道是谁构建失败了。
可以与 FX cop、Style Cop for .Net 等代码标准工具集成。因此，在构建时，它会自动检查编码标准。
Because,
Integrity of your Unit Test is automatically tested. So you need not to worry about functionality of your program is not broken because of changes made by others.
Automatically gets the latest Checked-In files and compiles, so any compile error caused by other reported.
Instant e-Mail acknowledgment on failure and successful execution of build. So you get to who failed the build.
Can be integrated with Code Standard Tool like FX cop, Style Cop for .Net. So while build it automatically checks the Coding Standards.
如果不定期进行完整构建，最终可能会出现一种情况，即应该重新编译的程序的某些部分没有被重新编译，即编译该程序部分的失败隐藏了重大更改。部分构建将继续正常工作，但下一个完整构建将导致事情无缘无故地崩溃。之后让一切正常运转可能会是一场噩梦。
If one doesn't do full builds on a regular basis, one can end up with a situation where some part of a program that should have been recompiled isn't, that the failure to compile that part of the program conceals a breaking change. Partial builds will continue to work fine, but the next full build will cause things to break for no apparent reason. Getting things to work after that can be a nightmare.
一项潜在的社会效益：自动化构建可以减少团队成员之间的毒性。如果开发人员每天重复执行一次或多次多步骤流程，错误就会悄悄出现。对于手动构建，团队成员可能会有这样的态度：“我无能的开发人员不记得如何每天正确进行构建.你会认为他们现在已经把它放下了。”通过自动化构建，出现的任何问题都是程序的问题——当然，程序是某人编写的，但仍然如此。
One potential social benefit: automated builds could decrease toxicity among team members. If developers are repeatedly carrying out a multi-step process one or more times per day, mistakes are going to creep in. With manual builds, teammates might have the attitude, "My incompetent developers can't remember how to do builds right every day. You'd think they have it down by now." With automated builds, any problems that come up are problems with a program - granted, a program that someone wrote, but still.