能快速提供一个子环境吗？

对于一个系统来说，如果不能很好的隔离出一个个子环境，那说明架构是不完善的，什么是子环境呢？开发环境，QA环境，仿真环境，线上环境。

这些环境对应的用户和功能也是不一样的，有几个特征，这些环境是否能够快速提供，环境之间是否是隔离的，稳定性怎么样，是不是比较仿真的（数据和架构）。

另外还需要注意成本，不仅仅是机器的成本，还包括协调成本，比如怎么说清楚。

那么如何搭建这些子环境呢？可以重新搭建，也可以从线上服务器中隔离出。

隔离的越彻底，说明架构设计的比较好，也更仿真。当然为了减少成本，也会复用一些资源，做些取舍。

说到隔离，web服务可以通过SLB隔离，数据库可以通过proxy隔离，redis同样如此，关键是子环境配置是否自动化，是否可管理，系统更新能否一致性，减少人为干预，从这一点上来说，这也是k8s流行的原因，基础设施即代码。

从入口上来说，如何区分这些子环境呢？目前使用域名来区分，配合SLB做调度，现有业务域名（SLB也可以根据路径做策略）非常多，配置搞的很多，很容易出错。

程序通过域名来做配置管理，耦合的比较厉害，不管什么架构，建议使用环境变量来加载，环境变量可以来源于docker，php-fpm，linux环境变量等等，但对程序来说，它就是读取环境变量，所以不关心服务是虚拟机部署，或者docker部署，从这一点来说，技术在迭代的时候，一定不要走弯路，大方向上要把握住，然后尽量往前走。

整个环境或集群如何部署呢？可以使用ansible这样的运维工具，也可以使用阿里云镜像的方式，或者未来的docker容器化。目前使用阿里云镜像，但有一个问题，镜像可能是数月前打的，现在重新基于镜像做一个服务，此时拉取的代码或者系统配置可能是旧的，所以还是需要有一定机制去更新，可以写shell，但估计ansible这样的工具更标准。

子环境必然和CI/CD一一对应的，包括Git工作流，目前我们采用类gitlab flow，其实做法有很多种，先说说目前怎么做的，我个人觉得还行。

分为开发分支，QA分支，Pre仿真分支，Master分支。开发一个功能的时候，首先基于master打一个开发分支，多人合作，然后本地测试通过后，合并到QA分支供测试，测试差不多后，将开发分支合并到pre分支，进行仿真测试，没有问题后再将开发分支合并到master分支上线。

原来我们是将master分支直接部署到仿真环境，但这样有个弊端，合并到master后因为各种原因先不上线，如果此时有个bug，基于master弄出一个bugfix分支，改好后也没法上线（会把不想上线的代码也部署上去）。所以才弄出一个仿真分支，需要开发尽量保证pre和master分支是尽量同步的。