Comments 11
Так и не понял, как здесь обходится тот факт, что при работе с проектом нужны разные конфигурации на разных машинах.
+1
Это может быть как параметр при старте процесса, какой именно файл конфигурации брать из репозитария. Либо в случае сложного решения должен быть некоторый bootstrap скрипт сборки конфигурации который точно так же должен храниться в git репозитарии.
В случае отдельных конфигураций для разных типов приложения (dev, test, uat, prod) или переопределение одного «суперконфига» в каждом процессе каждого узла сети.
Если я слишком абстрактно описал подход, могу на примерах показать как это можно решить.
В случае отдельных конфигураций для разных типов приложения (dev, test, uat, prod) или переопределение одного «суперконфига» в каждом процессе каждого узла сети.
Если я слишком абстрактно описал подход, могу на примерах показать как это можно решить.
+1
У нас используется такой подход:
в репозитории есть application.properties.example со строками вида:
database.url=postresql/блабла
database.username=я
сам application.properties, естественно, заигнорен
Когда приходит новый разработчик, он делает cp application.properties.example application.properties и вбивает в полученный файл свои данные.
Как такое сделать при вашем методе? Да, без примеров, если честно, тяжеловато.
в репозитории есть application.properties.example со строками вида:
database.url=postresql/блабла
database.username=я
сам application.properties, естественно, заигнорен
Когда приходит новый разработчик, он делает cp application.properties.example application.properties и вбивает в полученный файл свои данные.
Как такое сделать при вашем методе? Да, без примеров, если честно, тяжеловато.
0
Как пример для случая отдельных конфигураций для разных типов приложения (dev, test, uat, prod)
def envName = System.getenv("environment_name")
println gitConfigurationHelper.getFileContent('master',"settings-$envName.json")
0
Обычно, все гораздо сильнее усложняется в больших организациях на больших распределенных проектах. Конфигурация получается «многомерной». Например:
Деление по environment: dev, qa, uat, prod
Деление по регионам: eu, us, asia, etc…
Деление по разработчикам внутри dev: mike, john, etc
Деление по версиям системы (если несколько версий могут быть активны одновременно)
Деление по клиентам, и т.д.
В результате часто получается вложенная структура папок со сложными правилами выбора конфигов и применением template engine на этапе сборки/деплоймента. Пока не было найдено инструмента, позволяющего легко управлять всем этим зоопарком. Git тоже пробовали.
Деление по environment: dev, qa, uat, prod
Деление по регионам: eu, us, asia, etc…
Деление по разработчикам внутри dev: mike, john, etc
Деление по версиям системы (если несколько версий могут быть активны одновременно)
Деление по клиентам, и т.д.
В результате часто получается вложенная структура папок со сложными правилами выбора конфигов и применением template engine на этапе сборки/деплоймента. Пока не было найдено инструмента, позволяющего легко управлять всем этим зоопарком. Git тоже пробовали.
0
Согласен, что конфигурация может быть достаточно сложной и динамической. В один прекрасный момент сложность конфигурирования может стать такой, что template engine не спасет и нужны динамически вычисляемые значения. Так не проще ли использовать динамическую конфигурацию на основе скриптового языка: groovy, javascript, lua… !?
Git — лишь как слой для хранения конфигурации, предлагающий много возможностей, готовых инструментов и знакомый разработчикам!
Можно хранить конфигурацию в etcd, zookeeper… fabric8.io в итоге ушли с zookeeper на git
Git — лишь как слой для хранения конфигурации, предлагающий много возможностей, готовых инструментов и знакомый разработчикам!
Можно хранить конфигурацию в etcd, zookeeper… fabric8.io в итоге ушли с zookeeper на git
0
Когда приходит новый разработчик, он делает cp application.properties.example application.properties и вбивает в полученный файл свои данные.
Если конфигурация специфична для каждого пользователя, то fork, правка, commit и push
0
Ужас какой
+2
Примечательно, что конфигурация берется без авторизации, что значит, что проект публичный.
Ах, как здорово, когда конфигурации доступны всем. А пароли к базе тоже там, или здесь только те конфигурации, что на поведение влияют и у вас вместо одного места с конфигами стало два?
Ах, как здорово, когда конфигурации доступны всем. А пароли к базе тоже там, или здесь только те конфигурации, что на поведение влияют и у вас вместо одного места с конфигами стало два?
0
Sign up to leave a comment.
Конфигурация приложений с помощью github