改动多
这次改动比较多,前前后后的功能时间算起来得有半个多月,有的功能早写好了一直放着,后面的功能都用上了它还在那放着。
这次更新要把以前的东西一通都给上了,加上3.0版本。
加上这个星期的改动非常大:前台页面的大改版,抽奖功能的加入。
所以这次新版本的上线会非常复杂。
具体的改动有:
表结构的修改,
表数据的修改
后台接口的增加,
前台代码的修改
部署的顺序
这次更新想要达到的效果就是:
更新的过程中不管怎么样,用户看到的要么是旧的版本,要么就是新的。不要出现服务器正在维护中什么的问题。
后台是我写的,比较清楚,接口只有添加,没有删除,所以后台代码在前台之前布是没有问题的。
但是对于一些sql语句有了修改,会去查询一些原先没有的表的字段。
所以表结构的修改必须要在后台代码之前完成。
那么发布的顺序大概就是这样了:
1.表结构调整(包括新建表等)
2.后台代码部署
3.前台代码部署
那么数据库中数据的修改应该插在123哪个位置比较好呢?
这次更新,前台按照分类显示,而分类的字段在之前版本又是没有的,所以如果放在3后是不行的,也不可能在1前,所以只能在1-2,2-3之间。
仔细想想,其实在这2个位置都是一样的啦,
stage上的数据库问题
今天在部署stage环境的时候出现了问题:
由于给的文案空格太多,导致表字段不够,可怜的dba删了半天的空格。
最终发现有一件商品的说明还是太长,为什么太长呢,因为里面要显示一个漂亮的按钮,我又找前段要了一串复杂的style,所以就不够了。
没办法,只能扩字段了。
今天执行stage数据库的时候还出现了另外一个问题:
邮件发出去了,dba执行完了,过来问我,是执行stage吗,我是说的。
怪我把stage上执行一句话放到了最后,看到这句话的时候,dba已经在生产环境上执行完了。
所以当时真的是吓坏他了。。。
还好,执行的那个脚本是修改表结构的,多了几个字段,多了几张表,并没有什么影响。。
我也比较自信,stage测试的时候这个不会再做改动。。
stage上的后台代码问题
除了数据库,stage的后台代码部署也废了好大的劲,虽然不是我部署的,但是看着别人弄这么久也是蛮累的。
最终上了stage,兑换的时候抱了服务器异常,把我给惊呆了。
他们都去吃饭了,剩下我来查错。
首先,我不知道stage环境的ip,(密码倒是知道)
没办法,开起了抓包工具,结果抓到的是nginx的代理地址。
想通过找配置文件找出地址来的,最终还是失败了,还是问来了这个地址。。
然后看了api的日志,打印的是空指针,看了对应行数的代码,觉得应该是数据库里的数据少了。
但是不能啊,如果数据少了,也会显示兑换完了,况且这里做了缓存处理,还能避免并发问题的。
然后再去看service日志,找到问题所在了:数据库是有数据,不过缓存服务器在打包的时候配置错了,所以无法从缓存上拿到券。
所以就空指针了。
明天接着搞
ok,一切搞定。
明天上生产。
带我的人回家了。
明天邮件啥的一切我来搞,好紧张。。。