研发流程有多个不同的环节构成，一般分为开发、测试、验证和部署，这些环节需要不同的环境来支撑。对于企业来说，这些环境又需要互相配合来完成正常的研发部署工作，为了避免混乱的相互引用、提高协作的效率，界定环境之间的配合关系非常重要。
环境的类型
完整、可靠的研发流程涉及到五类不同的环境，从职责上划分类似下图：
其中，准生产环境和系统测试环境用虚线表示，是因为这两个环境不是必需的，在符合一定条件的时候创建这两个环境。
开发调试环境
开发调试环境是整个项目的地基，但不一定必须是“本地”的，一个原则是**“保证每个开发工程师能够有独立的、可运行的完整环境”**，这样能够有效避免代码的覆盖、相互间的干扰等导致的莫名其妙的问题。
一般来说，开发调试环境背后使用的数据库、缓存、共享存储等公共服务可以是共用的。相对来说，复制一份代码的成本是很低的，但是为每人都建立数据库、缓存、共享存储的成本较高，而且它们在开发过程中的调整并不频繁。
代码控制
即使只有一个人负责的项目，仍然强烈建议使用版本控制工具。它确实带来一些成本，但绝对物有所值，想象一下工作的移交、较为久远项目的再维护、决策依据的记录、决策对代码范围产生的影响等常见场景，使用版本控制工具能够快速有效的应对这些场景要求。
多人协作的项目对版本控制的依赖就更不用说了。
到这一层，研发人员直接控制代码部署的权限就没有了，后续三个环境的代码部署要完全依赖SCM系统。如果你的项目还没有实现这个目标，请立即想办法解决。
集成测试环境
在软件项目中，“集成”有多个不同的含义，这里特指代码的合并。
一般情况下，每个工程师产生的代码在提交到SCM时，理论上都是能够在自己的开发调试环境中正常运行了。但是多名工程师提交的代码在经过合并后，很有可能不能正常运行，比较常见的问题是配置文件的差异，这就需要一个集成测试环境进行验证。
集成测试环境验证通过后的代码才能提交到测试团队那里进行测试，所谓验证通过，是指没有低级的错误，比如数据库连不上，具体的标准需要测试和研发团队磨合、摸索和实践。
为了提高资源利用率，测试团队也在这个环境对开发团队提供的SCM代码版本进行测试。
请注意，在这个环境部署代码必须从SCM里获取，最好能有自动化的平台和工具，严格禁止绕开SCM的代码部署行为 。
系统测试环境
系统测试环境不是必需的。
当研发团队里有专门的测试成员时，有必要建立这个验证环境，不过在建立之前，可以考虑跟开发人员一起共用集成测试环境。当共用集成测试环境对研发工作带来较多不便时，可以考虑建立系统测试环境了。
这个环境是测试成员专属的，开发人员没有权限向该环境上传代码，而应该将代码通过SCM交给测试成员，比如使用专门的release分支。
准生产环境
集成测试环境里，开发人员掌控该环境的代码控制权限。系统测试环境里，测试人员掌控该环境的代码控制权限。从准生产环境开始，开发、测试团队将不能直接干预代码的部署工作，应该由专门的配置管理员完成。
准生产环境有四个至关重要的用途：
- 为其它系统的开发调试、集成测试环境提供相对稳定的接口服务
- 为功能验收提供相对完整的验证服务
- 为生产环境的数据变更提供验证服务
- 为生产环境的BUG重现提供支撑
这个环境的负责人应该是实施团队、配置管理团队。
准生产环境并不要每个系统都要建立一份，可以根据系统的规模、重要程度、敏感程度、稳定性要求酌情建设。
当系统的规模较大、重要程度高、敏感程度高、稳定性要求高时，准生产环境是非常适合建设的。相反，可以不用建设，环境越多，维护的成本越高，保证代码状态的控制手段越复杂。
预发布 | 生产环境
生产环境是控制最严格、稳定性要求最高的环节，这个环境只允许配置管理人员、基础设施人员具备管理权限和代码部署权限。
同时在该阶段，较大规模、相对重要的系统一般也需要一个“预发布”环境。
预发布环境
预发布环境是代码进入生产环境前的最后一个验证环节，它一般不参与生产环境的运行，但是拥有跟生产环境一致的代码状态。
这个环节的验证工作并不进行功能级别的验证，主要确保数据库联通性、接口可访问性等需要其它系统配合的关键节点。
生产环境
预发布环节验证通过后，就可以将预发布环境的代码镜像到每一台生产服务器了，具体镜像的方法，根据实际情况选用。但实在不建议逐台手动完成镜像。
不同环境间的协作关系
环境间的协作一般是指API或Service级别的对接，一般的规则是：
- 生产环境，不为任何非生产环境提供接口服务
- 准生产环境、集成测试环境，能且只能为其它系统的开发、集成、验证环境提供接口服务。
- 开发调试环境、系统测试环境，不应该为任何系统的任何环境提供接口服务。
生产环境，不为任何非生产环境提供接口服务
需要说明的是，在ESB已经就绪的情况下，接口服务要逐步迁移进来，以便管理和维护，否则很容出现系统关系的“蜘蛛网”结果。而且ESB还能提供专业的接口管理、质量监控等手段，保证接口的稳定性。
生产环境的接口不允许向其他系统的非生产环境提供接口服务，是为了避免开发、测试带来的干扰。
准生产环境，能且只能为其它系统的开发、测试环境提供接口服务
准生产提供相对稳定的接口服务，通过这一层向其他系统的开发环境、集成测试环境提供服务，能够提高对端系统的调试效率。
我经常看到，当在开发、集成环境向对端提供服务时，由于代码调整的频繁性，导致对端系统的调试屡出问题，可能刚刚还正常的功能，几分钟后就不正常了。而对端工程师一般不知道对接系统代码的发生了变更，会花费相当多的时间在自身找原因。
有时候，对端系统会要求对接系统保持稳定，但因此又影响了对接系统的开发进度，对接系统不得不小心翼翼地进行开发。
从图上可以看到，ESB准生产环境到开发、集成环境间有一个“单向”箭头，它的意思是说：ESB准生产不接入任何非准生产环境的接口。
前面说过，准生产环境的建立不是必要的，当一个系统没有必要创建准生产环境时，接口服务的提供只能让集成环境承担了。此时为什么不让验证环境承担呢？是因为验证环境仅面对测试人员，测试人员不具备调试接口的能力，开发人员又不具备该环境的权限。
开发环境、集成测试环境、系统测试环境间的关系
在整个流程中，开发环境是最不稳定的系统，所以不要考虑让这个环境为其他它任何环境提供接口服务。
上面提到，集成测试环境能够为其它系统的开发环境、集成、验证环境提供接口服务，基本上跟“准生产”环境一致了。不过这样做是为了兼容实际开发工作碰到的协同问题，是有条件的。
举个例子，系统A的升级开发要求系统B提供新的接口服务，B的这个接口显然需要通过A验证，甚至可能要和A系统同步上线。那么A系统的新开发接口是不具备部署到准生产环境的要求的，可是我们同时要求“开发调试环境，不应该为任何系统的任何环境提供接口服务”，以免互相干扰各自的开发进度，那么将这个接口部署到集成环境就是一个可行且相对稳定的方案了。
系统测试环境不向任何环境提供接口服务的理由在上一节已经提到过了。
部署流程
本文第一副图中标明了每个环境参与的主要角色和对应的代码分支，这些分支对应基于Git的Gitflow模型，下图标识了环境、分支、参与人员在完成代码上线工作的协作流程。
结论
从实际开发工作来看，上述几个环境基本能够解决多系统协同带来的问题，但是提高了维护成本。不过跟软件质量相比，还是非常有价值的。
而且，我们也可以根据自己的研发流程适当增减，但集成测试环境仍然建议必须具备。
注意：本文归作者所有，未经作者允许，不得转载
