环境回滚升级理解

对于一个测试人员，在迭代开发和迭代测试方式的普及下，环境的回滚和升级成了测试人员（负责环境维护）的一项技能。在负责某个局点的环境升级和维护的过程中，对于自己的成长还是可见的。总结一下，自己的一些理解。

环境回滚升级的过程

常用的命令，如何解决问题：

转测邮件是环境升级过程中的引子，也是比较重要的一步，其中包含了迭代转测的范围；此次升级归档的范围的以及取包的路径；由于开发和测试不是在同一套环境上进行，通常都是开发先升级验证然后在到测试这边；所以，转测邮件上偶尔也是附带上升级过程遇到的问题以及规避的方案。转测邮件一般会结合周日报一起看，因为便于了解这个版本的迭代周期和迭代范围。

在创建升级环境之前需要进行环境的回滚。这个就涉及到对“迭代”的理解。开始的时候，每次都是迭代升级，升级之前都是按照严格的步骤执行，即回滚----创建升级任务----升级。直到一次版本发布之后的升级。这一次，却跳过了回滚这一步，很是好奇，于是便向QA提出了自己的疑惑。所谓的“迭代”其实是对系统进行了模块化的划分，然后进行开发，每一次的迭代其实是同一个版本；当这次迭代升级完成验证通过后，需要进行环境的回滚，回滚至原始的版本，然后进行再次升级，这次的升级内容已经包含上一次迭代的包了；如此经过几轮迭代后，直到该版本验证完发布，当前版本结束，不需要回滚。下一次的升级是另一个版本的开始。

升级过程中常会遇到的几个问题：

1.在环境的备份过程中是对相关升级包的备份，因此对磁盘空间和对应目录的大小是有要求的，当遇到错误的时候，也是可以通过相关的日志进行查看的。常常设计的一些命令有：

df –h  列出文件系统的整体磁盘使用量,并以人们较易阅读的GB,MB,KB等格式自行显示

du –sh * 评估文件系统的磁盘使用量并列出所有的使用量

具体的请看转载Keyboard_123的CSDN博客：

https://blog.csdn.net/SCF_1104/article/details/89915537

查出占内存比较大的磁盘和目录，然后根据里面内容的情况进行删除（一般是上一轮迭代的升级包所在的目录占用的空间比较大）

tail –f 日志：动态的现实日志

2.升级过程中错误的解决：

在升级过程中，问题是无法避免的，每次遇到问题的第一反应便是截图给QA看，自己连日志也不瞅一眼，然后便拖着椅子坐到QA的旁边，看着他界面看日子，然后去后台处理日志，找到问题的缘由，涉及平台的便拉着平台的开发定位解决。一次，两次，三次。。。而每次基本都是晚上11点边上。终于，有一天，还是被约谈了。结果，很显然，后面他要退出局点升级维护了，遇到问题需要自己去解决了。被迫营业的好处是，痛苦的开端之后便是一个不错的过程。

遇到问题的解决思路：

前台升级任务执行报错------>选择debug日志，查看报错的范围(确定是哪个网元，哪个节点)------->找到报错提示的最开始位置，根据日志，去后台查看具体的debug日志-------->确定问题涉及范围，找平台帮忙定位找原因------->手工规避问题，继续升级-------->升级成功，提单跟踪---------->整理升级过程问题及解决方案