生产发版前准备【经验分享给萌新程序员】

#【中秋征文】程序人生，中秋共享#

经验分享

        自从当了码农，已经不知道有多少个日日夜夜熬夜到凌晨三四点了。

        不知道大家有没有想过，生产上线发布新版本到凌晨三、四点都有可能是哪些原因呢？

        下面我将分享下自己以前跟进生产版本发布的经验，经验丰富的老前辈们肯定都比我清楚（可忽略此篇文章~哈哈~）。

        这篇文章可能更适合萌新程序员体质。争取不熬夜工作（只能熬夜玩乐，不能熬夜工作~）

        

目录

经验分享

一、网络权限申请

涉及网络权限的场景

网络权限申请表

二、生产脚本准备

     （1）检查脚本

     （2）备份数据脚本

     （3）脚本命名顺序 

三、配置文件检查

四、代码检查

五、发版评审会议

六、发版漫长夜准备      

---

一、网络权限申请

        需求有时涉及与别的系统有交互，别的系统可能是内部的，也有可能是第三方合作公司的。

        那么权限最好在发版前一天甚至是前一周就申请好。

        因为权限很有可能不是一下就能搞定的，非等到上线当晚解决，很有可能就推迟了下班时间。

        我现在的一个需求，就是8月份上线的会调用第三方的API，到现在网络权限问题都没搞定！  （ps:现在的这个需求网络权限不归我负责，这里也不是我申请。但是上家公司是由开发自己写excel提交申请给运维的） 

涉及网络权限的场景

（1）前端项目调用后端项目（maybe）；

（2）后端项目调用其他团队项目或第三方合作公司API（maybe）

（3）后端项目需求新增了调用新的数据源（maybe）

网络权限申请表

      示例如下：

需求	源IP	目标IP	目标端口

二、生产脚本准备

     （1）检查脚本

         根据需求的大小，整个开发过程中，可能会设计一些数据库表的增删改。

         因此发版前，一定要检查自己准备的生产脚本，看有无遗漏。

     （2）备份数据脚本

        有些脚本特殊，涉及到修改和删除的表数据，一定要先做好备份，避免出现一些不可挽回的错误。

     （3）脚本命名顺序 

        涉及新建表的、加字段的、或者修改字段类型或长度这些，肯定是先执行DDL脚本。

        其次是DML脚本，DML脚本根据逻辑有的可能不在乎顺序，有的在乎顺序，有的可能要等项目发布了再执行。

        脚本命名示例：

                1_20230101_xx项目_DDL.sql;

                2_20230101_xx项目_DML.sql;

                3_20230101_xx项目_DML_通知后执行.sql;

       脚本里面也可以加一些注释，有的生产脚本是由运维执行的，脚本示例如下：       

-- 第一个执行的脚本 

create table t_test  (
   id varchar2(10) not null primary key,
   name varchar2(200) not null,
   age varchar2(2),
   status char(1) not null
);

--这是第二个执行的脚本，需要第一个DDL脚本执行完毕才能执行此脚本
INSERT INTO t_test(id,name,status) VALUES ('2023010101','张三','1');

三、配置文件检查

        测试环境与生产环境的许多配置项都可能是不一样的，尤其是涉及到URL这些配置。

        很有可能一不注意，就把调测试环境的某个url配置到了生产文件里面。

        因此发版前一定要检查生产配置文件的配置项是否有遗漏，有错误。 

        如果是yml文件，application-prod.yml文件更要比properties文件更严谨。     

四、代码检查

     发布前要检查下sonar扫描项目是否有代码的问题，这个最好是在开发完成后就检查。可以规避一些有风险的代码。

     可能会造成异常问题的代码，sonar也会识别出一些。

     例如下面一句随便写的的代码，可能因为开发有时不严谨而写出来：

User user = service.getUser();
user.setAge(11);

   sonar就会扫描到，并提示可能会有空指针：

Possible null pointer dereference xxxxx 

    如下图按严重程度处理，造成阻断和严重的问题都应该提前解决。

五、发版评审会议

       这个会议其实不是必要的，但是如果是很大的需求，涉及到多个同事或者团队的合作，那么最好提前约一个生产发版评审会议。

      多系统，多人协作，就要明确哪个项目发布在前，哪个项目发布在后。

      发布的时间也要确认，最好不要影响客户或系统用户的操作，避免引发流程bug。

六、发版漫长夜准备      

        O(∩_∩)O哈哈~

        完全不知道发版后，客户要测多久呢 ~

        测试过程中是否会有问题，建议准备好熬夜小零食吧 ~^_^

         

        

         祝大家的发版夜都顺顺利利，不会太晚哦~