#【中秋征文】程序人生，中秋共享#
经验分享
自从当了码农，已经不知道有多少个日日夜夜熬夜到凌晨三四点了。
不知道大家有没有想过，生产上线发布新版本到凌晨三、四点都有可能是哪些原因呢？
下面我将分享下自己以前跟进生产版本发布的经验，经验丰富的老前辈们肯定都比我清楚（可忽略此篇文章~哈哈~）。
这篇文章可能更适合萌新程序员体质。争取不熬夜工作（只能熬夜玩乐，不能熬夜工作~）
目录
一、网络权限申请
需求有时涉及与别的系统有交互，别的系统可能是内部的，也有可能是第三方合作公司的。
那么权限最好在发版前一天甚至是前一周就申请好。
因为权限很有可能不是一下就能搞定的，非等到上线当晚解决，很有可能就推迟了下班时间。
我现在的一个需求，就是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哈哈~
完全不知道发版后，客户要测多久呢 ~
测试过程中是否会有问题，建议准备好熬夜小零食吧 ~^_^
祝大家的发版夜都顺顺利利，不会太晚哦~