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