12 factors中的第十个，开发/生产对等，告诉我们尽可能的保持我们的环境一样
可能有一些组织已经做到了环境对等，但是我们中的大多数人都是工作在下面这样的环境中的：QA环境，以及有不同扩展性和稳定性要求的共享的开发环境。数据库驱动在开发环境，测试环境与生产环境都是不一样的，加密规则，防火墙以及其他的环境配置也是不同的。一些人有能力部署其中的一些环境，但是总有一些环境无法部署成功。最终结果是，开发人员将会害怕环境，他们即便能够在生产环境部署成功，也基本上没有信心能够在其他环境部署成功
前面讨论设计，构建，发布，运行阶段的时候，我指出“在我们的机器上工作的很好”（在其他环境不行）本身是违反云原生模式的。同样的，“在QA上工作良好”，“在生产环境工作良好”也是违反云原生模式的
遵循环境对等的规则是为了给你的团队和组织信心：应用程序将会在所有环境都工作良好
然后有很多因素都会导致环境的不一致，下面这些是最常见的：
*时间 *人员 *资源
在很多组织里面，从开发人员提交代码到代码真正的部署到生产环境，中间可能会间隔数周或者数月。在这样的组织里面，你可能会经常听到类似“四分之三版本” 或者 “12月20xx版本”，的词语，这样的词语是为了提醒其他人注意一点
如果发生了这样的间隔，人们通常会忘记有哪些功能将会被发版进去（尽管可以通过release notes来回顾），而且更重要的是，开发人员已经忘记了代码是什么样的
一种更现代的方式是，组织应该努力去缩短代码提交到生产发布的时间间隔，将它从数周或者数月缩短到几分钟或者几小时。一个合理的CICD管线应该自动在不同的环境执行测试，并且在测试通过之后将程序推送到生产环境。随着云支持“零停工”部署，这种方式将成为标准
这种想法可能会吓到很多人，但是一旦开发者习惯了这种开发方式，并且知道他们的代码将会在提交的同一天就会发布到生产环境，组织纪律和代码规范将会得到极大的提升
从历史来看，部署应用程序的人与公司的规模直接相关。小公司里面，开发人员编写完代码之后还要去部署程序，但是大公司里面，更多的人和团队会介入
原始的12因素表明开发者和部署者应该是同一个人，这个在应用部署的平台是一个像Heroku一样的黑盒的公开的云平台确实很有意义；但是这个做法在一个大型组织里面，需要把应用部署到一个私有云上面通常会不奏效
此外，我认为人类不应该部署应用程序，至少不应该部署到他们自己的工作站或实验室以外的任何环境中。如果存在适当的构建管道，应用程序将自动部署到所有适用的环境中，并且可以根据CI工具和目标云平台中的安全限制手动部署到其他环境中
事实上，即使您的云是公共云提供商，仍然可以使用CloudBees或Wercker之类的云托管CD工具来自动化您的测试和部署
尽管总是有例外，但我认为，如果您不能通过按一个按钮来部署，或者不能自动响应某些事件，那么您就错了
当我们坐在办公桌前，在本地开发的时候，由于要快速启动和运行某些东西时，我们就会做出妥协。这些妥协可能会给我们留下一点技术债务，也可能使我们陷入灾难性的失败
其中一个折衷办法我们使用和提供后端服务的方式。我们的应用程序可能需要一个数据库，而且我们知道在生产环境中，我们会将它连接到Oracle或Postgres服务器，但是在本地搭一套数据库太麻烦了，所以我们会妥协并使用类似于目标数据库的内存中的数据库
每当我们做出这样的妥协时，我们的开发环境和生产环境之间的差距就越大；这种差距越大，我们对应用程序行为的可预测性就越低。随着可预测性的下降，可靠性也会下降；如果可靠性下降，我们就失去了敏捷开发持续发布的能力。它给我们所做的每件事都增加了一种脆弱感；最糟糕的是，我们通常不能提前知道增加开发/生产环境差距的后果，直到知道时已经为时已晚
现如今，开发人员有太多的工具去规避环境不一致的问题了，开发者能够通过PaaS平台的一个服务，或者可以通过类似Docker的容器工具来保证他们的本地工作的数据库实例与生产环境几乎一样
当您在构建云原生应用程序的过程中评估开发生命周期中的每一步时，每一个增加部署环境之间的功能差距的决策都需要被标记和质疑，并且您需要抵制通过允许你的环境存在差异来给开发带来便利性的冲动，即使这种差异在当时看来无关紧要
本节以及本书的后面将会多次提及这个规则：每个提交都是一个部署候选
在以云计算方式构建应用程序时，每次提交更改时，该更改都应在一段短时间后进入生产环境：基本上是运行所有测试、根据所有集成套件检查更改以及部署到预生产环境所需的时间
如果您的开发环境、测试环境和生产环境不同，甚至是在你认为无关紧要的地方产生了不同，那么你就失去了准确预测代码变更在生产环境中的行为的能力。这种对代码部署到生产环境的信心，对于持续交付、快速部署（允许应用程序及其开发团队在云中蓬勃发展）至关重要