1、DevOps

DevOps逐渐成为开发运维领域的一种趋势，对DevOps 的定义有很多种，但“自动化” 很可能是该定义的一部分。Continuous Integration（CI，持续集成）、Continuous Delivery（CD，持续交付）、Continuous Testing（CT，持续测试）都是与 DevOps 相关的词语，CI、CD、CT都强调自动化。

2、持续集成

持续集成是在每天的基础上（或在开发人员将新的源代码签入入源代码库时）执行一个自动化的软件构建过程，包括编译、打包、测试、部署等环节，这个过程重点关注软件构建和单元/特性测试、代码质量。

1、代码的希腊债务危机

我在《消除技术债务？DevOps可以这么用！》这篇文章中探讨了技术债务的定义、分类以及形成的原因，技术债的出现是由于开发者这7种致命的原罪所造成的：

• 重复

• 糟糕的复杂性分布

• 意大利面式设计风格

• 缺少单元测试

• 缺乏代码标准

• 潜在的bug

• 注释不足或过多，或者干脆不正确（单元测试对这种类型的bug无能为力）

当企业想要迁移到一个DevOps模型时，经常需要偿还高等昂的技术债务，往往陷入“技术债务的恶性循环”中，以至于任何迅速、敏捷的迁移方式都无法使用，这是技术债务中的“希腊债务危机水平”。

最近，我们看到的一个趋势是：如果企业不断地在DevOps自动化上寻找空间，就必须打破这种恶性循环，重新开辟一个新的良性循环。

如果可以自动完成一些常规的、容易出错的和时间密集型的任务，便可以利用效率和投资，就可以将更多的时间和成本投入技术负债偿还中。

在技术债务偿还后，企业将得到一个质量更高、更稳定和更灵活的应用程序，从而可以重新在自动化工作上投入更多的时间，并启动下一个周期的改善和提升。

2、持续集成与代码质量检查

代码质量的检查是持续集成中的一个关键环节，也是最容易低成本实现自动化的一个环节。代码质量的重要性不言而喻，代码质量水平决定了软件的可靠性、可维护性、执行效率、安全性等软件质量水平。

而大规模的软件系统的代码庞大而复杂，必须借助自动化手段辅助完成代码审查。

1、Sonar质量管理平台

随着 IT 行业中软件产品的推陈出新，客户对于软件产品的要求也越来越高，因此如何高质量的管理软件代码，及时地对代码质量进行分析并给出合理的解决方案就成为了当下必须要解决的一个问题。与当今众多的代码质量管理工具相比，Sonar更具有特色和竞争力，其优势主要体现为：它是一个开源的代码质量管理系统，支持 25+ 种语言，可以与Jenkins、Eclipse 和 JIRA 等其他外部工具集成，从而实现了对代码的质量的全面自动化分析和管理。

Sonar 为代码的质量管理提供了一个平台，对传统的代码静态检测如 PMD、FindBugs 等工具进行整合，可以说是目前最强大的代码质量管理开源工具之一。

2、代码规范的定义

在应用Sonar辅助实施DevOps，帮助开发改进代码质量的实践过程中，我们发现会碰到很多的问题，其中最大的问题是，由于之前累积的技术债务比较庞大，缺乏代码质量规范，代码质量低下，导致应用Sonar默认规则进行代码扫描时，扫描出来的违反代码规则的代码量非常大，一下子给开发人员巨大的压力，开发下意识会拒绝修改这么大量的问题。

所以必须对代码扫描规则进行筛选、定制，前期尽量挑选适量的、高级别的规则进行扫描应用，等开发习惯后再分阶段逐步应用更多的规则。

下面介绍常用的筛选策略：

1）针对不同系统（项目）进行评审、筛选、定制扫描规则集

企业内不同的系统（项目）的重要程度是有差异的，例如分为核心、重要、一般3种级别的系统，对不同系统定义的代码扫描规则集不同，例如：越重要的系统，规则范围越大（挑选的规则数量越多）、规则的严重级别设定越高。

2）针对不同系统（项目）的特点选取重点关注的规则类型

不同类型的系统（项目）的特点不一样，对代码质量的要求侧重点也会有差异，例如，有些系统侧重性能和执行效率，有些系统侧重可移植性。代码规则大致可分为以下几类：

• 可维护性（Maintainability）

• 性能（Efficiency）

• 可移植性（Portability）

• 可用性（Usability）

• 可靠性（Reliability）

3）每个规则有默认严重级别，需要根据项目情况调整重要级别

例如，在Sonar中展示的代码规则违反分类数量统计，分为5个级别：

• Blocker

• Critical 

• Major

• Minor

• Info

可通过Sonar的配置管理界面对具体某个规则的严重程度（Severity）进行调整设置。

通过一系列的筛选和调整后，Sonar的规则会适当减少，例如，下面是挑选了Sonar中专门由Findbugs进行扫描的规则，并且仅挑选严重级别为Blocker、Critical的规则，代码扫描规则的数量由原来的500多个个降到了200多个。

有了定制化的代码规则集后，我们还可以结合研发流程做质量门（质量标准），例如，下面是某企业对代码合规等代码质量标准的指标定义：

3、如何辅助开发更高效地完成代码质量优化？

定义好代码规则集、质量门之后，我们还需要做一些辅助性的工作，以便开发能更高效地完成代码质量优化。

例如，借助Sonar的SCM Activity插件，在代码扫描出问题时，定位关联到SVN库，查找最近是谁、在什么时间签入了这段代码，从而精准地通知相关开发人员复查和修改对应的代码问题。

另外，由于Sonar工具中的规则描述通常是简单的语句，开发人员（尤其是一些初级开发人员）对规则的原理、相关的编码技术不熟悉、不了解的情况下，会导致问题的修复速度减慢。因此，通常需要整理规则集文档辅助开发人员加速这个过程，例如对规则进行描述解释、举例说明问题、解决的办法的描述等：

本文介绍了DevOps推进过程中，如何结合持续集成的代码检查环节，基于Sonar平台实现代码自动检查，通过筛选规则、小范围逐步引入逐步习惯的方式，推动开发优化代码质量的具体做法。

注：本文在编写过程中参考了引用了以下文章的部分内容：

将 SonarQube 集成到 DevOps 环境中

http://www.ibm.com/developerworks/cn/rational/integrate-sonarqube-devops-environment/

SonarQube 3.6 代码质量管理实战

http://www.ibm.com/developerworks/cn/opensource/os-sonarqube/

使用 Sonar 进行代码质量管理

http://www.ibm.com/developerworks/cn/java/j-lo-sonar/