您的位置:首页 > 其它

20131128工作安排及总结

2013-11-28 08:58 113 查看
版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。 本文链接:https://blog.csdn.net/macs2007/article/details/84507608

今天又是上线日,而且由于本次某些功能跨迭代开发,但却没有选择拉分支的方式,所以上得时候需要特别谨慎,一定要测试好,同时要考虑好,自己对配置文件和数据库都做过哪些改动。

每次上线,最担心的就是这个问题,由于这个系统的特殊性,线上和线下的配置文件不一致,导致了每次上线都需要认真检查,将在线下的修改替换到线上,而且还要保证每次修改没有任何问题,这对于比较粗心的我来说,无疑是一大挑战。同时,还需要考虑到对现有数据库的修改,有修改的话需要准备相应的数据库上线操作,而时间一长就容易忘记,比如今天早上我突然记起来我对数据库某个表有过加字段,而这个还没提交到准备文件中去,吓出一身冷汗。

在快速迭代过程中,如何保障对数据库的修改和对配置文件的修改都不被遗忘掉呢?我想可以这样做:

1. 每次新的迭代开始前,建立一个文档,以该迭代命名,专门记录数据库的修改记录和配置文件的修改记录。每次修改后,录入到该文件中作为一个备份,所谓好记性不如烂笔头。

2. 每次上线前,先看一下那个文件里的修改记录,看看哪些是需要在本迭代上线的,合同到线上文件,或者是提操作单。

3. 当然,如果修改了配置文件或数据库却没有录入进去,同样存在漏报的风险,那就没有办法了,就好比说马路上已经提醒你了过马路要绿灯行,但你过马路的时候一看左右没车,红灯也行,那么如果运气不好看漏了,遇上车祸就是自己的事了。当然也不排除运气特别差,在绿灯时遇上车祸,但那至少不是你的责任。

 

以后都按这样的方式操作,今天的话先把这个迭代的补充上,怎么看,就看配置文件本迭代这一段时间的历史修改记录。任何数据库修改,必须记录。

 

今天任务:

1. 增加“驳回可撤销”

2. 全力准备上线,功能DELAY还可以赶进度,如果上线出了事故,问题就大了

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: