理解预发布环境和项目部署流程

Posted 2020-12-02 lsjdddddd

题外话：

终于又提笔了。一直都记得博客园，偶尔看到评论，偶尔也会翻看旧的文章。一直没有写是因为这段时间里有些忙碌，学习测试方法分析，自动化编程，发布流程环境管理，测试提效，学习和积累是一个漫长的过程，以及暂时没有找到可以单独成文写出来的内容。

这次文章讲到的内容，是如何从一个测试角度看待发布流程和环境管理这些在功能测试前应该先了解的基础。

 

一、环境

开发环境：

通常表示最低环境，由代码开发人员直接使用和维护，是代码最超前版本的一个环境。

 

测试环境：

开发人员确认代码分支在开发环境自测没有问题后，提交测试环境进行测试。

测试环境对代码和系统已经集成，可以供测试人员进行功能模块测试，集成测试，系统测试，测试环境有独立的数据库和账号权限管理系统，由测试人员使用和管理，功能型bug一般在测试环境中暴露较多。

 

预发布环境(Pre)：

测试人员确认代码在测试环境经过测试用例测试没有问题后，提交预发布环境进行测试。

预发布环境作为上线前的最后一套环境，所有的功能和配置，数据库都已经与线上环境高度相似，仅准入本次需要上线的功能代码。测试人员使用该环境可以实现大面积的功能测试，该环境比较容易出现不同jar包的依赖和版本匹配问题。预发布环境测试没有问题的代码可以直接将该代码分支提交上线。

预发布环境不常见，一般在比较大，项目相对复杂的环境会特别搭设预发布环境，甚至有公司会搭多套预发环境供上线前使用。预发环境可以独立建立数据库，阶段迁移一些线上数据作为预发环境的测试数据；也可以直接连线上数据库测试，但这种方式需要注意脏数据的产生。

 

线上环境：

最高环境，直接面向用户。

 

二、部署

1）Application的版本管理：

通常被很多测试忽略的一点，就是检查当前测试的包的版本号。如果版本号与开发最新提供有误，需要查看最近一次部署是否成功。

 

2）新代码分支部署进测试环境主干代码的方式：

模式1：合并后测试。开发人员A与B的代码分支同时merge进app，提前解决冲突后，再进入测试环境供测试人员测试。

模式2：单个模块测试后退出环境。开发人员A代码分支可以先上到测试环境，测试人员测试完成后，再将A代码分支退下，提交B代码分支测试，每个分支独立管理，上线前再整理全部需要上线的分支代码。

 

3）上线后的所有代码需要merge到开发环境，保证后续所有代码都基于线上代码开发，避免版本漏洞。

 

4）发布计划：

当前后端代码都需要上线/资源存在依赖关系时，需要安排application的发布顺序，如：前端的逻辑依赖后端代码，必须先发布后端，再发布前端。

 

 

三、工具

1）showip

showip工具在浏览器右下角直接展示当前页面的IP地址，在测试中可以快速查看当前访问机器的版本号，以IP地址判断当前访问的环境是否正确。

https://chrome.google.com/webstore/detail/agoljmemkbciolpigpabjfkagboolkcj

2）URL Redirect

Redirect工具可以快速重定向某些资源的url地址，以方便在某些环境测试的时候需要用到另外一些环境的资源。

https://chrome.google.com/webstore/detail/kpdinddojclpdndplpblgckkfepjplie

（以上小工具均为chrome插件，非常快捷使用和安装）