我的项目发布总结

    本次项目有幸担当了一次发布员，这也是我今年想尝试的事情之一，因为对于项目过程来说，我设计、开发、测试、联调等等都做了，唯一就是项目发布还是没有践行过，至此，我也算是走通了整个项目流程了。我信奉一个理论：没有做过的事情千万不要说自己会做了。发布过程就不写了，已经写好了发布手册了。

 

1.准备阶段要充分，你轻视了哪个环节，哪个环节就有可能有问题，要知道发布阶段是大家都在等你，一定不要block在这里。

发布过程有两个问题值得一提：

（1）antx 配置虽然我配置好了以后 同步到本地用文本文件对照过，也一条一条的核实过，只核实有没有少配置什么，但是没有核实auto-conf里面的配置文件是否多了配置，特别是哪种确认阶段要求各个负责人去掉的配置，一定要检查下，这样配置文件就会跳出来让你配置，虽然不会导致什么错误，但是会耽误发布时间。

 

（2）用存过或PL/SQL初始化的脚本，一定要仔细检查，最好拿线上数据先做测试，这次出了一个这种问题：

在循环里有这样一条语句:

 open c_a for select add_months(t.INVOICE_DATE,1)  from ***.**** t
            where
              t.vaccount_id = o_obj.vaccount_id
              and (t.STATUS = '0' or t.STATUS = '1' or t.STATUS = '5')
            order by INVOICE_DATE asc;
    fetch c_a INTO V_OWE_TIME;

我们从业务上分析了都没有问题，但是在debug是发现，如果这个值为null时，他是赋值给INTO V_OWE_TIME，这样导致下次循环时直接就取了前一次循环的值，而如果使用 select into 则是可以赋值为null的。所以循环中一定要对变量初始化

还有一个问题：就是一个字段没有订正，导致消息通知出错。--发布前要整理初始化数据要和各个模块的人确认，凡是增加的修改的字段都要考虑初始化问题。

感悟：

建议能用脚本一步一步写的就用脚本，次之选择存过（存过容易debug），尽量不要用PL/SQL的批量处理，用大家都熟悉的东西，这样才容易review 出来问题，简单的技术是保证发布的要素，包括发布之前把所有的脚本写好，所有的环境放在一起，都是这个目的。

 

2.有时间检查发布机上的环境，就要检查下。（build机环境是公用的，不能保证所有配置都如你所愿）

这次发布还出现了一个mvn的path没有配置的问题。

解决：

>ll -a /home/admin 下隐藏文件 bash_profile

>修改maven path

>PATH=$PATH:$HOME/bin:/usr/alibaba/maven/bin

 

 

3. 发布要保持适当紧张和兴奋，要沉稳，不要被外界环境干扰

发布阶段，不要试图验证发布脚本的正确性，先连续的去发完，不要中断，中间不要和别人探讨技术和原理（否则你可能忘记了发到第几步了），然后再验证。

4. 要细致考虑网络情况，对于合作方只给出ip的要弄清楚原理，是否会定位到某台服务器上，然后telnet  他们提供的服务器。

 

5.记住发布和预发布的时间点，便于以后核对数据，考虑发布过程中的一些业务的停顿，提前想好补救措施，比如本次发布的发布过程中的销帐。

 

6. 不要忽略发布后的检查，对于特殊逻辑要特殊对待，发布前后看看数据，比如本次的0账单等

 

 

可以改进的地方：

（1）脚本同步所有环境的时候，重启机器并没有一台一台重启，第一台还没有起来，可能第二台已经关闭了，以后数据量非常大的情况下，是有风险的，可以sleep一下再关闭第二台。

（2）当出现关键性步骤没有通过时，应该block住并给出提示，否则发布人员如果不盯着日志很有可能放过一些关键问题，比如上面说到的第2条，mvn path没有配置，居然接着执行了，只在日志里有一条，command not found的提示。