Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Так и не понял, как здесь обходится тот факт, что при работе с проектом нужны разные конфигурации на разных машинах.
Это может быть как параметр при старте процесса, какой именно файл конфигурации брать из репозитария. Либо в случае сложного решения должен быть некоторый bootstrap скрипт сборки конфигурации который точно так же должен храниться в git репозитарии.
В случае отдельных конфигураций для разных типов приложения (dev, test, uat, prod) или переопределение одного «суперконфига» в каждом процессе каждого узла сети.
Если я слишком абстрактно описал подход, могу на примерах показать как это можно решить.
В случае отдельных конфигураций для разных типов приложения (dev, test, uat, prod) или переопределение одного «суперконфига» в каждом процессе каждого узла сети.
Если я слишком абстрактно описал подход, могу на примерах показать как это можно решить.
У нас используется такой подход:
в репозитории есть 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 и вбивает в полученный файл свои данные.
Как такое сделать при вашем методе? Да, без примеров, если честно, тяжеловато.
Как пример для случая отдельных конфигураций для разных типов приложения (dev, test, uat, prod)
def envName = System.getenv("environment_name")
println gitConfigurationHelper.getFileContent('master',"settings-$envName.json")
Обычно, все гораздо сильнее усложняется в больших организациях на больших распределенных проектах. Конфигурация получается «многомерной». Например:
Деление по 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 тоже пробовали.
Согласен, что конфигурация может быть достаточно сложной и динамической. В один прекрасный момент сложность конфигурирования может стать такой, что template engine не спасет и нужны динамически вычисляемые значения. Так не проще ли использовать динамическую конфигурацию на основе скриптового языка: groovy, javascript, lua… !?
Git — лишь как слой для хранения конфигурации, предлагающий много возможностей, готовых инструментов и знакомый разработчикам!
Можно хранить конфигурацию в etcd, zookeeper… fabric8.io в итоге ушли с zookeeper на git
Git — лишь как слой для хранения конфигурации, предлагающий много возможностей, готовых инструментов и знакомый разработчикам!
Можно хранить конфигурацию в etcd, zookeeper… fabric8.io в итоге ушли с zookeeper на git
Когда приходит новый разработчик, он делает cp application.properties.example application.properties и вбивает в полученный файл свои данные.
Если конфигурация специфична для каждого пользователя, то fork, правка, commit и push
Ужас какой
Примечательно, что конфигурация берется без авторизации, что значит, что проект публичный.
Ах, как здорово, когда конфигурации доступны всем. А пароли к базе тоже там, или здесь только те конфигурации, что на поведение влияют и у вас вместо одного места с конфигами стало два?
Ах, как здорово, когда конфигурации доступны всем. А пароли к базе тоже там, или здесь только те конфигурации, что на поведение влияют и у вас вместо одного места с конфигами стало два?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конфигурация приложений с помощью github