pro、pre、test、dev 环境

test 环境：测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定。

dev 环境：开发环境，外部用户无法访问，开发人员使用，版本变动很大。

分成四个环境原因：

大多数人都知道四个环境指的是什么，但是很多人却不知道为什么要这么区别，甚至为了省事就只有 dev 和 pro 环境。如果项目没有上线之前没有问题，如果项目上线之后就会有非常麻烦的事情发生。下面我们针对这四种环境，来分析一下对应的各种场景。

dev+pro：

如果我们只有 dev 和 pro 环境，pro 突然发现 bug，需要紧急处理，只有两个环境，这个时候我们要如何解决呢？？？

首先 dev 现在已经更新到 1.1.0，而 pro 现在才 1.0.0，所以这个时候我们需要重新创建一个 brunch 分支，这边我们可以叫做 1.0.0.1,然后修改代码之后需要放到 dev 环境上面进行测试，这个时候就会变成如下所示状态：

然后测试通过之后，我们需要将 1.0.0.1 发布到 pro 环境，然后合并 1.0.0.1 的代码到 1.1.0 中，最后将 dev 环境修改为 1.1.1，如下所示：

在 dev1.0.0.1 测试期间，所以开发工作全部得停止，必须等测试通过发布到生产上面才可以，如果仅仅只有两个环境，代价实在是太大了！！

dev+test+pro

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

如果我们多了一个 test 环境情况就会好很多了，比如上面说所的问题，我们就可以这么来处理。

我们可以在 test1.0.0 上面直接修改，修改后的版本是 1.0.0.1，测试通过之后直接发布到 pro 环境即可。然后再将 test 中 1.0.0.1 代码合并到 1.1.0，最后 dev 的版本升一级就可以了。

这样的好处就是不会影响 dev 开发环境，不管怎么修改 test，都不会造成 dev 暂停。

dev+test+pre+pro：

如果 test 环境和 pro 环境版本不同步，还是会有问题存在，比如 test 环境在测试 1.0.1 版本的代码而生产上面运行的是 pro 环境的代码，这个时候 pro 出现问题修改的时候就会比较麻烦。

这个时候和之前的做法一样，创建一个新的 brunch 分支（1.0.0.1）然后在 1.0.0.1 中修复 bug，然后发布到 test 最新版本中，测试通过之后发布到 pro 环境中。然后就是复杂的合代码操作了，将 1.0.0.1 代码合并到 1.0.1 中，将 dev 的 1.1.0 添加上修复的代码变成 1.1.1。

这种情况下，首先在 test 测试期间，1.0.1 的测试工作会停止，其次步骤太繁琐，所以这边我们新增了 pre 环境。