Конфигурация приложений с помощью github

[Fen1kz]

Так и не понял, как здесь обходится тот факт, что при работе с проектом нужны разные конфигурации на разных машинах.

[igor_suhorukov]

Это может быть как параметр при старте процесса, какой именно файл конфигурации брать из репозитария. Либо в случае сложного решения должен быть некоторый bootstrap скрипт сборки конфигурации который точно так же должен храниться в git репозитарии.

В случае отдельных конфигураций для разных типов приложения (dev, test, uat, prod) или переопределение одного «суперконфига» в каждом процессе каждого узла сети.

Если я слишком абстрактно описал подход, могу на примерах показать как это можно решить.

[Fen1kz]

У нас используется такой подход:
в репозитории есть application.properties.example со строками вида:
database.url=postresql/блабла
database.username=я

сам application.properties, естественно, заигнорен

Когда приходит новый разработчик, он делает cp application.properties.example application.properties и вбивает в полученный файл свои данные.

Как такое сделать при вашем методе? Да, без примеров, если честно, тяжеловато.

[igor_suhorukov]

Как пример для случая отдельных конфигураций для разных типов приложения (dev, test, uat, prod)

def envName = System.getenv("environment_name")
println gitConfigurationHelper.getFileContent('master',"settings-$envName.json")

[intenter]

Обычно, все гораздо сильнее усложняется в больших организациях на больших распределенных проектах. Конфигурация получается «многомерной». Например:
Деление по environment: dev, qa, uat, prod
Деление по регионам: eu, us, asia, etc…
Деление по разработчикам внутри dev: mike, john, etc
Деление по версиям системы (если несколько версий могут быть активны одновременно)
Деление по клиентам, и т.д.

В результате часто получается вложенная структура папок со сложными правилами выбора конфигов и применением template engine на этапе сборки/деплоймента. Пока не было найдено инструмента, позволяющего легко управлять всем этим зоопарком. Git тоже пробовали.

[igor_suhorukov]

Согласен, что конфигурация может быть достаточно сложной и динамической. В один прекрасный момент сложность конфигурирования может стать такой, что template engine не спасет и нужны динамически вычисляемые значения. Так не проще ли использовать динамическую конфигурацию на основе скриптового языка: groovy, javascript, lua… !?

Git — лишь как слой для хранения конфигурации, предлагающий много возможностей, готовых инструментов и знакомый разработчикам!
Можно хранить конфигурацию в etcd, zookeeper… fabric8.io в итоге ушли с zookeeper на git

[igor_suhorukov]

Когда приходит новый разработчик, он делает cp application.properties.example application.properties и вбивает в полученный файл свои данные.

Если конфигурация специфична для каждого пользователя, то fork, правка, commit и push

[reality]

Ужас какой

[igor_suhorukov]

Где ужас?) Можно подробности?

[M_Muzafarov]

Примечательно, что конфигурация берется без авторизации, что значит, что проект публичный.
Ах, как здорово, когда конфигурации доступны всем. А пароли к базе тоже там, или здесь только те конфигурации, что на поведение влияют и у вас вместо одного места с конфигами стало два?

[igor_suhorukov]

Это лишь пример. Можно настроить и аутентификацию.
Хранить пароли в конфигурации не зашифрованном виде — моветон. Любой аудит порвет за такое как тузик грелку