云智慧 AIOps 社区是由云智慧发起,针对运维业务场景,提供算法、算力、数据集整体的服务体系及智能运维业务场景的解决方案交流社区。该社区致力于传播 AIOps 技术,旨在与各行业客户、用户、研究者和开发者们共同解决智能运维行业技术难题,推动 AIOps 技术在企业中落地,建设健康共赢的AIOps 开发者生态。
本文以云智慧数字化运维数据平台DODB产品为例,由云智慧研发团队通过分析对比产品历史版本与新版本中的Java代码行数、Java文件个数、代码注释占比、发布包大小、组件依赖等关键数据,找寻出历史版本开发过程中存在的代码、项目管理及开发人员等方面问题,最终梳理总结出改造代码、制定规范等可提升研发效能的有效方法。
通过下方图表数据可以看出,在新版本中,代码注释占比降低了近150%,项目分支数减少了近100%,其他各项数据也均有了明显的变化。
指标 | 过去 | 现在 | 对比结果 |
---|---|---|---|
项目module数量 | 12 | 8 | 减少33% |
代码总行数 | 174252 | 136484 | 减少22% |
Java代码行数 | 90310 | 50719 | 减少44% |
Java文件个数 | 982 | 583 | 减少41% |
代码注释占比 | 3% | 7% | 提升133% |
sonar-bugs数量 | 92 | 0 | 减少100% |
对外http接口数量 | 160 | 100 | 减少37.5% |
对外dubbo接口数量 | 100 | 25 | 减少75% |
发布包大小 | 226M | 170M | 减少25% |
项目分支数 | 300(参考) | 20 | 减少93% |
写入性能(单条10K) | 88W/min | 187W/min | 提升113% |
组件依赖 | ignite、vertx | 删除ignite、vertx | 5.3.1以redis替换ignite,彻底删除vertx |
微服务 | 1 | 3 | 5.3.1支持服务以存储模块或者非存储模块独立运行 |
通过上述各项数据的对比分析,本章节对历史版本开发中存在的代码、项目管理、开发人员等各方面问题进行了回顾分析,详细可查看下文:
为解决产品历史版本开发过程中存在的代码、项目管理等各方面问题,云智慧研发团队制定了开发、接口等相关规范;同时,通过限制代码仓库权限等其他操作也保证了规范的严格执行。
无规矩不成方圆,切实可行的规范是保障团队战斗力的前提。规范制定应本着提高团队水平,又不限制成员积极性为目标。
工欲善其事必先利其器,规范里提供了相应的工具,用好可达到事半功倍的目的;同时有相关提交流程保障规范落地,不能让规范流于形式。
禁止任何人向保护分支提交代码,必须走merge流程
merge列表界面
merge详情界面
禁止删除tag
标签tag列表
标签tag详情
<!-- mybatis-plus操作数据库 -->
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus</artifactId>
<version>${mybatis-plus.version}</version>
</dependency>
模块名称 | 功能 | 包名前缀 |
---|---|---|
bdp-api | Restful API和业务逻辑实现、只能被bdp-standalone依赖 | com.cloudwise.bdp.api |
bdp-base | 业务对象和接口定义 | com.cloudwise.bdp.base |
bdp-commons | 通用工具common util | com.cloudwise.bdp.commons |
bdp-pipeline | pipeline数据处理实现 | com.cloudwise.bdp.pipeline |
bdp-rpc-core | rpc接口声明及rpc实体类定义,不能依赖其它模块,对外rpc接口请慎重修改 | com.cloudwise.bdp |
bdp-standalone | 主项目,DODB主入口类为DodbServiceApplication | com.cloudwise.bdp.standalone |
bdp-store-ck | ClickHouse存取实现 | com.cloudwise.bdp.store.ck |
bdp-store-common | 数据层存储接口声明 | com.cloudwise.bdp.store.common |
/**
* github-api
* https://github.com/help/api/api_resources.md
*/
private static final String GITLAB_URL = "https://github.com/api/v4/projects/2393/repository";
private static final String PRIVATE_PARAM = "*****************";
/**
* 清理分支,已合并分支直接删除,其余删除前以tag形式备份
*/
@Test
public void cleanBranches() {
Map<String, Object> paramMap = Maps.newHashMap();
paramMap.put("private_token", PRIVATE_PARAM);
paramMap.put("per_page", 10086);
String body = HttpUtil.get(GITLAB_URL + "/branches", paramMap);
List<Branche> branches = JSON.parseArray(body, Branche.class);
// 按最后一次提交时间由小到大排列
branches.sort(Comparator.comparingLong(o -> o.getCommit().getCommitted_date().getTime()));
log.error("分支数量:{}", branches.size());
branches.forEach(item -> log.info("{}", item));
// 清理长期不活跃分支
.....
}
首先了解发布包是如何构建的,参看assembly.xml配置
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<includes>
<include>com/cloudwise/bdp/**</include>
</includes>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>${start-class}</mainClass>
<classpathPrefix>../lib/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
重点关注过大的包是否是项目必须的
是否有重复依赖问题
*例如netty-all是众多netty-的合集,不要去重复依赖,如果版本不一致还会引发问题;
batik-all是batik-*的合集,排除各个子包
排查后通过相关插件追查依赖源,精确排除
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>${maven.dependency.version}</version>
</plugin>
1、开发人员应清楚依赖包是做什么的,不要不管三七二十一依赖一堆没用的包,无谓增加发布包大小,还会带来隐患;
2、代码审核时,依赖文件(maven工程的pom.xml文件)的修改需要重点关注,禁止随意引入和修改依赖;
3、各产品线可在统一各依赖版本的基础上,调整构建方式,大幅减小集成包的大小。
云智慧以开源集轻量级、聚合型、智能运维为一体的综合运维管理平台 OMP(Operation Management Platform) ,具备纳管、部署、监控、巡检、自愈、备份、恢复等功能,可为用户提供便捷的运维能力和业务管理,在提高运维人员工作效率的同时,进而提升业务的连续性和安全性。
点击下方地址链接,欢迎大家给 OMP 点赞送 Star,了解更多相关内容~
GitHub 地址:https://github.com/CloudWise-OpenSource/OMP
Gitee 地址:https://gitee.com/CloudWise/OMP
微信扫描识别下方二维码,备注【OMP】加入AIOps社区运维管理平台 OMP 开发者交流群,与 OMP 项目 PMC 面对面交流~
|