我在一个小型的编程团队中工作，为较大的组织提供支持。今年，我们的经理决定我们将使用Oracle Apex技术来处理我们公司的绝大多数数据。

可以，除非我们只有一台Apex服务器。我们的经理已下令一切都发生在那个实例中。我们的团队正在开发应用程序，而经理演示的是应用程序，而内部客户则在使用它们，这显然已经引起了问题！

我只能期望随着我们对Apex的投入越来越大，应用程序变得更加复杂以及用户数量的增长，这种情况会变得更糟。我听说最佳实践是拥有单独的开发，测试和生产环境，但是为什么会这样呢？

问题：为什么我们要有单独的开发，测试和生产环境？

为什么我们要有单独的开发，测试和生产环境？

您同时进行多项活动：

• 开发-开发人员在其中提交代码，犯错误，进行实验等。
• 测试-由于复杂性，在手动或自动运行测试的地方可能会消耗大量资源。
• 生产-为客户和/或企业创造价值的地方

您是否希望所有这些都在同一环境中发生？您是否要因为新的测试将您的服务器推向硬盘交换并消耗处理器上的每个核心而使业务停顿？您是否希望由于开发人员在缩放实验中做出了复杂的分叉炸弹而导致测试停顿了？您是否希望由于开发人员的麻线和胶带而使您认为有效的代码在生产中运行？您是否要让开发人员使用可能敏感的生产数据（我知道这并不是所有企业都关心的问题，但是在许多企业中都是如此）？

是什么阻止了这些问题的发生？

单独的环境。

那你需要什么

您需要单独的环境。

正式地说

出于以下原因，您需要单独的环境：

• 降低阻碍业务和软件开发的风险。
• 降低由于开发人员的临时操纵而将代码投入通过测试的生产风险。
• 降低生产数据被错误处理的风险（当组织处理敏感数据（如ID号以及财务和健康信息）时非常重要）或与测试数据混合或销毁的风险非常重要。

根据您的情况，一个新技术平台

也许这还不是真正的生产环境（因为它是一个相对较新的平台），但是当企业开始依赖它时，您将获得单独的环境，并且他们要么明智地预见风险，要么通过刻苦学习来意识到办法。

我听说最佳实践是拥有单独的开发，测试和生产环境，但是为什么会这样呢？

这些天不是那么明确。

许多地方不再进行手动测试，因此本身没有测试数据。许多地方的规模如此之大，以至于由于成本他们无法复制其生产环境。特别是随着微服务的爆炸性增长，使快速变化的环境保持足够的同步以确保在QA环境中进行的测试能够准确地复制事物以捕获将在生产中出现的错误变得具有挑战性。

为什么我们要有单独的开发，测试和生产环境？

• 如果让用户看到您的测试数据将是非常糟糕的。
• 如果让开发人员/测试人员看到您的产品数据，那将是非常糟糕的。
• 如果您不相信您的开发人员不会严重破坏自己的东西，那么您将无法迅速解决这种情况。
• 如果您拥有自动配置项，从而可以快速轻松地进行代码推广。

本质上，如果具有环境的成本小于成本不具有环境。

主要（也是最明显的）原因是您永远不想混合测试和生产数据。对于系统用户和开发人员而言，这都可能很快使他们感到困惑。在管理质量保证和单元测试（应该做的）时，需要确保它们处于完全隔离的环境中。如果在您的开发环境或质量检查中发生爆炸，将对生产产生负面影响，从而影响实际用户及其重要数据！您绝对不希望这样影响生产！

这扩展到您在日常工作中应使用的常规服务，例如版本控制。如果您要控制的代码在实时环境中，则可能无法正确利用版本控制！您的用户会发疯-如果您需要还原或回滚该怎么办？如果您犯了十五次严重错误，该怎么办？您将如何处理分支？

至少，应该将您的环境分为几个虚拟实例，但是您确实需要按照您所说的做，并为每个环境使用完全独立的实例。理想情况下是开发，质量检查，分段和生产。

所有这些最终最终不仅损害了您的前端应用程序（进而损害了您在用户中的声誉），还损害了团队的效率。

只有一个Oracle实例可用并不意味着“在开发，测试和生产环境之间没有分隔”！

您在评论中写道

我们目前对不同的项目使用不同的模式

好的，因此，通过仅将某些项目专用于开发而将某些项目专用于测试，可以通过使用不同的架构在一定程度上分隔环境。我猜您已经做到了，因为这是我不计划实例分离时唯一知道的明智方法。我无法想象您的经理如此疯狂，以至于他希望您以任意方式将开发数据，测试数据和客户数据混合在一起。他很可能只是想通过不购买第二台服务器或第二次购买许可证来省钱。

因此，您需要提出的真正问题是：

我们是否需要使用不同的实例和/或服务器来分离开发，测试和生产环境，或者架构分离是否足够？

这使得答案不像这里的其他答案那么明确。不同的模式允许不同的访问权限，因此您至少可以在一个Oracle实例内部达到某种程度的隔离。但是，您的开发人员很可能需要在“其”模式中拥有一些管理权限，因此，如果仅使用一个实例，则很难确保他们将无法访问生产数据。

此外，一台实例/一台服务器还意味着开发，测试和生产之间的共享资源-共享的用户/架构管理，共享的磁盘空间，共享的CPU，共享的网络带宽。将此与“泄漏抽象定律”结合使用，很明显，仅使用一个实例将有一定的风险，在开发，测试和生产环境之间会产生不良的副作用。

最后，您必须自己决定：您可以有效地解决该方法的缺点吗？您的应用程序是否不是资源密集型的，生产数据不是那么“机密”，以至于与“三实例/三台服务器”相比，在开发，测试和生产之间的分离级别可以降低的程度是可以容忍的方法？如果您不能以这种方式有效地工作，或者没有高风险的干扰来开始失去客户的方式来生产，那么您就有说服您的经理至少购买第二台服务器的所有理由。

您需要多种环境类型，甚至在每个环境中甚至可能需要多个服务器。

开发人员可以在开发中更新代码。该代码甚至可能不起作用-也许该应用程序甚至无法启动。

这不会影响在自己的环境中测试最新稳定版本的质量检查人员。

由于开发和质量保证部门都在更新其环境，因此生产是六个月前的最新版本，并且不受其他环境变化的影响。

在各种环境中推出的这些更改可以是代码或数据。也许质量检查人员需要测试旨在修复生产中某些不良数据的数据库脚本。脚本可能使问题变得更糟-还原数据库备份，然后重试。如果这在生产中发生，您可能会遇到非常严重的财务问题。

如果有多个版本，会发生什么？也许您正在开发2.0版，但仍需要在1.0维护分支上发布错误修复程序。现在，您需要多个开发和QA环境，以确保在发现严重错误并需要昨日修复时始终可以开发和测试任一分支。

您已经注意到没有单独环境导致的问题。在那里，您已经有了建立独立环境的根本原因：消除由在单个环境中进行开发，测试和生产操作时不可避免地发生的冲突所引起的问题。同样的道理也适用于为开发人员提供单独的沙箱，这可以防止一个开发人员的错误，甚至只是不兼容的更改都不会破坏整个开发团队。

这也是您可以向管理层提出的从单一环境转变的最佳论据：指出单一环境已经引起的问题，显示趋势线，并争辩说如果事情继续下去将迟早会出现。与为单独的环境重新配置内容相比，清理该问题（直接付出的努力以及使客户失去对公司提供服务的能力的信心）要花费更多的时间。

有许多对立的力量和动力。有很多服务器的成本和只有一台服务器的成本。我认为这个问题可能不仅仅是数据库？我可能会误解，但这确实与系统性误解有关，因为有形的成本与抽象的成本有关

通常，显而易见的成本很容易理解。

抽象成本很难量化，因此也很难理解。技术债务，错误成本，压力成本，开发人员负担，变更的影响，回归测试，停机时间的影响等难以解释。

不同的环境 环境通常出于数据和/或目的而分开。每个环境都有不同的功能。系统的变化率，即 会考虑更新频率，更改的种类和影响。

我们使用不同的环境来简化变更。

我们使用不同的环境，因此我们提供了未改变的环境的鲁棒性和确定性。

我们使用环境来考虑变更的影响。

我们使用环境来减少变更所涉及的成本。

测试和稳定系统的成本很高。 您创建环境以确保对稳定环境所做的投资。

您的团队规模绝对不小，无法坚持实用，节省成本，勤奋可靠的流程模式。

使用一种环境进行所有操作就像将所有照片存储在一个硬盘上一样，虽然可以做到，但您会后悔。

有些人需要证明 我在很多情况下都曾与客户或其他人打交道，他们不欣赏确保健壮性和遵循最佳实践的成本。我建议您汇总一些明确定义成本的实际案例。