版本上线血泪史

今天都13号了,2.4号是农历除夕之夜,很是快呀,一个年又过得差不多了,对于几乎严格遵守法定假日的很多朋友来说,今天都已经上班好几天了。昨天还收到公司的开年红包,预示今年要开工大吉了呀。

年前磕磕碰碰终于赶上iOS的版本审核通过,奈何已经到了农历年底,上版本的事情也就被拖延了,所以年后开工的第一件事,就是把之前遗留的版本发布提上日程来。于是乎,做了个上线的计划,开工第二天就准备上线迟到了一周多的版本,我是服务端,需要把控的事情自然也就变得多了,毕竟服务端稳定了,客户端才有运行的保障,这也是我转行Java服务端之后,感受最多的想法。因为本身能力的问题,我已经领教了不止一次服务端的厉害。

服务端的思考是我每次上线的必备之路,检查配置文件,代码分支,环境模拟运行,这可能也和之前所待的公司有关系吧,我还是喜欢每次都从头到尾检查下,虽然有时候还是会出差错,但是也是减少差错的路径之一。因为现在一起开发的小伙伴人少,代码检视成了自己的独角戏,略微放松警惕,也是我受到教训的路径之一。

不过今天要聊的,除了服务端的思考之外,还有上线的流程。在前公司,因为自动化CI发布做的挺好的,还得到过公司领导的夸奖,而我也切实感受到自动化的厉害之处。比如说,我今天提交的代码,第二天就能马上看到代码质量的好坏,流程是否能跑通,也正是因为这个,好几次代码写完出差错都能及时更正,防止错误拖延。现在不一样了,每天接触的都是手工测试为主的流程,很多时候一个疑问不知不觉就过了几天,追溯的事情也就变得困难起来。昨天开年第一天,就因为年前提交的一个更新DB的操作出了问题,硬是排查了一上午,时间就这么过去了,很是可惜。

今天发布版本,跨年的版本,而且因为在配置上有了不少的改动,需要修改线上相关的配置,就这个动作,让版本比平时更新的时间延长了差不多一小时,引起了我的深刻回溯。首先,发布版本的动作,不应该只存在口头上的描述,还是需要通过必要的文档梳理成一个详细的流程,尤其是版本大改动,需要同步修改配置文件的时候这一步尤其重要;其次,版本更新没更上开发版本的进度,要及时做好相应的分支备份,不仅仅是代码备份,还有发布命令的备份(今天还有一个流程就是因为启动jar包命令的改变);第三,提交代码要做好代码提交记录,版本发布之前做好相应的功能梳理,防止缺漏必要的功能;第四,需要培养其他能更新版本能力的小伙伴,技术不能闭源,尤其是在小团队里,掌握核心的不能是一个人。

做这个小总结,也是为了新的一年能顺顺利利编写我的代码,提升我除了写代码之外的能力以及思考做准备。今天虽然版本上线延迟了,但没有遇到太多的困难和阻碍,也是令人欣慰的一件事。而且,年前和运维的小伙伴一起推动了自动化构建,在测试环境上发布版本已经很是顺利,基本解放了我一大部分操作,还是可喜可贺。今年的第一个小目标,就是能在测试环境充分使用完之后,顺利在线上环境中使用自动化构建,等到那一天,就是开发和运维的胜利之处。

开年第二天,已经感受到了无形的压力,还好几处诉说的地方,缓解下紧张的情绪。期待今年我的成长,期待朋友们和我一起进步。

原文地址:https://www.cnblogs.com/dimple91/p/10440345.html