🤷‍♂️ Рубрика вопрос-ответ.

Q: Есть в проекте app.env, там штук 15-20 параметров. Чтобы не хранить их в репе, куда их лучше вынести ? Хотел в Teamcity через параметры сборки, но меня смутило их кол-во там такая простыня будет из параметров.

A: Eсли следовать лучшим практикам, то их в любом случае надо выносить, но есть нюансы, а именно что это за параметры? если речь идет о веб приложении например, то все параметры, которые приложению нужны для работы можно разбить на 3 группы:

- параметры рантайма (то что нужно приложению в рантайме для работы не связанной с бизнес логикой, например конфигурация пула конекшенов к базе данных, или конфигурация фреймворка, на котором запускается приложение, и т.д). такие параметры можно сетить как переменные окружения, это довольно удобно. эти параметры версионируются с кодом приложения в системе контроля версий, например прописаны в docker-compose файле.

- параметры на уровне логики приложения (то что нужно для работы бизнес логики, например конфигурация таймаутов, если приложение куда-то обращается, какие-то дефолтные значения для констант, используемых в бизес логике, и так далее). такие параметры технически тоже можно сетить как переменные окружения, но это не удобно, и лучше всего для этих целей подходит конфиг файл, который тоже версионируется вместе с кодом приложения в системе контроля версий и деплоится каждый раз, когда деплоится само приложение. почему неудобно их сетить в переменные окружения - потому что там уже лежат рантайм параметры из пункта 1 и получится каша из параметров в окружении и в долгосрочной поддержке приложения это неудобно, поэтому можно и нужно разделять (мухи отдельно, котлеты отдельно).

- параметры, которые являются секретами (логины, пароли от базы, токены от внешних API сервисов и прочее). лучшая практика это не сетить их как переменные окружения и не хранить в том же файле, что и конфигурационные параметры бизнес логики из пункта 2, а вместо этого, хранить их отдельном файле. по поводу версионирования секретов, то в системе контроля версий можно хранить только заглушку файла, то есть например если это json, то все значения должны быть заглушками типа "db_password": "***". это нужно для удобства разработки как таковой. но это - отдельный файл - только если секреты будут храниться локально рядом с приложением, а если использовать внешний менеджер (хранилище) секретов, то там как правило провайдер этого менеджера предоставляет утилиту, которая умеет доставать секреты из этого хранилища, и возвращать как строку к примеру, и тогда разработчики уже пишут приложение таким образом, что секреты не вычитываются из файла, а запрачиваются через утилиту или SDK, предоставляемые провайдером хранилища.

#вопросответ