hudson与sonar的集成.docx

上传人:b****1 文档编号:2833311 上传时间:2023-05-04 格式:DOCX 页数:14 大小:121.25KB
下载 相关 举报
hudson与sonar的集成.docx_第1页
第1页 / 共14页
hudson与sonar的集成.docx_第2页
第2页 / 共14页
hudson与sonar的集成.docx_第3页
第3页 / 共14页
hudson与sonar的集成.docx_第4页
第4页 / 共14页
hudson与sonar的集成.docx_第5页
第5页 / 共14页
hudson与sonar的集成.docx_第6页
第6页 / 共14页
hudson与sonar的集成.docx_第7页
第7页 / 共14页
hudson与sonar的集成.docx_第8页
第8页 / 共14页
hudson与sonar的集成.docx_第9页
第9页 / 共14页
hudson与sonar的集成.docx_第10页
第10页 / 共14页
hudson与sonar的集成.docx_第11页
第11页 / 共14页
hudson与sonar的集成.docx_第12页
第12页 / 共14页
hudson与sonar的集成.docx_第13页
第13页 / 共14页
hudson与sonar的集成.docx_第14页
第14页 / 共14页
亲,该文档总共14页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

hudson与sonar的集成.docx

《hudson与sonar的集成.docx》由会员分享,可在线阅读,更多相关《hudson与sonar的集成.docx(14页珍藏版)》请在冰点文库上搜索。

hudson与sonar的集成.docx

hudson与sonar的集成

一、Hudson是一个可扩展的持续集成引擎。

主要用于:

1.持续、自动地构建/测试软件项目。

2.监控一些定时执行的任务。

Hudson拥有的特性包括:

∙易于安装-只要把hudson.war部署到servlet容器,不需要数据库支持。

∙易于配置-所有配置都是通过其提供的web界面实现。

∙集成RSS/E-mail/IM-通过RSS发布构建结果或当构建失败时通过e-mail实时通知。

∙生成JUnit/TestNG测试报告。

∙分布式构建支持-Hudson能够让多台计算机一起构建/测试。

∙文件识别-Hudson能够跟踪哪次构建生成哪些jar,哪次构建使用哪个版本的jar等。

∙插件支持-Hudson可以通过插件扩展,你可以开发适合自己团队使用的工具。

目前比较流行的持续集成工具:

∙CruiseControl(

∙Hudson(http:

//hudson-ci.org/)

∙LuntBuild(

∙TeamCity(

∙AntHillPro(

∙Bamboo(

∙QuickBuild(

二、Sonar是一个开源平台,用于管理Java源代码的质量。

从Sonar1.6版本开始,Sonar从一个质量数据报告工具,转变成为现在的代码质量管理平台。

主要特点:

∙代码覆盖:

通过单元测试,将会显示哪行代码被选中

∙改善编码规则

∙搜寻编码规则:

按照名字,插件,激活级别和类别进行查询

∙项目搜寻:

按照项目的名字进行查询

∙对比数据:

比较同一张表中的任何测量的趋势

进行hudson和sonar的安装之前,需要具备的环境:

java6、tomcat6、mysql5、maven。

以上软件都要已经安装好。

首先是sonar的安装:

Sonar数据库的支持:

默认使用自带的Derby数据库、Mysql、Oracle、MSSqlServer、PostgreSQL。

本例使用mysql数据库。

第一步:

下载sonar:

http:

//www.sonarsource.org/。

第二步:

sonar下载下来是个zip文件,将其解压。

如果想使用sonar的默认数据库的话,可以直接到\bin目录下,执行相应操作系统的下服务启动文件。

如:

linux下的\bin\linux-x86-32\sonar.sh。

windows下的\bin\windows-x86-32\StartSonar.bat等等。

第三步:

浏览器打开http:

//localhost:

9000。

sonar默认是监听9000端口的。

第四步:

进入后台,admin/admin

第五步:

sonar中的数据统计是依靠maven的。

在相关maven项目根目录下执行:

mvncleaninstallsonar:

sonar。

即可将数据导入sonar数据库中。

如果想使用其它数据库的操作:

第一步,创建数据库

ApacheDerby是Sonar默认安装的数据库,并且不需要你安装。

它能很好的用于Sonar的演示,但是在实际运用中我推荐你使用性能更好更强大的数据库。

Sonar对如下数据库提供支持:

MySQL5.x,Oracle10gXE,Postgresql和MSSqlServer2005。

第一件事就是为Sonar创建一个数据库。

表和索引会在Sonar激活后自动创建。

同时要给Sonar用户能够在数据库表中创建、禁止和更新对象的权限。

第二步,配置数据库

如果你不是使用默认的数据库,那么你可以编辑conf/sonar.properties配置数据库访问权限。

注释derby的配置并复制一份自定义来修改,下面是Sonar的数据库配置模板:

sonar.jdbc.url:

数据库URL

sonar.jdbc.driver:

驱动类

sonar.jdbc.user:

用户名默认sonar

sonar.jdbc.password:

密码默认sonar

Mysql示例:

sonar.jdbc.url:

jdbc:

mysql:

//localhost:

3306/sonar?

useUnicode=true&characterEncoding=utf8

sonar.jdbc.driver:

com.mysql.jdbc.Driver

sonar.jdbc.validationQuery:

select1

如果是Oracle,你必须手动复制JDBC驱动类到/extensions/jdbc-driver/oracle/目录下。

其它支持的数据库都已提供了驱动。

第三步,启动SonarServer

方式一-单独启动

Sonar默认的端口是“9000”,默认的上下文路径是“/”,默认的网络接口是:

“0.0.0.0”。

一旦激活,Sonar服务器就可以使用http:

//localhost:

9000。

这些参数都可以在conf/sonar.properties修改。

下面提供一个http:

//localhost:

80/sonar的示例:

sonar.web.host:

192.0.0.1

sonar.web.port:

80

sonar.web.context:

/sonar

可以通过如下脚本启动Sonar服务器:

linux/mac:

bin/[YOURPLATEFORM]/sonar.shstart

OR

windows:

bin/windows-x86-32/StartSonar.bat

 同样你可以启动bin/windows-x86-32/InstallNTService.bat把它注册为一个Window服务,然后再启动bin/windows-x86-32/StartSonar.bat

方式二-部署到Tomcat

打包步骤如下:

编辑conf/sonar.properties还原成标准格式(就是不修改端口之类)。

确保部署到应用服务器时conf/wrapper.conf未被使用过。

在war/目录下执行build-war.sh脚本(Windows下执行build-war.bat)。

部署war/sonar.war到应用服务器。

通过http:

//loaclhost:

8080/sonar访问,继续安装步骤。

为了避免内存溢出,增加内存堆栈的大小。

在Tomcat启动前设置CATALINA_OPTS环境变量:

CATALINA_OPTS=”-Xms1024m-Xmx1024m-Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true-XX:

MaxPermSize=256m”

第四步:

配置到Maven中

因为Sonar是通过Maven2插件来分析源代码并把结果注入到数据库的。

这就是为什么我们必须在Maven的配置里设置数据库的属性。

编辑位于$MAVEN_HOME/conf或者~/.m2下的settings.xml文件,然后在添加step3中的参数。

如果数据库和服务器不在同一台主机,你还必须通过’sonar.host.url’指定服务器地址。

sonar

true

–mysql–>

jdbc:

mysql:

//localhost:

3306/sonar?

useUnicode=true&characterEncoding=utf8

com.mysql.jdbc.Driver

sonar

sonar

–remotehost–>

http:

//myserver:

1234

 注意:

属性不能以”/”结尾。

否则,MavenSonar插件将报找不到驱动类的错误。

同样,为了避免内存溢出,推荐增加内存堆栈的大小。

设置MAVEN_OPTS环境变量:

exportMAVEN_OPTS=”-Xmx512m-XX:

MaxPermSize=256m”

Hudson的安装

第一步:

下载hudson:

http:

//hudson-ci.org/

下载hudson.war,并拷入Tomcat安装目录下的Webapp中,启动Tomcat,hudson就成功安装了。

第二步:

在hudson中安装插件

Hudson的插件是hpi格式的。

Hudson插件的安装方式:

1、在“系统管理”-“管理插件”-“可选插件”中添加

2、在“系统管理”-“管理插件”-“高级”中直接上传。

3、在hudson的用户目录下直接添加。

Hudson的默认工作目录是在用户根目录下的/.hudson目录里了。

例如:

Linux:

/root/.hudson。

Hudson的工作目录是hudson将源码下载后的存放地址,和功能运行地址

直接将hpi文件复制到用户根目录下的/.hudson/plugins。

Hudson插件下载地址:

http:

//hudson-ci.org/download/plugins/

安装完插件后,要重启服务器才能生效。

第三步:

hudson配置并集成sonar。

按以上步骤,将sonar插件下载下来。

安装。

后即可使用了。

1、建立数据库,命名为sonar,不用创建任何表

2、找到sonar目录中conf文件夹下的sonar.properties文件,设置数据库,以数据库为MySQL为例

3、找到Maven安装目录中conf文件夹下的settings文件,用记事本打开按下图进行进行修改

4、依次运行%sonar安装目录%/bin/windows-x86-32中的InstallNTService.bat,StartNTService,StartSonar,此时sonar就已经成功启动了

5、重启tomcat,进入hudson页面C:

\{IP地址}:

{端口号}\hudson

6、进入系统管理,点击系统设置,找到Maven,按如下方式设置

7、找到sonar,按照第五步骤中Maven的设置进行设置,即可,如下图

8、新建任务,使用freestyle模式或maven模式,建议使用maven模式

点击OK,进入设置页面

(1)设置源码库地址:

若需密码,可点击RepositoryURL输入框右侧问好,点击thislink,进入下面的页面,输入用户名和密码,点击OK即可,关闭

(2)拉到页面最下方,勾选sonar即可,其他无需设置,sonar功能已经完善

9、点击save,保存设置。

 

FindBugs检查程序生成的class的工具

PMD检查源码

CheckStyle检查源码,主要关注源码格式

 

PMD扫描Java源代码并且寻找潜在的问题像:

∙可能存在的bug-空的try/catch/finally/switch语句

∙Deadcode-未用过的local变量,参数和私有方法

∙不最适宜的代码-浪费的String/StringBuffer用法

∙过度复杂的表达式-多余的if语句,for循环thatcouldbewhile循环

∙重复的代码-复制/粘贴的代码意味着复制/粘贴的bug

FindBugs

  静态分析工具承诺无需开发人员费劲就能找出代码中已有的缺陷。

当然,如果有多年的编写经验,就会知道这些承诺并不是一定能兑现。

尽管如此,好的静态分析工具仍然是工具箱中的无价之宝。

在这个由两部分组成的系列文章的第一部分中,高级软件工程师ChrisGrindstaff分析了FindBugs如何帮助提高代码质量以及排除隐含的缺陷。

代码质量工具的一个问题是它们容易为开发人员提供大量但并非真正问题的问题——即伪问题(falsepositives)。

出现伪问题时,开发人员要学会忽略工具的输出或者放弃它。

FindBugs的设计者DavidHovemeyer和WilliamPugh注意到了这个问题,并努力减少他们所报告的伪问题数量。

与其他静态分析工具不同,FindBugs不注重样式或者格式,它试图只寻找真正的缺陷或者潜在的性能问题。

  FindBugs是什么?

  FindBugs是一个静态分析工具,它检查类或者JAR文件,将字节码与一组缺陷模式进行对比以发现可能的问题。

有了静态分析工具,就可以在不实际运行程序的情况对软件进行分析。

不是通过分析类文件的形式或结构来确定程序的意图,而是通常使用Visitor模式(请参阅参考资料)。

图1显示了分析一个匿名项目的结果(为防止可怕的犯罪,这里不给出它的名字):

  在FindBugs的GUI中,需要先选择待扫描的.class文件(FindBugs其实就是对编译后的class进行扫描,藉以发现一些隐藏的bug。

)。

如果你拥有这些.class档对应的源文件,可把这些.java文件再选上,这样便可以从稍后得出的报告中快捷的定位到出问题的代码上面。

此外,还可以选上工程所使用的library,这样似乎可以帮助FindBugs做一些高阶的检查,藉以发现一些更深层的bug。

  选定了以上各项后,便可以开始检测了。

检测的过程可能会花好几分钟,具体视工程的规模而定。

检测完毕可生成一份详细的报告,藉由这份报告,可以发现许多代码中间潜在的bug。

比较典型的,如引用了空指针(nullpointerdereference),特定的资源(dbconnection)未关闭,等等。

如果用人工检查的方式,这些bug可能很难才会被发现,或许永远也无法发现,直到运行时发作…当除掉了这些典型的(classic)bug后,可以确信的是,我们的系统稳定度将会上一个新的台阶。

  以目前遇到的状况来看,FindBugs可以有两种使用时机。

  开发阶段

  当Developer完成了某一部分功能模块开发的时候(这通常是指代码撰写完成,并已debug通过之后),可藉由FindBugs对该模块涉及的java文件进行一次扫描,以发现一些不易察觉的bug或是效能问题。

交付新版的时候,开发团队可以跑一下FindBugs,除掉一些隐藏的Bug。

FindBugs得出的报告可以作为该版本的一个参考文档一并交付给测试团队留档待查。

  在开发阶段使用FindBugs,一方面开发人员可以对新版的品质更有信心,另一方面,测试人员藉此可以把更多的精力放在业务逻辑的确认上面,而不是花大量精力去进一些要在特殊状况下才可能出现的BUG(典型的如NullPointerDereference)。

从而可以提高测试的效率。

  维护阶段

  这里指的是系统已经上线,却发现因为代码中的某一个bug导致系统崩溃。

在除掉这个已暴露的bug之后,为了快速的找出类似的但还未暴露的bug,可以使用FindBugs对该版的代码进行扫描。

当然,在维护阶段使用FindBugs往往是无奈之举,且时间紧迫。

此外,如果本来在新版交付的时候就使用过FindBugs的话,往往意味着这种bug是FindBugs还无法检测出的。

这也是FindBugs局限的地方。

  FindBugs出到目前的版本,功能已经相当强大,不过也有待完善的地方。

从实际使用来看,有一些隐藏的bug并不能靠FindBugs直接发现。

那么,可不可以撰写一个新的Detector,来发现这种将一个未初始化的reference传来传去而形成的潜在的bug呢?

理论上来讲,应该是可以的。

这个Detector目前还未实现。

哪位如果有兴趣的话,可以参考FindBugs,Part2:

Writingcustomdetectors(扩展阅读)这篇文章,帮忙实现这个Detector。

实现一个新的Detector,便可以检测出一种新型的bug,这样不知又可以帮开发人员省去多少人工检查的时间,功德无量啊。

  FindBugs也不能发现非java的Bug。

对于非java撰写的代码,如javacript,SQL等等,要找出其中可能的bug,FindBugs是无能为力的。

当然,javacript中的bug似乎还不至于使系统崩溃,而SQL中的bug往往又跟业务逻辑相关,只要测试仔细一些应该是可以发现的。

  FindBugs不过是一个工具。

作为开发人员,当然首先要在编程的时候努力避免引入bug,而不要依赖于某个工具来为自己把关。

不过由于代码的复杂性,一些隐藏的bug确实很难靠咱们的肉眼发现。

这时,应用一些好的工具或许就可以帮你发现这样的bug。

这便是FingBug存在的价值。

  为什么应该将FindBugs集成到编译过程中?

  经常问到的第一个问题是为什么要将FindBugs加入到编译过程中?

虽然有大量理由,最明显的回答是要保证尽可能早地在进行编译时发现问题。

当团队扩大,并且不可避免地在项目中加入更多新开发人员时,FindBugs可以作为一个安全网,检测出已经识别的缺陷模式。

我想重申在一篇FindBugs论文中表述的一些观点。

如果让一定数量的开发人员共同工作,那么在代码中就会出现缺陷。

像FindBugs这样的工具当然不会找出所有的缺陷,但是它们会帮助找出其中的部分。

现在找出部分比客户在以后找到它们要好——特别是当将FindBugs结合到编译过程中的成本是如此低时。

  一旦确定了加入哪些过滤器和类,运行FindBugs就没什么成本了,而带来的好处就是它会检测出新缺陷。

如果编写特定于应用程序的检测器,则这个好处可能更大。

  生成有意义的结果

  重要的是要认识到这种成本/效益分析只有在不生成大量误检时才有效。

换句话说,如果在每次编译时,不能简单地确定是否引入了新的缺陷,那么这个工具的价值就会被抵消。

分析越自动化越好。

如果修复缺陷意味着必须吃力地分析检测出的大量不相干的缺陷,那么您就不会经常使用它,或者至少不会很好地使用它。

  确定不关心哪些问题并从编译中排除它们。

也可以挑出确实关注的一小部分检测器并只运行它们。

另一种选择是从个别的类中排除一组检测器,但是其他的类不排除。

FindBugs提供了使用过滤器的极大灵活性,这可帮助生成对团队有意义的结果,由此我们进入下一节。

  确定用FindBugs的结果做什么

  可能看来很显然,但是您想不到我参与的团队中有多少加入了类似FindBugs这样的工具而没有真正利用它。

让我们更深入地探讨这个问题——用结果做什么?

明确回答这个问题是困难的,因为这与团队的组织方式、如何处理代码所有权问题等有很大关系。

不过,下面是一些指导:

  可以考虑将FindBugs结果加入到源代码管理(SCM)系统中。

一般的经验做法是不将编译工件(artifact)放到SCM系统中。

不过,在这种特定情况下,打破这个规则可能是正确的,因为它使您可以监视代码质量随时间的变化。

  可以选择将XML结果转换为可以发送到团队的网站上的HTML报告。

转换可以用XSL样式表或者脚本实现。

有关例子请查看FindBugs网站或者邮件列表(请参阅参考资料)。

  像FindBugs这样的工具通常会成为用于敲打团队或者个人的政治武器。

尽量抵制这种做法或者不让它发生——记住,它只是一个工具,它可以帮助改进代码的质量。

有了这种思想,在下一部分中,我将展示如何编写自定义缺陷检测器。

Checkstyle简介,其是目前最广泛使用的代码检查工具,功能强大,操作简单可以和Ant结合使用,最重要的是其是OpenSource的,你不用担心收到律师函,哈哈!

   主页:

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 教学研究 > 教学计划

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2