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还可以赶进度,如果上线出了事故,问题就大了
相关文章推荐
- 工作安排及总结 2014 08 15
- 工作安排及总结 2014 08 14
- 20131129工作安排及总结
- 20131203工作安排及总结
- 上周工作总结及本周工作安排
- 20131206工作安排及总结
- 上周的工作总结和下周的学习安排
- 20131204工作安排及总结
- 明日工作安排及今天工作总结-----日志
- 工作安排及总结
- 20131202工作安排及总结
- 走向管理:建立工作汇报机制 工作进展汇报 晨会 周会 汇报会议 讨论安排第二天的工作任务 总结上周的工作情况 制定下周工作内容的重点 制定周计划 并让大家了解本周的工作重点
- 工作总结第十四天
- 2012年终工作总结与2013展望
- 工作总结第十一天
- 2017/1/3 工作总结
- 清华建筑系毕业生工作8年后心得总结
- 工作日志之总结篇
- 最近几天的工作安排
- 工作安排(dfs深度优先搜索)