持续集成工具--QuickBuild（三）--ProofBuild

什么是Proof Build
通常程序员在合并代码前，都会自己编译并测试一下。但是这样做有很多局限性：
1. 程序员自己做测试，往往只测试了自己认为需要测的用例，而不是所有可能相关的用例，这样有可能造成一些MR泄露。
2. 一处代码修改可能需要在多个产品上验证，而程序员受研发环境或进度的影响，改动在某些产品上没有验证就认为通过了。
为了解决这类问题，QuickBuild提供了一个新功能，即Proof Build。Proof Build允许程序员将电脑上还没有CheckIn的代码先Merge到QuickBuild Server上，之后运行编译和自动化测试。这样就可以更全面的验证代码的质量。

ProofBuild功能的使用稍微有点复杂，不过在官方网站上有较为详细的说明，我这里就不再赘述了。
还请参考这个链接：【官方Help】 

 

QuickBuild ProofBuild的一些小问题：
1. User Agent上的代码，必须处于CheckOut状态的，才会被同步到QuickBuild服务器上编译。
    有的公司的版本控制很严格，必须提供充分的测试报告以后，才能开启CheckOut权限。这样同QuickBuild ProofBuild就形成了鸡生蛋还是蛋生鸡的死循环。当然也可以通过将本地代码改为私有分支的方式解决，但毕竟又耗费了额外的时间，影响客户体验。
2. ProofBuild需要在服务器端和客户端分别Update代码。如果代码量很大的，光更新代码就需要较长的时间。

QuickBuild的另外一个问题：对多核编译的支持不良。
    一台i7 CPU的电脑，如果不使用QuickBuild编译，可以完美支持8内核编译；但是使用QuickBuild服务器，只能开启4核编译。哪怕使用5核编译都会出错，目前还没有研究清楚为什么。 
    提到这个，忍不住想多说两句。做软件开发的公司里，电脑可以说是最不值钱的资产了。将电脑升级到i7，可能需要多支出3000元。但是算算每年能提高多少工作效率，再乘以现在的工资，就会发现这笔开销还是很合算的。
    从另一个角度讲，如何把公司里所有计算机资源都充分应用起来，也是一个很值得研究的方向。