История изменений
Исправление paddlewan, (текущая версия) :
Только хотел про 12-factor написать. Но это больше про backend приложения (хотя, как мне показалось, вопрошающий отчасти про них и спрашивал).
Что касается практик: да нет тут никаких правил. Если целишься сделать сервис - лучше придерживаться 12-factor и ожидать, что тебя запустят в Docker, то есть файла конфига в виде файла лучше не иметь вообще, если это возможно, либо, как минимум уметь переписываеть его из энвов.
Если юзверьское приложение делать - то нужны sane defaults, которые работают без конфига вообще, а также желательно, чтобы приложение могло сгенерировать дефолтный конфиг само. А так - XGD_CONFIG_HOME/appname/file - и вот тут и хозяйничай.
Если cli-приложуха, то в идеале бы ей уметь генерировать completions для разных оболочек.
Что касается репозитория:
- Держать пример конфига прямо в репозитории - отличная идея (главное не закоммитить секреты, хотя есть и практика хранения зашифрованных секретов для разных окружения прямо в репозитории с кодом, если что).
- Держать тесты в репозитории - отличная идея. Так и запустить их быстрее и CI проще настроить, и видно, что ОНИ ЕСТЬ :) Иногда тесты могут подсказать что-то о работе приложения читающему код.
И общий совет - можно побродить по github и посмотреть, у кого как сделано…
Исходная версия paddlewan, :
Только хотел про 12-factor написать. Но это больше про backend приложения (хотя, как мне показалось, вопрошающий отчасти про них и спрашивал).
Что касается практик: да нет тут никаких правил. Если целишься сделать сервис - лучше придерживаться 12-factor и ожидать, что тебя запустят в Docker, то есть файла конфига в виде файла лучше не иметь вообще, если это возможно, либо, как минимум уметь переписываеть его из энвов.
Если юзверьское приложение делать - то нужны sane defaults, которые работают без конфига вообще, а также желательно, чтобы приложение могло сгенерировать дефолтный конфиг само. А так - XGD_CONFIG_HOME//file - и вот тут и хозяйничай.
Если cli-приложуха, то в идеале бы ей уметь генерировать completions для разных оболочек.
Что касается репозитория:
- Держать пример конфига прямо в репозитории - отличная идея (главное не закоммитить секреты, хотя есть и практика хранения зашифрованных секретов для разных окружения прямо в репозитории с кодом, если что).
- Держать тесты в репозитории - отличная идея. Так и запустить их быстрее и CI проще настроить, и видно, что ОНИ ЕСТЬ :) Иногда тесты могут подсказать что-то о работе приложения читающему код.
И общий совет - можно побродить по github и посмотреть, у кого как сделано…