怎么搭建持续集成/质量数据度量中心（一）

  一、总体说明：      

    随着敏捷的推行，持续集成越来越流行，现在已经上升到持续交付的高度。自己听过和看过很多人分享过，自己本身也做过持续集成，如果说一个小团队说持续集成做的非常好，非常相信，但如果说一个公司或者一个非常大的团队持续集成、持续交付（搜索除外）做的比较好，我心理都会打下折扣；

       持续集成本身就是自动检测被测对象变更或者被测对象集成是否发生变化，一旦有变化就会触发一系列自动化（编译、构建、部署、反馈，从这些动作来看，持续还有许多基础设施要建设），但这些都是硬件；现实中我们持续集成难点在于发现集成中问题但是很少甚至没人去解决，得到反馈有很多说法，我们本身也比较多，比如问题定位不够精准化，管理上没有进行太多约束等等。这里不做太多累述；

       本篇不会去讲很多软性的东西，为什么题目命名为“持续集成/质量数据度量中心”，上一篇已经讲过，持续集成会产生很多质量数据，这些质量数据就是衡量一个产品、项目数据质量情况，如果用好这些数据，那么持续集成的威力会更加强大，本篇详细说明；

先看一张架构图,如图：

 

从上面这张图可以看出，我们会拿到项目中或者产品中所有的数据（请见我写的质量模型）。数据的威力开始呈现；下面举几个场景：

1、老大想看线上一个故障是由于什么产品、什么项目、什么需求导致、有哪些bug的，是谁导致了这个问题。发现了问题，就可以有相应的action解决
2、项目或者产品最近一年代码质量怎么样。
3、研发者本身能力（代码质量、故障、bug）模型，比如说当一个开发者投入项目时，可以预测到人员风险等。
4、同等项目（比如增量代码行数）比较，为后续项目资源可以做评估等。

5、会告诉团队反馈本次集成失败是谁提交什么文件，或者失败的原因（