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导出结果到其他需要的服务
