欢迎光临
梦想从学习开始!

那些年背过的锅~版本发布管控

测试辛辛苦苦将一个版本测试完成后,版本如何发布,由谁发布,发布到线上需要走什么样的流程,每家公司可能都不一样,有的公司甚至都没有版本发布流程,随便开发,产品,测试就把版本丢出去了。这种操作,没有出严重问题的时候万事大吉,出问题后就扯不清了。

(图片来源于网络)

我们先来梳理一下有哪些类型的发布
一 APP 这个要分IOS和android
android,如果不需要上各个应用商店的渠道包,比如华为应用商店,谷歌应用商店,那通常由开发打一个线上的APP包,测试验证后,项目经理把APP包上传到版本服务器,生成下载的二维码。如果要上渠道包,开发将包发送到各个渠道,审核通过后在各个渠道能搜索到。那这种只要开发把APP打包好,发布版本的操作其实开发,测试,产品等都可以操作。
IOS,发布到苹果应用商店的包必须要经过苹果的审核,开发需要构建版本,上传到苹果的应用商店,审核通过后上架。这种发布操作通常是由开发完成的,很少由测试做这样的发布操作。
二 客户端/服务器 (C/S)
一个client通常开发合并好代码打完包好上传到下载服务器就能发布,这个发布操作也是开发,测试,产品都可以将客户端的包给出去,这种很多情况下都是测试验证完线上包后给到客户,或者上传到服务器,把地址给出去供客户下载。
服务器的版本一般都会打一个系统包,在本地升级,这种发布操作和客户端一样,开发、测试、产品都可以将服务器的系统包给出去,这种很多情况下也都是测试验证完成后,和客户端包一起上传到服务器,把地址给出去供客户下载。
三、浏览器/服务器 (B/S)
这种模式,前端开发将代码发布到服务器,服务器端也是后台开发直接将代码发布就可以,这种都是由开发完成发布,产品、测试无法进行发布
四、android系统
做手机、电视等android系统的项目,打完系统包,要么放到OTA服务器上,发布推送使用户进行升级,要么直接把系统包给到特定的用户进行本地升级,这种情况只要开发把系统包打完,测试、产品都可以把包推到OTA服务器或者给到特定的客户
所以综上,只有第三种情况测试才能完全避免版本发布问题的锅,其它几种情况都可能要牵扯到测试。
熊太所在公司版本发布流程非常的健全,一个版本发布流程发起到结束直接在简道云上走流程,相关的人都需要进行审批,所有人审批完成后才能发布。所以不会存在版本把控不严的锅甩到测试身上。来两张图展示一下发布流程。


如果公司没有完善的,责任分明的发布流程,那大家都会很被动。小熊就遇到这样的事情,在没有版本发布流程的情况下测试不通过的版本,但是由于前线紧急,被迫把测试不通过但是勉强能用的版本发出去,这个发布的操作由开发经理让小熊去做了,内部其实相关人员都是认可这种做法的,包括项目经理,开发经理等人。但是日积月累,这样的版本出去的多了就会有很问题过来,最后小熊被总监一顿痛批,测试没有把版本把关好,这个时候任凭有多少测试不通过的邮件都没有用,结果还是有问题的版本都出去,这时候当时默认把这些版本发出去的人都不会发声了,小熊成了真真切切的背锅侠。痛定思痛的小熊把自己关了半天,整理了一份比较详细的版本发布流程,内容包含版本发布的要求,发布前必须要开发布会议,如果没有测试通过的版本还是要发,必须要得到项目经理、开发经理等相关负责人的签字或者邮件回复等,最后这份发布流程总监审批通过,开始执行,以后小熊再也没有背过版本把控不严的锅了。所以公司的流程不完善的情况下我们要学会利用现有的条件自救。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » 那些年背过的锅~版本发布管控

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏