对代码高质量的追求从来都是不停歇的，对于如何保证提交代码的质量，可以划分两种：
（1）事后处理式：提交代码后，“通知”测试；
（2）事前预防式：提交代码前，“通知”测试；
方式（1）的缺点在于，如果测试发现问题时，代码已提交，如果期间其他人进行测试或基于已提交代码进行其他开发必然深受其害。
所以在实践中，方式（1）虽然最常见，但是效果并不好，因为只是发生错误后的处理，所以大多更倾向于方式（2）。
于是对于方式（2）的实现又衍生出两方式：
（1）同步方式：提交代码时->同步执行测试->测试通过允许提交，测试失败，拒绝提交。这种方式很容易成为程序员的噩梦，因为特别对于喜欢频繁提交的人来说，随着测试用例耗时的增加，同步等待的时间越长，所以为了减少同步等待时间，只能做些简单的编译检查或者极少的测试用例。
（2）异步方式：基于方式（1）的分析，从最佳实践上，果断选择异步方式，异步方式最常见实践是：提交代码到非产品库->通知测试->测试通过，自动将非产品库代码Merge到产品库，测试不通过不Merge。
其实这种方式如果不采取全自动化的方式更像大多程序员的“私有包实践”：checkout代码->修改代码build出“私有包”->测试->测试通过，将代码提交，否则不提交。相信做过这样的事情的人都能体会其中的繁琐，不言而喻，只要任何一项不是自动化，必将降低效率，同时也容易出错。所以自动化全异步方式是必然趋势。
如何实现：
目标： 可参考《持续交付》
核心思想：创建一个中间repo，所有代码提交只能进中间repo，一旦有代码提交到repo,通过预先配置好的hook通知jenkins中事先配置好的job，job接受到通知后，首先拿出repo的最新代码与产品代码master进行merge，然后基于结果代码做测试，如果成功，则push代码进master，如果失败，则不提交进master。这样一个过程使得master的代码一直都是经过测试考验的随时可部署的。
示例工具： Jenkins + GitLab
流程：
要点：(1) 禁止直接提交代码到主库master
具体执行：
（1）创建专门为测试而用的branch，例如test;
（2）为test branch设置web hook: 这里可以定制监听的事件，一般默认push即可
http://bkci.qa.com/jenkins/git/notifyCommit?url=http://gitlab.qa.com/jiafu/test-ci.git&branches=test
（3）设置jenkin job:
这里有3个地方要设置：
3.1 SCM: 注意Merge Before Build
3.2 Build Trigger: 勾选Poll Scm，否则通知能收到，但是执行不了。
3.3 Git Publisher: 勾选Push only if build success
经过以上几步简单操作，即可实现：再也不用担心产品代码因为自己的小失误而搞乱，始终保持产品库的整洁。
