gitlab

jenkins

代码分析

提交代码

下一步工作：   1、徐涛搭建相应的环境，同时测试svn迁移至gitlab。   2、徐涛制作PPT讲解gitlab使用流程及基本使用办法。   3、徐涛组针对gitlab进行试用，同时优化使用流程。   4、 测试组介入，融入到产品开车、测试、发布流程。   5、根据反馈效果推进到整体开发组。

release稳定版本

潜在bug

bugfixbug分支

注释率

sonarLint

feature功能分支

master主分支

sonarQube Server

history-master地市版本分支

结构和设计

可以解决的主要问题：   1、地方版本过多，公共问题的修改需要修改多遍，不便于进行维护。   2、svn中提交记录过多，部分功能多次提交，不便于进行问题的追踪。   3、稳定分支及主干分支可保持稳定状态，有利于系统版本的确定及Tag。   4、测试提前介入，功能没有问题后，进行合并提交。   5、代码需经过审核后才能合并到主干版本，保证了代码的质量。   6、gitlab本地有完整的版本信息，离线状态下也可进行提交，便于离线开发功能。（笔记本较为方便）

代码规范检查

持续集成

develop开发分支

SVN、GIT

重复代码

地市版本分支与主分支相似，也需创建开发分支、功能分支、稳定版本、bug分支。注意：   1、系统的功能开发需要细分，属于公用功能的需要在主干分支开发，合并到主干分支中。   2、地市版本的差异功能，在地市分支中建立功能分支开发，合并到地市分支中。   3、地市分支需要从主干分支中拉取主干中修改的内容

代码复杂度

sonar

单元测试

需要解决的主要问题：   1、任务需要细分，进来避免同一功能多人协作开发。   2、代码需专人审核并合并到主干版本中。   3、开发人员需要熟练使用分支功能，避免出现分支混乱。   4、需要完善的版本定义规则。

评审代码

主要过程如下：1、开发者在IDE中编码，并使用SonarLint执行本地代码分析；2、开发者向软件配置管理平台（Git，SVN，TFVC等）提交代码；3、代码提交触发持续集成平台自动构建、使用SonarQube Scanner执行分析；4、分析报告被发送到SonarQube Server进行处理；5、处理好的报告生成对应可视化的视图，并将数据保持到数据库；6、开发者可以在页面通过查看，评论，解决问题来管理和减少技术债；7、SonarQube导出结果到其他需要的服务