1. 建设目标

根据相关代码规范，对项目中涉及的编程语言设置对应的质量阈，并完善项目的代码质量监控流程，系统地提高代码的可维护性，从而提高开发团队的长期生产力。

2. 实施准备

根据实施要求，本项目以SonarQube作为平台，对项目源代码持续检查，并集成至SDLC系统中。

2.1项目成员及职责

项目的具体实施工作人员职能见下表：

2.2项目组资源计划

整个项目大概需要XX人/天的工作量。具体见下表：

3. 实施

3.1 平台架构

3.1.1 络架构

整个系统为B/S架构，应用服务器与客户端之间 络必须保持通畅，客户端与应用服务器之间通讯的带宽占用约5Mbit/s。

3.1.2 系统架构

1. 开发人员在他们的IDE工具中使用SonarLint进行编码过程中的分析纠错，尽量将bug在编码阶段修复；

2. 开发人员上传他们的代码至SCM中，如：Git、SVN等；

4. 将分析 告发送至SonarQube服务端；

5. SonarQube服务端在数据库中存储以上分析 告，并且能在Web界面上显示分析结果；

6. 开发/管理人员通过SonarQube UI审查、评论、解决所产生的问题，管理和减少技术问题；

7. 管理人员从分析中获取 告，也可以使用API自动配置并从SonarQube中提取数据，运维人员可以使用JMX监控SonarQube服务器。

3.2 环境搭建

具体配置见下表：

3.3实施方案

3.3.1 代码规范审计

1. 针对各个团队现有的代码规范，按照规则类型或标准等条件，梳理出代码规范里的规则。例如Java，可以按照Weak Cryptography、Insecure Configuration、Authentication、Object Injection、Cross-Site Scripting…等进行分类梳理；

2. 依照SonarSource提供的代码规则，对应不同语言的代码规范进行对比，梳理出重要的或者级别较高的规则；

3．梳理出现有代码规范与Sonar规则的共有规则，其余部分另行讨论处理；

4. 针对代码规范与Sonar规则的共有的规则，设置对应规范下的质量阈；

5. 通过项目进行扫描反复验证，最终确定自定义的质量阈。

3.3.2 试点系统扫描

1. 使用SonarQube对每个试点项目进项扫描，分析试点系统，调整相关的质量阈，找出误 较高的规则，总结相关经验；

3. 综合分析SonarQube和Fortify的扫描结果，对试点项目进行综合评判，对试点项目进行相关规则、质量阈等进行整改。

3.3.3 代码质量阈设置

1. 通过sonar对研发组提供的试点项目（已稳定的项目代码）进行扫描，查看查看扫描结果是否满足需求（结果为 A， 级别C1高于50%，注释率大于20%），对扫描结果进行分析；

3. 重新扫描试点项目，查看扫描结果是否满足要求，分析扫描结果，如若试点项目扫描结果未满足要求，继续调整质量阈，与研发组一起商讨，直至最终的扫描结果满足需求；

4. 通过试点项目，总结归纳各个对应语言的代码规则，确定稳定的质量阈，作为其他项目的基准。

3.3.4 添加自定义规则

1. 根据需求对java语言添加以下规则，生成插件导入SonarQube系统中；

2. 扫描试点项目，查看自定义规则是否正确启用，同研发组一起确认自定义规则；

3．如新增自定义规则不满足研发组需求，重新调整和扫描检查，直至满足扫描需求；

4. 与研发组一起确认自定义规则，正式导入sonar系统中，试运行多个项目，分析扫描结果，最终确定适用的自定义规则。

1. 根据需求对python语言添加以下规则，生成插件导入SonarQube系统中；

2. 扫描试点项目，查看自定义规则是否正确启用，同研发组一起确认自定义规则；

3．如新增自定义规则不满足研发组需求，重新调整和扫描检查，直至满足扫描需求；

4. 与研发组一起确认自定义规则，正式导入sonar系统中，试运行多个项目，分析扫描结果，最终确定适用的自定义规则。

3.3.5 使用流程优化

Sonar能无缝集成传统的软件生命周期的整个过程（以下简称SDLC），部署使用（sonarlint+Gitlab+Jenkins+sonarqube）的SDLC方案。需要调研当前具体使用情况，得出更详细的调研结果，提出对应的优化意见，与研发组进行协商确认具体使用流程方案。

3.3.6 质量制度管控

3.3.6.1 总则

1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。

2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。

3、源代码直接控制管理部门为技术开发部。

4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。

5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。

3.3.6.2 源代码完整性保障

1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。

2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。

3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。

3.3.6.3 源代码的授权访问

1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。在SVN库中设置用户，并为不同用户分配不同的权限，适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。

2、曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由 络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。

3.3.6.4 代码版本管理

1、终端软件的版本标识管理：

a、终端软件版本由终端型 、版本 和内部修订 来进行标识。

e、另外，终端软件在发布时，还会给出发布日期，以便开发、测试、项目、客户等相关人员参考。

2、终端软件版本发布管理：终端软件主要是以版本 为基准，对外发布，目前采用不定时发布策略，发布的时间由软件部、项目部和客户方根据情况，共同商量决定。由于目前项目时间紧，终端软件无法得到完整的测试就要发布，在发布之后，有一些需要紧急需要修复的bug，软件部需要紧急修复后就要发布更新包，以便用户能够使用，所以，在一个版本 发布后，需要进行多次修订，对于这些修订的版本，其版本 保持不变，内部修订发生变化。

3、软件bug记录、管理和统计：软件bug的记录、管理和统计主要以版本 为基准，但为了软件开发人员能够找到bug的出处，需要用户、测试人员在 告和验证bug时，输入内部修订 。

3.3.6.5 软件配置组对版本的记录

软件版本记录的目标有两个：记录软件版本的发布历史。发布的每一个版本，都要能够唯一的从源代码库中找到对应的全部源代码。测试方案作为软件开发的重要环节，作为交付成功的优质的产品的重要保证手段和方法，软件测试越来越受到项目的重视。要做好测试首先要做好测试的组织、管理、计设、实施等工作。系统测试方案概述是指在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。测试的目标：以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。在实际项目中，测试作为软件开发生命周期中的一个重要过程，但从其具体工作的前后过程来看，它又是由一系列的不同测试所组成，这些测试的步骤分为：单元测试、集成测试（又称组装测试）、确认测试和系统测试。软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上，逐步集成的。在项目过程中，我们按以上的测试步骤完成系统的测试。

3.3.6.6 源代码复制和传播

1、源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。

2、源代码以任何介质形式进行存储的备份，必须由专人负责保管。对于这些介质地借阅，用于研发部内部使用的必须获得研发部经理的授权，对于用于研发部以外使用的必须获得总经理的书面授权。

3、源代码的借阅、复制必须进行详细的登记，必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。

4、任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。

5、对于因合作需要，需要向外复制、传播、分发源代码的，不论是全部还是部分代码和资料，均必需和对方签订技术、源码的保密协定，明确对方应当承担的对源码保密的责任和义务。

3.4安装部署

3.4.1部署流程

整个系统的部署按照以下流程进行：

4. 系统试运行

4.1 试点项目试运行

1. SonarQube系统部署完成后，对试点项目进行试运行；

2. 对试运行结果进行分析，给出试运行 告；

3. 修正试运行中发现的问题，与研发组确认后，将系统导入整个SDLC进行试运行；

4. 测试SDLC整个试运行情况，给出试运行 告；

5．修正试运行中出现的问题，最终确认，完成整个系统的试运行。

问题记录表：

5. 系统上线

5.1上线时间

根据用户测试反馈，该项目达到研发组使用目的，并无较大的歧义，系统运行稳定；确定试上线，试上线确定无异常，确认正式上线。

5.2上线 告

系统上线总结，编写上线 告；召开上线支持阶段完成确认大会。