我们正在开发一个带有spring框架的项目。我们正在使用一个 tomcat 集群，为了进行一些真正高级的集成测试，我们向 Web 应用程序添加了一些控制器，这些控制器允许一些不能进入生产的有风险的东西。
我们学到的是，为了做到这一点，我们可以使用弹簧配置文件并注释有风险的控制器，就像使用
@profile("Staging")
此注释确保仅当活动配置文件为“Staging”时才会创建 bean。
叫我偏执狂，但这个有风险的代码现在驻留在我们的 svn 上，并且是项目代码的一部分。似乎最轻微的错误可能导致此代码成为生产的一部分，并允许利用者采取冒险行动。
此外，如果某些程序员忘记注释代码，肯定会到达生产环境。我们都会犯错。
这个问题有什么缓解措施吗？
您所说的错误是添加staging到活动配置文件列表中。是的，这很容易做到。但是很容易从文件系统中删除文件格式化硬盘并关闭电源。所以，你的问题听起来真的是一种偏执狂...... :)
我认为问题不在于 Spring 配置文件，而在于您的开发方法。如果您在某些代码中不确定，则根本不应该在生产中。如何做到这一点？从 svn 移动到 git。并开始使用分支。每个任务都是一个分支。无一例外。每个任务都必须经过测试。因此，您可以部署要暂存的每个分支，对其进行测试，并在确定代码正常时将其合并/重新设置为 master。Master 也应该经过测试，然后才能部署到生产环境中。
在这种情况下，您不需要配置文件“登台”。
我会说你有点偏执。（眨眼）希望您的应用程序中也有集成测试，并且它们通常会设置一些环境 - 如果它们曾经在生产环境中运行，它们可能会搞砸您的数据库，将消息发送到其他系统等。你这个不用担心。为什么？也许你可以使用这个答案来回答你应该如何打包那些有风险的代码。
我的建议：将所有有风险的代码保存在一个模块中（如果您使用的是多模块构建）。不要在生产版本中包含这个模块（你可以使用 maven 配置文件）
或者..让代码自行检查是否允许运行。也许它可以检查您仅在测试环境中创建的文件系统上是否存在某个文件。
这真的取决于你担心什么。
但考虑一下是件好事。我知道负载测试导致许多订单被放置在实际（外部）订单处理系统中的故事。