Я реализовал Spring Cloud Config Server, но я пытаюсь понять, как реализовать структуру и метки репозитория, чтобы:
- Поддержка конфигураций версионных свойств для конвейера CI / CD
- Удалите зависимость между версией приложения и версией свойств.
- Разрешить динамические c обновления конфигурации без выполнения новой версии приложения
- Разрешить конфигурации общих свойств, которые используются многими приложениями, но управляют версиями отдельно от свойств приложения c.
В моем ПО c я реализовал структуру следующим образом. (В настоящее время мы используем SVN, но я не хотел ограничивать какие-либо решения используемым SCM) :
trunk
- application.properties (common properties file)
- application-{profile}.properties (common properties file)
- spring.application.name
- {spring.application.name}-{profile}.properties
Это, однако, не использует никаких версий.
Я посмотрел на это, но на самом деле оно не предлагает решения, поскольку версия свойства жестко связана с версией приложения через версию / метку, указанную в файле приложения bootstrap. Управление версиями свойств с помощью Spring Cloud Config
Перед реализацией конфигурации Cloud мы храним наши свойства в наших проектах приложений с различными профилями для разных сред, и мы изменяем наши свойства как часть изменения нашего кода. Похоже, это очень похоже на предложение в ссылке, поскольку свойства и логики приложения c связаны между собой через выпущенный файл bootstrap и, по сути, один и тот же пакет выпуска. Но тогда мы не получим преимущество в том, что можем вносить sh только изменения конфигурации приложений без полного выпуска, и мы создали еще одну точку отказа, представив сервер облачной конфигурации.
Некоторые идеи У меня были:
- Чтобы использовать сервер конфигурации только как дельта / переопределение, которое мы можем использовать, чтобы pu sh любые изменения в приложениях, не делая полной версии. Например, сохраняйте конфигурацию в проекте приложения, но просто используйте сервер конфигурации для переопределения этих значений. Это, кажется, упускает момент реализации сервера конфигурации
- Другой целью было всегда выпускать приложения, указывающие на одну и ту же " stati c branch " свойства, а затем некоторые, как объединить свойства выпуска в эту ветку как часть развертывания, но это кажется неправильным, сложным и, вероятно, неправильным go.
После некоторой дополнительной мысли, возможно, мы сможем Относитесь к этому так, как если бы мы выпускали код нашего приложения, в котором SCM имеет теги и ветви, которые создают артефакт, который затем развертывается в других средах.
application
- trunk
- {spring.application.name}.properties
- {spring.application.name}-{profile}.properties
- tag
- {spring.application.name}.properties
- {spring.application.name}-{profile}.properties
- branch
- {spring.application.name}.properties
- {spring.application.name}-{profile}.properties
common-properties
- trunk
- application.properties (common properties file)
- application-{profile}.properties (common properties file)
- tag
- application.properties (common properties file)
- application-{profile}.properties (common properties file)
- branch
- application.properties (common properties file)
- application-{profile}.properties (common properties file)
Затем у нас есть другие папки репо на самом деле он содержит {environment}/active «освобожденные» конфигурации, которые мы можем настроить для каждой среды, определяющей c облачный конфигурационный сервер. Затем мы добавим sh свойства к этому, когда мы хотим отменить любые изменения:
{environment}/active
- application.properties (common properties file)
- application-{profile}.properties (common properties file)
- spring.application.name
- {spring.application.name}-{profile}.properties
Есть ли более простой способ справиться с этим?