我可能在这里遗漏了一些东西，但是什么是属性版本控制的好解决方案？
例如，在属性值更改的蓝绿部署场景中（旧应用版本使用旧值，新版本需要新值），如何确保应用的两个版本能够成功共存（考虑潜在的重启和回滚）？
一种选择是为需要应用新值的属性创建新的属性名称。当然，这不是一个好的选择，因为我们需要在代码库中跟踪该属性的所有用法并相应地更新其引用。从概念的角度来看，这也不是很好。
另一种选择是为每个版本创建一个分支。虽然这在这种情况下可以很好地工作，但我设想了一个分支/标签地狱，因为我们将配置存储库扩展到多个应用程序，并且它们各自的分支演变为不同的方向。
分支地狱的解决方案是为每个应用程序设置一个单独的配置存储库。但是，我相信这在某种意义上违背了配置服务器的目的，因为它增加了开销。
还有其他方法吗？
Spring Cloud Config 的Environment资源由三个变量参数化：
{application}映射到spring.application.name客户端{profile}映射到spring.active.profiles客户端{label}这是一个服务器端功能，用于标记一组版本化的配置文件。由于在蓝绿部署的情况下，您在同一个配置文件中使用同一个应用程序，最好的选择是通过使用 git Tags来使用版本化配置文件。
基本思想是为不同版本的配置文件创建标签，并告诉您的应用程序使用与spring.cloud.config.label您的bootstrap.properties.
例如，您可以使用v1.0and标记两个不同的提交v2.0：
并spring.cloud.config.label=v1.0用于旧实例和spring.cloud.config.label=v2.0新实例。
当我们扩展到多个应用程序的配置存储库时，它们各自的分支会演变成不同的方向。
为了避免这个问题，我建议只在application-{profile}.properties配置文件中保存通用和跨应用程序属性。更好的方法是每个应用程序都有自己的配置文件，例如recommender.properties推荐服务和search.properties搜索服务。然后，您可以通过定义适当的spring.application.name. 通过这种方式，您可以在配置文件中实现某种程度的单一职责原则。