就在前不久，上面让运维搞了一套预发布环境，也不知道谁的指令，我猜测十之八九是头下的吧。因为增加了一套环境，苦逼的测试猿的事情也就相应的增加了，谁让我们是底层的小兵呢，难免。那有人会问，既然这样，你还抱怨啥，还有何好说的？好吧，且听我慢慢道来。
问题出在哪里？
问题是，预发布环境的部署、设计、配置。和运维经过简单的沟通得知，我们的预发布环境是一套单独的环境，用的数据库是独立的数据库，和集成测试环境、测试环境，线上正式环境没有任何关联，用的数据是我们测试猿自己造的，刚开始的时候代码拉取的是测试环境用的trunk代码，直到后面才从单独的release分支拉取，不仅如此，预发布环境的环境配置还不如测试环境，比如涉及到支付宝口碑门店管理，外卖接单等的功能也只能在测试环境测试，因为再搞个这样的环境需要有相关资源如口碑商家帐号，需要对接外卖，比较麻烦，所以没配置好。
再说测试，作为测试猿，需要在测试环境把功能测试一遍(按头要求，通常是“你们把相关功能全部重新过一遍”)，然后呢，在预发布环境重新全部再过一遍，接着线上再过一遍。因为需求任务还是蛮多的，可想而知，这里的工作量了。按我上面的描述来看，我们搞的预发布，等同于说再搞了一套测试环境，然后人力的重复投入，在测试环境漏测的缺陷，在预发布环境一样的存在。
再说运维，预发布对于运维来说，还是有点好处的，类比的说，把代码从测试环境部署到预发布环境，这个过程就是上线前的一次“演练”，当把代码从预发布部署到线上环境时，按上次演练过程再来一遍，自然顺畅多了，但是“演练”的代价是建立在测试人力资源浪费的基础上。
心里好困惑，因为按我之前的理解，预发布本身就是线上环境，用的就是线上数据库，为何到了我公司，咋就成这样了呢。再次找运维沟通，运维给的理由是，预发布不可能用线上的，理由是：如果程序需要更改表结构，比如加表字段，那部署到预发布的时候，改了线上的数据库，岂不是也会影响线上环境的使用。
于是，我问了好些人，得到的答案基本是说，预发布应该尽量接近生产环境，预发布就是正式环境，用的数据库也是线上。
因为上班比较忙，这个问题就放着没再理了，直到后来想起了，又去寻求答案，问了下一个在搜狗工作的人员，得到了一个相对满意的答案。
这里就结合我自己的想法，对预发布做个常规性总结：
1、预发布环境，就是线上环境、正式生产环境，为避免因为测试环境和线上环境的差异性等带来的缺陷漏测而设立的一套环境，其配置等基本和线上一致，只是预发布环境web服务器不在线上集成服务器范围之内，为单独的一台机器；
2、预发布环境不能被线上用户访问
通常这里的技术实现是这样的：把预发布环境的访问域名设置成和线上环境的不一样，通过配置host来访问预发布环境；
3、预发布环境和线上环境公用数据库，即预发布环境使用的是线上的数据库
问题：如果新版本程序需要更改表结构等，比如加个表字段，那么，部署到预发布环境时也需要更改表字段，这个可能会影响线上环境程序代码的运行，咋解决？
①先把预发布环境使用的数据库切换为测试环境使用的数据库
②根据实际部署过程，如果有必要，接着，可有针对性的测试下数据库的变更是否会影响线上当前代码程序的运行(注：个人想法)
③把新代码部署到预发布环境，测试程序是否正常运行
④预发布测试完毕，如果没问题，先上线数据库，即在正式环境执行对应的数据库变更操作
⑤紧接着，把预发布环境连接的数据库切换为线上环境使用的数据库，再次进行预发布环境的测试
⑥最后，如果预发布环境测试通过，则把预发布环境的代码部署到线上生产环境。
需要注意：
1、如果不需要更改数据库表结构等，则无需切换预发布环境环境使用的数据库，即预发布使用线上的数据库。
2、这里，因为预发布环境本身就是线上环境，测试完预发布，也基本代表线上环境测试完成。这样还可以避免发布到正式环境还得再测一遍的情况。
上面仅供参考，没有绝对，不一定适用所有公司，根据实际情况处理，如果你有想法，欢迎评论探讨。