production-environment - 测试和生产环境的最佳实践

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

5 个月前关闭。
社区在 14 天前审查了是否重新打开此问题并关闭:

原始关闭原因未解决





Improve this question




在我工作的公司，我们有 2 个环境:测试和生产。由于成本原因，我们目前没有开始新环境。

这是我们遵循的程序:业务提出功能请求，开发使其发生并将其部署在测试环境中。然后业务对其进行测试(UAT)，如果没问题，该功能将包含在下一个生产部署中。

问题是测试数据库的最佳实践。开发人员将测试环境视为他们的游乐场，有时他们将 DB 重置为初始状态以进行测试。另一方面，业务人员认为测试数据库必须是稳定的，不应重置。我们想解决这个问题，并决定测试环境应该属于开发团队还是业务团队。 (开发人员不希望业务将他们的 Nose 放在测试环境中，但业务团队正在为服务器付费。)

关于环境的最佳实践是什么？你能推荐一篇关于这个的文章吗？

Answer 1

我在很多公司工作过，每家公司都有不同的环境，我最喜欢的一家有 5 种环境:

1)本地:基本上是你的机器。在这里，您甚至可以在要求同行审查之前编写和测试您的更改。

2) 开发:如果由于某种原因你不能在本地测试你的代码(依赖问题主要是:“我的代码在我的机器上编译了 neves 但它在 Jenkins/Bamboo/Travis 中编译得很好”)，那么你将你的更改推送到你的功能分支在 Git 中，让 Bamboo 编译它并将其部署到可以测试的开发服务器上(您仍然不确定它是否可以工作，所以到目前为止还没有同行评审)。

3) 暂存:你认为你的代码有效并且你喜欢它的样子。您创建一个 Pull Request 以便您的同行在它合并到主分支之前查看它。在这里，他们发表评论并修复可能的问题，因为您对自己的更改更加确定，您可以让 Bamboo 将其部署到 Staging 环境，在该环境中存在更多“稳定”代码，并且更真实的数据存储在任何数据库中。部署后，另一个开发人员/测试人员可以检查您的更改是否实际有效，并使您成为“暂存环境中的 QA 签核人”。

4) 稳定:好的，现在您最终确定您的更改在部署到 Staging 后可以正常工作，并且没有任何问题。您将分支合并到 master，Bamboo 编译 master 并部署到稳定环境中的另一组服务器(在您完成对生产的部署之前，其他人不应合并到 master，以避免合并不相关的合并)。这个环境应该是生产、数据、代码和服务器条件的副本。您可以在此处向您的经理、产品负责人或负责人展示您的更改，以在将其发送到生产之前验证您的工作。你得到了最后的批准，一切都很好，你满头大汗，你已经连续工作了 30 天来完成这个改变，你的妻子和你离婚了，但你非常有信心它可以完美地工作。

5) 生产:客户连接以使用公司服务的地方，或发送给客户的软件的最终版本。在 Bamboo 中点击几下，您就可以将其部署到生产服务器或编译最终版本。它是绿色的，似乎一切正常。您检查 Splunk 以查找错误，一切都很好，生活很好，您在离开前又喝了一口咖啡，然后开车回家，整个周末都和您的狗一起 sleep 。

这是一个圆满的结局，因为拥有如此多的“测试”环境可以确保质量，在每个人(不仅仅是您)完全确定更改正在起作用之前，不会有任何更改进入生产。