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

  一、总体说明：      

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

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

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

先看一张架构图,如图：

 

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

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

5、会告诉团队反馈本次集成失败是谁提交什么文件，或者失败的原因（比如说错误堆栈信息等），

 由于内容太多，本篇只介绍持续集成CI服务器、sonar、部署、反馈相关性的东西，项目管理、缺陷、自动化我就不介绍了。本人最近才写文档，如有什么不对的地方，还请大家指正。

二、持续集成-CI服务

先说持续集成框架的搭建，一个持续集成技术框架离不开一个CI服务器，我们所有的一切都会围绕着CI来做文章，这里选择的是jenkins。因为jenkins相对比较成熟，有很多业内插件支持，而且可以扩展，怎么扩展请看我写的 blog《jenkins插件开发》，如果你的应用遵循maven管理，jenkins就非常适合了。jenkins的安装和介绍文档非常多，请看https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins;我这里主要介绍除了jenkins 插件之外的东西。   

主要分为以下几个方面：

   1）jenkins部署目录介绍 ：

             从jenkins下载war之后，可以通过各种方式部署，我这里就介绍通过tomcat部署后的目录介绍。hudson和jenkins部署都差不多，不过hudson部署后所有目录都是在

当前用户的根目录下一个隐藏的目录“.hudson”里，而jenkins是直接放在tomcat的webapps里，如：/home/admin/tomcat6/webapps/jenkins；

        A、全局配置 ：

   玩过jenkins或者hudson的同学都明白，我们有很多的配置。但是要知道一点，jenkins上数据存储是以xml方式存储的。比如说全局配置，会在/home/admin/tomcat6/webapps/jenkins下有个config.xml管理整个展现页面数据的存储。config.xml部分片段文件如下：

   

  
  1.509.1
  0
  NORMAL
  true
  
  
    true
    false
  
  
  ${JENKINS_HOME}/workspace/${ITEM_FULLNAME}
  ${ITEM_ROOTDIR}/builds
  
    false
  
  
    
      Java
      /usr/alibaba/java
      
    
  
  
  
  
  

      全局配置里很多都是以插件形式存在的，比如说jenkins对外提供的url，全局配置如图：

      jenkins部署目录都会存在一个全局配置xml：jenkins.model.JenkinsLocationConfiguration.xml，详细xml内容如下;

      


  address not configured yet 
  http://xxxxxx:8080/jenkins/

其他的细节有兴趣的可以研究一下。内容很多！

      B、jobs：

           jenkins或者hudson里所有的运行模式都是以job为维度的，在jenkins部署目录里专门有个jobs的目录“/home/admin/tomcat6/webapps/jenkins/jobs”，jenkins上所有的job都会在里面管理。进入某一个job，有相关以下内容：

    

     现在重点介绍几个文件和目录：

• config.xml：上面说jenkins或者hudson上数据的存储都是以xml存放，这个文件就是存放这个job的所有配置。从页面上可以通过“http://jenkins_url/jobs_name/config.xml”可以查看，config.xml管理的就是整个job构建生命周期里的所有策略。
• nextBuildNumber：jenkins下一次构建的序号
  
• scm-polling.log：检测svn是否有变更日志
  
• subversion.credentials：该分支co的svn用户名和密码。也可以通过在服务器端.subversion/config文件来设定其恒定性。
  
• lastStable：最近一些构建信息的软连接。指向的是builds里面的内容。这个文件夹下的内容很关键，有build.xml、changelog.xml、revision.txt，分别记录的是构建的记录、分支修改信息、以及当前构建的svn版本信息
• builds：记录的是本job构建所有历史信息

或许你会发现，这里怎么没有构建的源码，只有构建后的数据呢，如果你构建选择的服务器是master，那么会存在，如果你选择的是slave。这些信息全部在slave机器上。

      C、plugins：

             这个目录也是非常重要。为什么怎么说，上面介绍的时候已经说过，构建的整个过程都是插件来支持的，这个目录管理的就是jenkins上运行所有插件（有些插件是jenkins自带的插件），hudson和jenkins上插件命名的后缀也不太一样，hudson上插件后缀是以“.hpi”结尾的，而jenkins上是以”.jpi“为后缀，怎么打成这样的包，可以见我写的jenkins插件开发。根据pom里依赖的类型不同就会打成不同的包。jenkins默认情况下都是以jpi形式存在，如图：

只有jenkins部署，会解压成和插件名称对应的文件夹，和war部署差不多。上传插件的形式有两种：

• 通过页面上传和restart jenkins生效；如图：
• 直接将打成的hpi或者jpi的包丢到部署容器的jenkins/plugin目录。重启jenkins即可，一般性采用这种效率会高点

3、触发策略

4、jenkins怎么与外围系统交互

5、收集jenkins数据

sonar介绍