当前组内负责迭代和维护的 App 项目共计有 19 个,内部组件大概 60 个.业务高速增长时迭代和维护的过程中,忽略了对项目依赖的管理.
在改进过程中我们需要准确的了解各个项目的依赖情况,逐步对某些指标进行持续跟进和验收:
- 方便查看具体 App 的所有依赖,依赖名,版本,源码地址等,及时汰换有风险的组件版本
- 方便查看各个 App 对关键组件的接入情况,推进组件话进程
- 方便查看内部组件的信息,依赖名,版本,集成方式,使用方,接入率.
同时需要配套实现一些满足开发者用以提升效率和减少失误的开发工具.
预期
协助管理者更精准的把控各个项目的依赖风险和组件化程度,帮助开发者了解组件被使用的信息,及时解决相关问题.
- 管理者可以迅速地查看某个项目信息
- 项目贡献者可以清晰地查看项目的依赖信息
- 组件维护者可以查看自己的组件被哪些项目接入,以及被接入的版本号码
- 可以了解到某一个关键组件的接入情况,协同开发人员提升其接入率
- 可以了解到所有项目的的全部依赖情况,逐步汰换存在风险的依赖项
- 后续分析和寻找更多的优化指标,或者进行类似的扩展
- 提高整个组件的开发和发布过程的效率
技术栈
客户端
Jenkins、Ruby、Gem、Cocoapods、Thor
服务端
Java 、SpringBoot、 JPA
Web 前端
Vue 2.x、Element-UI
功能
v1.0
实现组件信息和依赖分析结果信息 入库后展示
客户端定时任务
- 使用 gitlab api 拉取所有的 App 信息
- 使用 gitlab api 拉取所有的内部组件信息
- 客户端定时在 App 打包任务目录下遍历所有 App 源码目录,逐个执行分析任务并通过服务端接口上传依赖数据
- ruby cli 依赖 cocoapods ,分析某个 App 现有的依赖,得到依赖对象列表并入库
- 分析结果上报到微信群
服务端接口
- 提供 App 数据和内部组件数据的入库接口服务
- 提供前端对客户端各种数据的查询接口
- 提供客户端上船某个 App 依赖列表时的额外属性计算和数据数据入库接口服务
前端页面
- 展示所有维护中的 app 和各个 app 的基本信息
- 展示所有内部组件的基本信息
- 展示全部 app 所有依赖信息
实现方案
业务的主体结构
此方案的主要难点在于 ruby 客户端 yk_command 的功能实现和 Java 后台的接口服务的实现.
简述一下业务流程.
1.我们的 App 项目和组件项目的信息和源代码都托管在 gitlab 服务器上,这些信息需要拉取下来重新 map 之后入库到组件管理平台的数据库中,以供前端展示.
2.yk_command 程序是一个可以运行在开发者机器和打包机器上的 CLI,具备多种功能,其中的
yk_command platform_refresh负责将 gitlab 上的组件数据和 App 数据进行入库,每日下午六点定时执行yk_command workspace_analyze负责在打包机器上的整个打包任务下的所有 App 目录进行逐个分析,然后批量将依赖信息全部入库,并发送结果通知到微信群3.由于 iOS 设计的业务流程和对象字段安卓并不相同,所以没有共用后端服务和数据库.后端的核心接口是依赖添加,
DependencyService().addDependency,此接口用于将 App 的依赖数据和 gitlab 中的项目数据进行关联入库.4.Java 服务使用的
Spring boot和JPA的组合,省去了写原声 Sql 语句和一些实体类配置的操作,但是实体对象之间的关系注解比较庞杂,只选取了一些简单的进行使用.5.前端项目和安卓以及 web 前端一起合并在一个项目中,iOS 相关的数据来源于我们单独的 api
业务对象和关系
这里的表结构经过迭代和重新设计.第一个版本使用 JPA 自动多对多进行映射,但是由于对 JPA 的熟悉程度不够,在更新 App 和依赖信息的时候采取了一个折中的方案,先删除所有数据,再次添加入库.这样的设计为后续 1.2 版本查询组件的历史版本信息埋了个坑,在 1.2 版本时做了一点大的重构,下图为重构后的表结构.
project实体属性来自于 gitlab 上的项目数据筛选过后的字段,以 gitlab_id 做为主键project实体会持有一个数组,用于存储其所依赖的依赖对象的id,在DependencyService().addDependency调用之后进行更行
dependency实体属性来自于yk_command依赖cocoapods-core得到的依赖数据筛选过后的字段,主键随机生成.dependency实体会持有一个数组,用于存储其使用者的gitlab_id,在DependencyService().addDependency调用之后进行更行
结果上报,每天下午的 6 点,打包机上的 Jenkins 会执行定时任务,在打包跟目录下,调用 yk_command dependency_analyze 变了所有项目批量分析,批量入库所有 App 得依赖信息.将任务执行结果发送到微信群.
展示所有 App
这个页面展示技术中心参与维护的全部应用,分别展示项目的名称,描述,贡献者,活跃时间. 在组件化的持续推进中,我们最优先关注的是组件数量和内部组件的依赖数量.
展示某个 App 所有的依赖.
在 App 列表的选择任意一项 App,点击操作区域的查看依赖详情,就能查看此 App 所使用的所有依赖信息. 我们主要关注某个依赖的版本和其集成方式,在验收某个组件的接入情况时,也能快速跳转到 gitlab 代码仓库查看组件的源码和配置文件内容.
公司内部组件列表.
目前公司的自研组件已经达到 60+(图中数据 57 为旧版本),在这里可以做一个统一展示.作为管理者目前最关注的是组件分类数据,各个类别下的组件数量,以及其接入率. 作为组件的开发者,我们最关注的是组件被多少个项目所依赖,以及被哪些项目所依赖
全部项目使用到的的所有三方库,含内部组件.
这个列表展示了所有的 App 的全部依赖信息,通过对组件名字的筛选排序,我们能够看到同一个组件的不同版本分布,能够尽快提示使用方注意更新,对于外部的组件,我们可以跳转到其仓库查看是否有潜在的 bug 和活跃程度,有风险的情况为下我们会尽快推进汰换.
后续迭代
v1.1
- 新增正在迁移中的三房库列表
- 组件列表新增组件分类属性
- 后端程序的内存增加分类的枚举直,入库的时候依据组件名设定设定分类
- 全部依赖列表新增此依赖是否已迁移到内部的标识
- 各个 App 数据增加贡献者信息
- gitlab api commits 最近 50 条中筛选出提交者
- 重新实现组件的使用者列表
- 使用组件名和版本号作为唯一标识,关联到 App 数据
- 使用者的接入方式,新增 git commit 标识
- 重构功能代码,模块各个业务功能
- 将从 gitlab api 拉去在库组件和在库 app 并入库的过程实现为自动处理
- 各个 App 显示最近多个版本的贡献者 commit 占比
v1.2
- 确定 5 个基础的热门组件,在前端进行提示,让业务组提高对这些组件的关注度
- 实现组件的发布功能,将组件的发布座位流程工具
- 实现内部组件的过期版本上报功能
- 前端实现 App 列表提示该 App 有依赖一个或多个过期组件的提示,配套的还有依赖
组件发布和上报流程图
组件发布和版本上报是一个比较大的重要功能,以下是完成实现流程.这里的难点是实现一个比较容易接受的交互流程,也方便开发者使用.比较耗时的是交互测试和边界情况的判断处理.
客户端组件发布和上报运行实例
预期评价
目前顺利实现了管理者期望对项目情况有更深入和量化地了解的预期.也开发出了顺手的发布工具,目前在测试阶段. 后续会及时跟进同事们的反馈及时调整功能的迭代方向,将这个平台进行更细致的打磨.