作为一名构建工程师，我一直在寻找新的有趣的方法来改进我们的构建过程 - 包括寻找新的和有趣的方法来使我们的构建失败！
我还没有找到构建失败的原因的规范列表...所以我认为是时候创建一个了。考虑到这一点：
您看到构建失败的构建时检查 - 既明显又有创意？
答案 0 :(得分：7)
答案 1 :(得分：5)
Build中未批准的签到。检查过的代码与工作项或错误修复无关。
答案 2 :(得分：4)
答案 3 :(得分：2)
单元测试失败。
答案 4 :(得分：2)
代码未通过自动质量检查（FxCop等）。
答案 5 :(得分：2)
在介绍Continuous Integration的文章中，Martin Fowler提出了failure to run the application's suite of unit tests作为构建失败的一个令人信服的理由。
答案 6 :(得分：1)
编译警告失败
答案 7 :(得分：1)
在模块之间引入循环依赖（例如java包）。
答案 8 :(得分：1)
我的公司实际上并没有这样做，但是像我们这样的大型遗留代码库，在未记录的更改上失败会很好。如果没有某种类型的错误机票，我们的QA部门就不会知道测试这些更改，这太可怕了！
答案 9 :(得分：1)
检查不同jar文件（Java）中的重复类（相同的包和类名）。
答案 10 :(得分：0)
对编译失败的检查这么简单应该被认为是强制性的， nuff说。
导致破坏版本的签到应该是不可接受的，尽管可悲的事实是许多组织都接受这样做。
如果编译失败：
为什么呢？ 因为建筑被破坏。
答案 11 :(得分：0)
代码覆盖率降低或低于可接受的阈值。