项目管理中软件版本发布流程

声明

以下内容是我在目前任职的公司对于现有目前公司软件版本发布的流程的一些理解和总结,可能不具有普适性,欢迎一起讨论。

1. 平台通用问题检查

重点在于全平台类通用问题检查。版本送测前,SPM需要预先对即将发布的版本进行平台问题检查,可以以上个版本发布后新增的问题为重点。一般来说,版本如果具有连续性,则上个版本平台问题理论上是已经全部解决。检查以后给各个接口人建立检查任务对每个平台问题进行审核,等所有问题处理结束后,方可认为没有平台类问题。
由于我司内有质量平台,大概检查如下:
1) 所以质量平台问题都已检查(可以继承项目);
2) 问题结果为NA且没有备注说明,不能发版;
3) 问题结果有FAILED,不能发版。

2. 代码修改点检查

软件版本发布对应着问题修复或新功能交付,此时需要注意检查当前分支修改点是否提交:
1) Gerrit检查是否有commit记录;
2) 查看commit记录内的描述与修复问题是否一致,如果不一致和开发二次确认;
3) 所有问题修复或新功能都有对应修改点commit记录,方可认为版本已就绪。

3. 送测前检查

重点在于检查即将送测的版本是否符合软件发布流程,通过检查送测过程中的每个环节,方便知晓目前进度,以我司内部的送测平台为例:
1) SPM需要先检查下CPM填写的版本信息是否正确;
2) 填写详细的测试建议、编译命令、分支路径、编译宏、项目名、分区表、修改点信息等;
3) 在版本测试完成后,评估版本测试结果,决定版本是否能归档发布。

4. 版本发布

对外的版本发布一律通过CPM来释放,严禁SPM私自释放,未经过CPM确认的版本可能会存在问题,存在不可知的风险。

5. 版本发布流程图

标签:版本发布

原创不易,请勿在未经作者同意的情况下,转载到其他平台或者博客

评论区

1 评论
    一颗小苹果Chrome 105OSX
    10月1日回复

    ୧(๑•̀⌄•́๑)૭