研发环境的搭建

这两个月在推进研发流程的建设，可以用 呕心沥血 来形容，因为决定给你资源的人不太懂 IT。

首先，以前的技术leader认为自己只做“架构师”，不管理团队，留下了这样一个困局给接手的我。

1）引入多种技术栈，下属不能很好承接，golang、vue、nodejs、把外包公司做的java项目用golang和php重写了。

2）开发者写完代码就提交测试了，测试了好久都还不能上线。同时种bug的提法是【测试环境】xxx bug、【正式环境】xxx bug。更汗的时，这位leader的设计下 测试环境和正式环境的 代码基 是不一致的。

然后，我的做法时，

对于 1）这个地雷，现在还只能捧在手上不能让它掉地上了，只能是后面做一点挪一点的做法去排雷了，因为每一个家公司对人员的数量都是严格控制，领导也不会让你停下手上的工作花个4、5个月只做重构，同时一个合格的职业态度也是你不能看着不爽就去重构。

对于2）是目前我可能改进并且短期内可以看到效果的。但 呕心沥血 在和不懂 IT 的资源方沟通，可以用不懂技术来形容，他们以为每一个环境都需要他们参与，给我的阻力是增加了他们的工作量。但不正是由于他们没做好这方面的工作才导致测试了好久都有各种bug上不了线么？意识上出现死锁了。

听不明白要做什么，惯例来一碗鼓励的鸡汤。

后面回家后我仔细想想才发现他们以为 开发环境也要他们负责测试，以为每个环境都要他们测试，都不知道问这个问题的人是不是以前真的写过代码。

==================== 不吐槽了，开始正文 ，直接把给资源方的通俗版贴出来 =================

声明：以下对各个环境的定位只适合当前，未来还有改进。

我们以新项目为开始，逐步搭建好
1）本地环境（使用人：一个开发者，自己开发自己的代码）
2）开发环境（使用人：多个开发者，集成开发的代码）
3）测试环境（使用人：测试人员）
4）灰度环境（使用人：开发者、测试人员，非常少用到，使用场景是：1> 新功能改动大不能直接上线正式环境需要少量流量进来验证 2> 开发者 定位正式环境下的问题）

5）正式环境（使用人：真实的用户）

假设：

1）项目域名为 www.xxx.com，域名的公网解释为 2.2.2.2

2）测试环境的服务器公网 IP 为 1.1.1.1

3）使用 https

我们最初的目的是，各个环境都是独立和完备（完善）的，同用同一个域名（通过修改hosts把流量切换到不同的环境）

目前 XX项目 已经用上测试环境、正式环境
但目前 XX项目 遇到一个问题，位于公网的OSS服务需要回调我们各个环境内部的服务器，我们期望如下

但由于OSS服务器位于公网，我们不能通过修改hosts的方式把 OSS的流量切换到各个环境内的服务器，因为在公网 这个域名只会解释到公网的IP

解决方案是，不同环境的配置参数不同：
1）非正式环境，配置是 http + ip
   再由 ip --转vhost--> hostname，这么配置的目的是让OSS的流量直接去到指定的环境的ip对应的服务器，这样OSS的流量就不会去到正式环境的公网ip对应的服务器了

2）正式环境，配置是 https + hostname

==================== 基础知识补充 ====================

http://www.xxx.com/callback 与 http://1.1.1.1/callback 这两种形式的 URL 有什么区别？这个区别就是这次方案的关键点了。

读者自己想吧。

给点 Tips，用fiddler抓包看一下，不要用chrome 的 devTools 看，看不出的。