持续集成工具QuickBuild

目前遇到/解决的问题：

1、RUN之后，只看见#Requests计数1  #Builds计数为零，查看日志显示检查build条件时挂住: Checking build condition on node 'xxx:8811'...

    ssh 设置无密码登陆OK

2、又出现错误: Failed to run command: /usr/bin/git log -1 --pretty=format:%H remotes/origin/master; 

    Repositories设置中把分支名称显式设定后OK; 上面的命令用法有问题,估计是quickbuild的bug，写明分支名称可以规避；

3、master step不能改变名字，要想运行其他step 需要把master step的类型设为串行或并行，然后把其他step设为master的子/孙step；

4、command栏里面的脚本开头最好加 #!/bin/bash; 否则解析 Redirect 重定向符号可能出错. (或者重定向符跟后面的文件名不要加空格也可以解决)；

5、openwrt要求以非root用户编译, 脚本里面加 [ `id` = 0 ] && su commenUser;   或者build的agent.sh启动时用普通用户启动；

6、Advance选项里 'Pre-Execute Action' 'Post-Execute Action' 的 'Excute a script' 中的script是什么语法？？ *NIX shell脚本不能执行。

-----------------------------------------------------------------------------------------------

官网下载就可以: 

文档: http://wiki.pmease.com/display/QB40/Documentation+Home

    安装: 

    step设置: 

网上看到的一些介绍，转载/mark过来

转载自 --- 链接地址: 

  持续集成工具--QuickBuild（一）

  持续集成工具--QuickBuild（二）

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

之前一直使用的持续集成工具是LuntBuild和Bamboo。LuntBuild一直更新很慢，缺少很多特性；而Bamboo是商用软件，需要用License，升级比较麻烦。
经过一段时间的研究，发现QuickBuild是一个比较适合的替代品。QuickBuild是LuntBuild的商用版，虽然是商用版，但是可以免费使用，且没有屏蔽任何功能，只是限制了同时只能管理16个项目，对于规模较小的软件公司，足够用了。
关于如何选择持续集成软件，可以参考《》。

QuickBuild由PMEase Incorporated开发【】。
官方的wiki中，对QuickBuild的用法有较为详细的说明。截止2011-11-28，最新的QuickBuild版本为V4.0.16，可以获取很多有用的【帮助信息】。
在使用QuickBuild之前，建议先把帮助好好读一下，绝对可以事半功倍。

QuickBuild对很多SCM工具都提供了良好支持，如ClearCase，CVS，Subversion，VSS等，使用非常方便。
相对而言，对变更管理工具的支持稍差一些，支持BugZilla，Jira等，但是还不支持ClearQuest，比较遗憾。
对于中小公司，如果之前正好使用CVS/Subversion +BugZilla，那么用QuickBuild创建持续集成环境，既能保持功能强大，又最为经济实惠！！

------------------------------------------------------------------------------

QuickBuild V4.0版本，和V2.x版本比较，最大的变化是首页由“Configures”改成了“DashBoards”页面。
V2.x版本的首页上只能显示配置的列表，以及一些简单状态。到了V4.0，不但允许用户创建多个“DashBoard” ，还支持在DashBoard的基础上，增加多个“Gadget”。这样只要打开首页，所有项目的持续集成情况都可以一目了然的显示出来。

Gadget，可以理解为持续集成的组件，常用的有:
1. Configuretion Tree:
     所有参与持续集成的项目列表，集成次数，当前请求数和最近一次集成的状态。
2. Build Stats:  
     关于某一个项目持续集成的统计数据。
此外，还包含了变更管理工具统计数据，代码覆盖率工具统计数据（Cobertura，EMMA，NCover），代码检查工具统计数据（Findbugs，PMD，checkStyle），以及单元测试统计数据等。可以看出，QuickBuild对Java软件开发的支持是比较好的。

不过，不管首页怎么变化，QuickBuild还是以"Configure"为核心的，比如免费版的QuickBuild就限制了只能同时使用16个"Configure"。
一份Configure中可以看做是对一个项目持续集成配置的总和。Configure可以继承和复制，使得管理员可以在很短的时间就创建多个Configure，提高工作效率。
Configure中比较重要的配置项有：
1.  Repositories：
    代码的维护管理，主要是同SCM工具的集成，源代码管理相关。
    QuickBuild中有一个很重要的特性：Proof Build，允许服务器编译、验证开发人员还没有CheckIn的代码，非常好用。这个特性后面会单独拿出来讲一下。
2.  Steps： 
     QuickBuild把持续集成分解为若干个可以独立运行并自由组合的步骤。
     每个Step都可以配置为并行或串行运行，甚至可以在多个Build Agent上同时运行，这样可以大大减少持续集成的时间。
     Steps一般采用这样的步骤：”前期环境准备”->通过SCM取源代码->“代码静态检查”->编译->"单元测试"->”自动化测试”->生成报告->通知相关责任人。
     打引号的步骤根据项目情况，可以自行选择。 
3.  Notifications：
     QuickBuild支持多种通知，Email是最为常用的了。

把以上三项配好，一个最基本的持续集成环境就搭建起来了。当然，要想真正把持续集成做好，还有很多细致的工作要做。
比如单元测试和自动化测试用例的编写和集成，就是一个长期的工作，不能一蹴而就的。

------------------------------------------------------------------------------

什么是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元。但是算算每年能提高多少工作效率，再乘以现在的工资，就会发现这笔开销还是很合算的。
    从另一个角度讲，如何把公司里所有计算机资源都充分应用起来，也是一个很值得研究的方向。

====================================================================

另外一篇: (原帖声明不让转载,so只mark一个链接;评论中有quickbuild和hudson的比较争论; 大家自己判断)