在我工作的公司中，我们有两个环境：测试和生产。由于成本的原因，我们目前不会启动新的环境。
以下是我们遵循的流程：业务部门提出需求，开发团队实现并将其部署到测试环境中。然后业务人员进行用户验收测试，如果一切正常，则该功能将在下一个生产部署中包含。
问题在于测试数据库的最佳实践。开发人员将测试环境视为他们的游乐场，有时会重置数据库以进行测试。另一方面，业务人员认为测试数据库必须稳定，并且不应被重置。我们希望解决这个问题，并决定测试环境应该属于开发团队还是业务团队。（开发人员不希望业务参与测试环境，但业务团队支付服务器费用。）
关于环境的最佳实践是什么？您能推荐一篇相关文章吗？
我在许多公司工作过，每家公司都有不同的环境设置，我最喜欢的公司有 5 种环境：
1) 本地: 基本上就是你自己的电脑。这里是你编写和测试更改代码的地方，甚至还没有向同事寻求审查。
2) 开发: 如果由于某些原因你无法在本地测试自己的代码 (主要是依赖问题: "我的代码从未在我的电脑上编译通过，但在 Jenkins/Bamboo/Travis 上可以完美编译"), 那么你就将自己的更改推送到 Git 中的特性分支中，在此分支上进行 Bamboo 编译，并将其部署到开发服务器上进行测试 (此时仍然不能确定是否有效，因此没有进行同行审查)。
3) 演示: 你认为你的代码能够正常运行，并且你喜欢它的外观。你创建了一个拉取请求，以便你的同事在合并到主分支之前查看它。他们会提出意见，你会解决可能存在的问题。由于你对自己的更改更加有把握，你让 Bamboo 将它部署到演示环境中，那里存储着更“稳定”的代码，以及任何数据库中存储的更现实的数据。一旦部署完成，另一个开发者/测试人员可以检查你的更改是否真正有效，并在演示环境中进行“QA 签名”。
4) 稳定: 好了，现在你终于确定你的更改是有效的，因为你已经将其部署到演示环境中，而且没有出现任何问题。你将分支合并到主分支中，Bamboo 编译并将其部署到稳定环境的另一组服务器上 (在发送到生产环境之前，其他人不应该将未相关的合并提交到主分支上，以避免出现合并错误)。该环境应该是生产环境的复制品，包括数据、代码和服务器条件。在这里，你向你的经理、产品负责人或负责审批你工作的人展示你的更改，之后得到最终批准。一切顺利，你感到心满意足，你已经连续工作了 30 天来完成这项改变，你的妻子离开了你，但你很有信心它完美无缺地工作。
5) 生产环境: 客户连接以使用公司服务的地方，或您软件的最终版本供客户使用。在Bamboo中，只需几个点击即可将其部署到生产服务器或编译成最终版本。它是绿色的，一切似乎都很好。您在Splunk中查找错误，一切正常，生活美好，您喝完咖啡后离开，驾车回家，在周末与您的狗狗睡觉。
有这么多“测试”环境确保了质量，直到每个人（不仅仅是您）都完全确定更改有效才能上线到生产环境，这是一个圆满的结局。
在我们公司，也有两个数据库，一个测试数据库和一个生产数据库。测试数据库主要由开发人员用于测试，但有时也会用于商业测试。每天使用生产数据库的实际副本来刷新此数据库。因此，这个数据库既可以是一个游乐场，也可以是一个严肃的测试数据库。但第三个开发数据库是最好的选择。我们曾经有过一个，但它目前无法使用。但当你拥有其中之一时，你应该确保它被足够频繁地更新。当开发人员将其用作游乐场时，它将偏离生产环境，并且其数据将变得陈旧和损坏。因此，开发人员将无法自我进行良好的测试。因此，请确保您定期刷新此数据库（可能每天或至少每周一次）。
如果可能的话，给每个开发者在本地机器上分配他们自己的数据库。这样他们就可以随心所欲地使用它而不会影响其他人。这应该显著减少玩弄测试数据库的欲望，提供更稳定的商业用户验收环境。
