背景
多个运行环境对于项目研发来说是必须的，毕竟要经过充分测试之后才能正式发布产品，这个很好理解。笔者工作这些年经历过大概几十个项目，十几个团队，发现了一个现象：大家对运行环境的叫法和理解千差万别，几乎没见过重样的。更有甚者，一个团队的几个组，对于某个环境的称呼都不一样，或者同样一个称呼，每个人的理解却不一样。笔者多次见过因为这种认知差异造成沟通困难的情况，当双方意识到这点时，总会哭笑不得，真是「你说城门楼子，我说胯骨轴子」。
理论上来说，统一称呼和理解是一件没那么难的小事，所以往往被我们忽视，但是每次因为这种小事引起的沟通成本增加，实在是有点让人如鲠在喉。所以笔者尝试经过一定的调研，综合业内比较权威的做法来总结出一套环境命名规范，以作参考。
注意，这种规范没有对错之分，只有适合与否，调研也是为了能够符合大多数人的认知，能够尽量以理服人。所以此规范仅做参考，请各位按需取用。
正文
DTAP
软件开发领域有一个概念： DTAP。引用维基百科的介绍：
Development, testing, acceptance and production (DTAP)[1][2] is a phased approach to software testing and deployment. The four letters in DTAP denote the following common steps:
- Development: The program or component is developed on a development system. This development environment might have no testing capabilities.
- Testing: Once the software developer thinks it is ready, the product is copied to a test environment, to verify it works as expected. This test environment is supposedly standardized and in close alignment with the target environment.
- Acceptance: If the test is successful, the product is copied to an acceptance test environment. During the Acceptance test, the customer will test the product in this environment to verify whether it meets their expectations.
- Production: If the customer accepts the product, it is deployed to a production environment, making it available to all users of the system.
The set of environments used for a DTAP cycle is often called a DTAP street.
根据引用资料推测，此概念应该出现于 2009 年之前，算得上老牌的概念了。但是，当搜索【Agile + DTAP】时，会出现很多反对的声音：
我们现在的开发模式基本都是偏 Agile（敏捷开发）的，这种现象还是需要重视一下的（关于敏捷开发，可以看下笔者之前的文章《敏捷开发指南》）。DTAP 当中的 DTP 应该是没有争议的，关键是 A。笔者在国内这些年的工作经历中（主要是 toB），严格意义上的用户验证（UAT）这步是几乎没有的，更多的是被 QA 或 PM 测试后直接就上线了。
另外，一些较严肃的产品会有一个预发环境，被称作 staging 或 pre-release，好多人将 A 理解为此，为了能够更清晰的区分，我们现将 staging 环境做如下约束：与生产环境使用同一套数据库。至于用预发环境做什么，比如用户验证、A/B Test、染色等等，这些都不是其最本质的特点。
针对以上两点，我们来进行补充和优化，具体见【结论】部分。
Git Workflow
这里在顺便提一嘴 Git Workflow（以下简称 GW），也就是多人协作下的 Git 工作流规范。这跟环境命名有什么关系呢？
实际上 GW 的目的就是让开发过程变的有序，落地到实际就是某个分支的代码对应到不同的运行环境。也就是说【分支 <=> 运行环境】理论上应该是个较强的映射关系，这样做的另一个好处就是可以结合 CI/CD 工具实现各种流程自动化的操作。
笔者早前写过一篇《Gitflow 太繁琐？为什么不自动化呢》，里面较详细的梳理了 GW 的底层逻辑和分支的对应关系，文末的结论也会有【分支】的内容。
结论
说了那么多，直接上表：
| 环境 | 英文 | 缩写 | 说明 | Git 分支 | 备注 |
|---|---|---|---|---|---|
| 生产环境 | Production | prod | - 用于真实生产 - 极其稳定 - 不允许有 bug 和脏数据 | master/main | 别名：线上、正式环境 |
| 预发环境（可选） | Staging | stage | - 正式上线前的少量灰度 - 极其稳定 - 不允许有 bug 和脏数据 - 与生产环境使用相同的数据库 | matser/main | 多用于上线影响极大的服务，也可用于 A/B 测试。 |
| 验收环境（可选） | Acceptance(User acceptance testing) | uat | - 用于用户验收或展示新功能 - 很稳定 - 不应该有 bug 和脏数据 - 单独数据库 | release | 多数情况会用测试环境替代。 |
| 测试环境 | Testing | test | - 主要提供给 QA、PM 测试 - 基本稳定 - 可能存在少量 bug 和脏数据 - 单独数据库，可能会 mock 数据 | release | |
| 开发环境 | Development | dev | - 方便开发时联调 - 极不稳定，随时可能挂 - 可能存在大量 bug 和脏数据 - 一定要单独数据库，可能会刷数据 | develop | 以下情况都有可能发生 - Git push -f - 刷数据库 - 没有权限控制 |
最后，还是要再强调一遍。此规范没有对错之分，请各位按需取用。
彼得定律：在一个等级制度中，每个职工趋向于上升到他所不能胜任的地位。
In a hierarchy, every employee tends to rise to his level of incompetence.——Laurence J. Peter
