gitlab仓库release版本生成与管理

〇、背景

RVIcamera 即将进入正式服, 现有版本号管理依赖于gitlab papline id, 目前每次构建都会造成版本号步进, 膨胀速度过快, 且生成的升级包太多, S3 存储成本过高. 为了方便正式服版本管理, 需要一套新的版本号管理方法. 另外要确定, 哪些包是需要长时间存储(S3)的, 哪些是暂存的.

一、发布机制

利用gitlab提供的release接口进行发布, 其实在最早创建CI的时候有测试过相关功能, 后来并没有实际启用.

启用release分支, 所有在develope或master生成的包, 都算作开发者包, 只有在release分支打tag并publish的才是正式包.

后续提测和发布可能需要两套版本号策略. 详见1.2

1.1 工作流程

1. 提交代码
2. 触发CI构建
3. 使用pipline id 生成一个内部版本号
4. 用内部版本号打包并制品
5. 内部包作为alpha版提测
6. 测试组打回或通过测试
7. 通过测试则将develop分支合并进release分支, 并打tag.
8. release制品上传S3

以上所有流程均自动完成

1.2 版本号管理

版本号分为内部版本号和发布版本号, 内部版本号即为pipline id, 每次合并都会造成版本号步进; 发布版本号为用户最终在设备信息列表中可见的版本号.

ex:
release version: 6.15.1.20
inside version: 1874

设备app.ver中需要记录inside version, 固件实际使用时需要考虑设备升级时对于版本号的判断.

注: 内部版本号机制是一个还在构思的方案, 主要目的是便于追踪版本和CI工作流的关系, 降低版本号膨胀速度. 并非必须使用. 如果我们能接收release版本号有跳跃, 那么可以直接在release版本号基础上步进

release版本号将从这个管理措施启用的一刻起, 步进第三位版本号,x.x.2.0, 并打tag v6.15.2.0; 后续CI出包会先读取服务器上现有的tag,然后+1作为版本号来步进.

1.3 升级包管理

以下列出CI pipeline触发的几种情况和处理方式

触发	处理
日常开发分支推送	不会触发任何CI
网页端手动触发	执行编译并生成包, 不上传S3
提交merage request	执行编译检查, 不生成包
master分支产生更新	执行编译并生成包, 不上传S3,不打tag
release分支产生更新	执行编译并生成包, 上传S3, 打tag

开发分支产生的升级包, 以制品的形式在Gitlab仓库服务器中保存30天, 这个时间已足够提测\开发者自测的要求. release分支产生的包是将会发布给用户的包, 将会永久保存在S3服务器上. 所以后续要保证所有的推线上的包, 都是在S3上下载的.

注: 这里存在一个问题, 在master分支或develope分支进行提交后产生的包, 通过之后, 代码合并回release分支, 将会产生一个新的包. 那么这个包是否还需要测试? 需要和测试组沟通.

二、仓库及服务器管理

2.1 代码仓库相关

此管理方案启用后, 为避免旧的CI脚本继续推送包到S3, 现有开发分支全部CI脚本将全部认为失效(通过仓库设置来控制). 开发者需要重新rebase release分支.

develop\master\release分支需要设置保护, 禁止直接推送. 必须经过mr才允许合并.

关于多个产品公用同一个仓库的问题, 我个人倾向于不要这么做. 否则影响release时打包, 因为无法指定是为哪些产品做release. 最好fork出一个新仓库.

如果一定要用同一个仓库, 请在分支后加后缀, 如release_sigmastar\release_rvi等类似形式, 便于CI脚本判断.

2.2服务器相关

Gitlab仓库服务器需要注意存储空间, 目前RVI项目生成包较多. 可能造成存储压力过大.

S3服务器建议立即删除现有存储的所有RVI未release的升级包. 因为大部分包都是在gitlab服务器上有30天备份, 同时又没有发布给用户的, 没有长时间保留的必要.

Docker服务器请关注是否存在镜像未释放造成空间占用的问题, 如果正常则忽略.