到底什么被认为是“破坏构建”？
在 CI 环境中，到底什么才被视为损坏的构建？
我可以想象几个答案（编译、测试通过、指标在范围内、文档存在等的任意组合），但我不确定其中哪些是规范的。
例如，就在今天，我实际上签入了所有代码更改，但忘记提交 Visual Studio 项目文件，从而破坏了单元测试。 （尽管我确实三次检查了我的提交，因为它是谷歌代码上的公共 OSS 项目）。
在第一次提交后，我可以轻松地在一分钟内解决这个问题，但是我现在应该认为自己是一个构建破坏者吗？
如何配置 CI 环境：是构建每个修订版还是每次完整构建后仅使用最新版本，还是使用基于时间的检查来检查新修订版？
In a CI environment, what exactly is considered a broken build?
There are several answers I can imagine (any combination of compiles, tests pass, metrics are in range, documentation exists etc.) , but I am not sure which of these are cannoncial.
For example, just today it happened to me that I actually checked in all code changes but forgot to commit the Visual Studio project file, thus breaking the unit tests. (even though I literally triple checked my commit, as it's a public OSS project on google code).
I was easily able to fix this in under a minute after my first commit, but should I consider myself a buildbreaker now?
How do you configure your CI environment: Is every revision built or only the newest version after each complete build, or do you use time based checking for new revs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
破坏构建会阻止任何用户依赖与 CI 环境相同的标准工具和代码集来获得编译和运行系统。
如果您的同事在最新时无法编译系统，因为缺少某些配置，则构建已损坏，不是吗？
如果你的同事不能确信单元测试能够通过，因为其中一个测试很不稳定，那么构建就被破坏了，不是吗？
如果你有自动化的性能测试，并且你的项目必须进行优化，我也会说，如果你的代码运行得不够快，你就破坏了构建（但这是有争议的）
我会例如，不要太关注代码覆盖率或其他指标。
破坏构建的情况是有可能发生的。 CI 只是确保在您应该发货的当天不会发生太多这种情况；）
Breaking a build is preventing any user that relies on the same standard tools and set of code than your CI environnment to get a compiling and running system.
If your coworkers cannot compile the system when they're up to date, because some config is missing, the build is broken, isn't it ?
If you coworkers cannot be confident that unit tests pass, because one of them is flaky, the build is broken, isn'it ?
If you have automated performance tests, and you're project have to be optimized, I would go as far as too say that if you code doesn't run fast enough, you've broken the build (but that is arguable)
I would not be so strongly minded about code coverage, or other metrics for example.
Breaking the build can happen. CI is just there to make sure it doesn't happen too much on the day you're supposed to ship ;)
对于我们来说，每当测试套件在新提交后失败时，我们都会使用术语“破坏构建”。
所以，在你的例子中，是的，你会破坏构建（至少根据我们公司的说法）
for us, we use the term "breaking the build" any time the test suite fails after a new commit.
so, in your instance, yes you would have broken the build (according to our company at least)
只要您因为简单的人为错误（例如忘记提交某些内容）而破坏了构建，并且只要这是例外而不是规则，我就会说没关系。只要您注意快速修复这个问题:)
另一方面，如果有人在提交之前没有在他/她的机器上本地执行完整的构建，从而定期破坏构建，那么这是纪律不严的迹象并不真正关心其他团队成员和开发过程的团队成员。
我的经验是，让人们更加小心的一种有效方法是将 CI 服务器设置为在（且仅当）构建状态发生变化时发送电子邮件，并将“罪魁祸首”打开收件人：列表和抄送：团队的其他成员。我想你可以称之为“羞耻因素”；）
As long as you broke the build because of a simple human error (like forgetting to commit something) and as long as this is an exception and not the rule, I would say it's OK. As long as you take care to fix this quickly :)
On the other hand, if somebody breaks builds on a regular basis by not executing the complete build locally on his/her machine before committing, then this is a sign of an ill-disciplined team member who doesn't really care for other team members and for the development process.
My experience is that one effective way to make people be more careful is to set up your CI server to send an email when (and only when) the status of the build changes, with the "culprit" on the To: list and the rest of the team on the Cc:. I guess you can could call it a "shame factor" ;)
损坏的构建是指任何未通过自动化测试套件的构建。
你是一个建筑破坏者。 ;) 只要你能快速修复它，这并不是什么大问题。 CI 环境的重点是捕获错误，而不是让人们害怕提交。
我的公司为每个正在生产或即将生产的分支建造尖端。我们在每天凌晨 4 点的每次提交时都会执行此操作。我们使用的是 Mercurial，因此此处提交意味着将更改推送到集成存储库。
A broken build is anything that doesn't pass the automated test suite.
You're a build breaker. ;) That's not really a big deal as long as you fix it fast. The whole point of a CI environment is to catch bugs, not make people afraid to commit.
My company builds the tip of each branch that is either in production or next up for production. We do this on every commit and each day at 4am. We're using Mercurial, so commit here means pushing changes to the integration repo.
理想情况下，您有
计划每晚运行以从源代码构建应用程序的自动化脚本。
用于将二进制文件复制到一个目录/目录集的脚本，可以从该目录运行另一个脚本来部署应用程序（如果该应用程序在您的环境中运行），或者用于为客户创建可交付成果。
运行并验证所有组件通过所有测试的自动化测试套件。
验证构建是否已正确构建的自动化脚本。
如果验证脚本失败，自动化脚本/监控系统会发出警报。
当上述过程生成警报时，则被视为“破坏构建”。
但由于程序/流程因公司而异，因此可能有不同的定义。在某些地方，它可能会破坏单元测试。其他人可能会检查源代码，导致代码无法编译。
Ideally, you have
automated script that is scheduled to run each night to build the application from source code.
Scripts to copy the binaries to a directory/set of directories from which another script can be run to deploy the application if it is running in your environment, or used to create deliverables for a customer.
Automated suite of tests that run and verify all components pass all tests.
Automated script that verifies that the build has been built correctly.
Automated script/monitoring system that sends out an alert if the verification script fails.
When an alert is generated by the above process, then that is considered "breaking the build".
But since procedures/processes can vary from company to company, there may be alternate definitions. In some places it may be breaking the unit tests. Others it may be checking in source code that results in the code being unabl to compile.
破坏构建是指提交任何导致无法（或可能但不明智）部署项目的更改。
修复损坏的构建不会修复损坏的构建，但可以创建新的未损坏的构建。
我将 CI 服务器配置为在每次提交时创建最小构建，并在每个时间段创建最大构建。该周期取决于从事该项目的人数（人越多，提交就越多）和构建持续时间（您可以每次运行单元测试套件，但 30 分钟的验收测试套件每天运行一到两次）。
Breaking the build is commiting any changes that make it impossible (or possible but not smart to do) to deploy the project.
Fixing a broken build does not repair the broken build, but makes it possible to create a new non-broken build.
I configure my CI-server to create a minimal build on every commit, and create a maximum build every period of time. The period depends on the number of people working on the project (more people is more commits) and the build duration (You can run your unit test suite every time, but the 30min. acceptance test suite once or twice a day).