内容


将 SonarQube 集成到 DevOps 环境中

持续集成和持续交付

Comments

自动化是软件开发改进的一个关键实践。DevOps(开发运营)是软件开发领域内的一种趋势。DevOps 的定义有很多种。不过,“自动化” 很可能是该定义的一部分。虽然软件开发被自动化,但人的行为对该流程也是有所贡献的。不同团队成员编写的代码各不相同,风格也各异。有些开发人员会省略代码中的注释。Continuous Integration(CI,持续集成)、Continuous Delivery(CD,持续交付)、Continuous Testing(持续测试)都是与 DevOps 相关的词语。因为代码得到了系统的分析,所以可以减少多种编码错误风​​险。这方面的两个最佳实践分别是静态代码检查,以及通过应用程序安全测试来测试代码的漏洞。

本文将介绍如何在持续交付流程中部署一个静态代码检查流程。IBM SmartCloud Continuous Delivery 被用作检查状态源代码的一个示例。不过,本文中所使用的方法也可用于多种流程,比如来自 IBM 的持续集成(如 IBM® Rational Build Forge®)或持续部署(uDeploy)解决方案。

IBM SmartCloud Continuous Delivery 解决方案和 SonarQube

IBM SmartCloud Continuous Delivery 包括 DevOps 的大部分关键实践,并提供了额外的功能,包括工作负载部署器组件,该组件定义了部署模式和对云系统(IBM® PureSystems™、IBM® Workload Deployer、IBM SmartCloud® Provisioning 等)的自动部署。有关的更多信息请参阅在文章底部的参考资料部分。

SonarQube 是一个开源项目,用于源代码静态检查。它支持 20 种语言。报告是实时运行的。SonarQube 称此为 Continuous Inspection(持续检查)。

本文中所用术语的定义

因为没有 “持续<流程>” 的标准定义,需要先定义在本文中所使用的术语。

备注:本文中所使用的定义在各出版物中有所不同。

持续交付
(CD) 一个分阶段的自动化流程。它从软件构建开始,完成软件开发的以下这些阶段:打包、自动部署到测试系统、预生产质量保证系统,可能还包括部署到生产系统。自动化系统测试往往是针对已部署的系统而运行的。  
持续集成 (CI)
一个自动化的软件构建和测试过程,通常用于开发测试。持续集成是在每天的基础上(或在开发人员将新的源代码带入源代码库时)执行的。这个过程与持续交付类似,惟一区别是其主要重点是软件构建和单元/特性测试,而不是系统测试。 

有些公司可能会每天运行持续交付。如果每天运行持续交付,那么持续集成将被包含在持续交付流程中。

交付管道包括下面列出的步骤,如图 1 所示。

构建
从存储库加载源代码。然后,运行构建流程。 在这个步骤中,可以运行单元测试工具和代码覆盖工具。也可以运行代码分析。如果有错误,那么交付管道会停止运行。 
发布
构建包被存储在库服务器中。库服务器还存储了相关的信息,比如构建的质量状态及所有关联的文档。 
部署
应用程序被部署到物理和/或虚拟主机。如果虚拟主机不可用,那么云接口将会提供虚拟机。 
验证
自动测试:运行集成测试(功能测试)、性能测试和安全测试。  
生产
如果您选择部署到生产环境中,那么构建被发送到生产系统,以获得利益相关者的反馈。在面向合规性的软件开发项目中,生产步骤可能不会发生。  

备注:本文的重点是代码分析。文章的样例从构建步骤开始,并以验证步骤结束。

图 1. 典型的交付管道流程
交付管道的步骤
交付管道的步骤

解决方案架构

图 2 显示了解决方案架构。IBM SmartCloud Continuous Delivery 解决方案是解决方案架构的基础,如图 2 所示。

图 2. 基于 SmartCloud Continuous Delivery 的解决方案架构
解决方案基础架构
解决方案基础架构

在本例中,Ruby Make (Rake) 被用作交付管道的一个实现。可以根据工程师的需求或事件(如调度程序)来启用 Jazz Build Engine,它会运行交付管道。如果从客户端发出请求,则还会运行 Rake 实用程序。在本文中,是从 IBM® Rational Team Concert™ 客户端手动调用交付管道流程。

按照以下步骤,在解决方案架构上实现交付管道:

  1. 构建。构建步骤是在 Jazz Build Engine 组件上运行的。交付流程从 Rational Team Concert 中的存储库加载源代码。SonarQube 执行静态检查,并最终构建软件。在此阶段,静态检查的结果被存储在 SonarQube 服务器中。
  2. 发布。Jazz Build Engine 将构件和基础架构自动化代码发布到 Library Server。
  3. 部署。Jazz Build Engine 请求云主机提供测试所需的任何虚拟机。云主机指引虚拟机在哪里加载构建构件及相关文件,比如设置代码(基础架构自动化代码)。然后,每个虚拟机从库服务器加载软件和基础架构自动化代码。配置它们自己是部署步骤的最后一部分。
  4. 测试。无论是否通过系统测试,Jazz Build Server 都对所提供的虚拟机运行系统测试。

在本文中,不打算探索交付管道流程 (rakefile)。有关 Ruby Rake 实用程序的信息,请参阅参考资料部分。

清单 1. rakefile 静态检查测试

  desc "Static check the application"
  task :static_check_application => :setup do
    
    log.info "Static checking the source codes ..."

	activity = build_system.start_activity(build, "Static Checking source codes ...")

    build_script_dir = File.join(File.dirname(__FILE__), "..", "JKEBuildScripts")
    current_dir=File.dirname(__FILE__)
    
    cd "#{current_dir}/.."
	sonar_runner_cmd="/opt/sonar-runner-2.2/bin/sonar-runner"
	sh "#{sonar_runner_cmd} -Dproject.settings=#{build_script_dir}/sonar-project.properties"

	build_system.complete_activity(activity)

  end

Rake 使用任务的概念来运行流程。在 rakefile 文件中创建 :static_check_applicationlog.infobuild_system.start_activity Ruby 函数被调用。这会提示构建系统(在本文中是 Jazz Build Engine)对静态检查的开始处进行标记。主程序是:

sh "#{sonar_runner_cmd} -Dproject.settings=#{build_script_dir}/sonar-project.properties"

命令 sonar-runner 将会读取由选项 –Dproject.settings 设置的项目。该文件指定了项目名称和源代码的位置。清单 2 是一个检查源代码的示例文件。

清单 2. Sonar-project.properties

# required metadata
sonar.projectKey=my:project
sonar.projectName=JKE project
sonar.projectVersion=1.0

# optional description
sonar.projectDescription=JKEBanking

# path to source directories (required)
sonar.sources=JKEJavaUI/src,JKEBusinessLogic/src,JKEDBAccess/src,JKEServer/src

# The value of the property must be the key of the language.
sonar.language=java

# Additional parameters
sonar.my.property=value

运行交付管道

通过从 Rational Team Concert Web 客户端请求交付流程,可以运行 Ruby Rakefile。图 3 显示了如何启动交付管道。虽然 Request Build 按钮显示了 build,但它通过在 Jazz Build Server 上的 Ruby Make 进程来启动交付管道运行。在交付流程开始后,系统会显示进度和预计完成时间。本例从构建到系统测试总共花了 8 分钟时间。本文中的示例是 JKEBanking。该项目是一个人工银行应用程序,创建该应用程序是为了通过所有系统测试。

图 3. 启动交付流程
启动交付流程
启动交付流程

图 4 显示了交付管道和交付流程的结果。SonarQube 在交付过程中执行静态检查。为了验证所部署的应用程序处于活动状态,将会运行系统测试。

图 4. 交付管道活动
样例软件交付的交付管道。
样例软件交付的交付管道。

图 5 显示了测试结果。零失败,零错误。所有测试都是成功的。

图 5. 交付管道的系统测试结果
交付管道的系统测试结果。
交付管道的系统测试结果。

分析结果

图 6 所示的 SonarQube 仪表板显示了一个静态检查的样例结果。在代码中有 270 个违规行为。其中两个违规行为属于严重违规!

图 6. JKEBanking 应用程序的 SonarQube 仪表板
分析的 Sonar 仪表板
分析的 Sonar 仪表板

图 7 和图 8 显示了两个关键消息。SonarQube 列出严重程度,并用红色突出显示源代码。在突出显示的源代码下面,是代码错误的解释。

图 7. JKEBanking.java 代码中的严重错误示例
JKEBanking.java 代码中的关键消息
JKEBanking.java 代码中的关键消息
图 8. GenerateData.java 代码中的关键消息
用红色突出显示的关键消息
用红色突出显示的关键消息

图 7 显示消息 "Avoid catching throwable."..其中的 throwable 表示它在该语句中捕获的所有异常。在图 8 中,generateData.java 代码和 if 语句在代码块内没有要执行的语句。两者在静态代码分析中均被视为 “关键” 消息。

备注:虽然这只是用于演示 SonarQube 集成的一个样例应用程序,但这种情况也可能出现在实际的场景中。

有些应用程序的运行可能只是个意外。重要的是要提醒自己,系统测试并不总是彻底检查所有可能的场景或用例。这是在发布后出现缺陷逃逸(defect escape)的原因之一。持续检查可以降低这些缺陷逃逸的风险。

结束语

即使从系统测试的角度来看系统似乎在完美运行,代码质量可能仍然不够好。SonarQube 有助于提高代码质量。通过在持续集成和持续交付(DevOps)环境中包括静态检查流程,可以在发布有价值的软件后持续地大幅提高软件的代码质量,并降低失败的风险。

致谢

作者想感谢领导 DevOps 解决方案开发的 Wei Li,还要感谢我的经理 Paul Weiss,是他鼓励我发布文章。


相关主题

  • SonarQube 3.6代码质量管理实战:SonarQube 是一个开源的代码质量管理系统,本文介绍了 SonarQube 的工作原理,并从项目实战的角度讲解了使用 SonarQube3.6 进行项目代码质量管理的流程和注意事项。
  • 了解有关 IBM SmartCloud Continuous Delivery 的更多信息。
  • 演化架构和紧急设计:设计环境因素。作者 Neal Ford(IBM developerWorks,2010 年 12 月)。
  • Ruby Make 实用程序是基于 Ruby 语言的构建工具。
  • SonarQube 是一个管理代码质量的开放平台。
  • Enterprise Chef 自动化服务器和应用程序的配置、部署和扩展。
  • 浏览 developerWorks 上的 Rational 软件专区,获得有关 Rational 协作和集成解决方案实现软件和系统交付的技术资源、最佳实践和信息。
  • Jazz.net 下载 Rational Team Concert,多达 10 位开发人员可以不限时地免费试用它(要求注册)。您也可以选择在沙箱中试用它,无需将它安装在自己的系统上。
  • 下载 免费试用版本 的 Rational 软件。

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational, Cloud computing
ArticleID=960617
ArticleTitle=将 SonarQube 集成到 DevOps 环境中
publish-date=01232014