Разработка программного обеспечения — это путешествие, которое проходит через разные среды, каждая среда изолирована, что помогает эффективно разрабатывать программное обеспечение. Эта изоляция также помогает командам выполнять свою работу независимо. Если у нас есть три команды разработки, тестирования и создания контента с помощью изолированной среды, каждая команда может работать независимо и может достичь коллективной цели доставки программного обеспечения.
Каждая среда поставляется со своей собственной базой данных точек доступа, серверами API, уровнем ведения журнала, учетными данными и т. д. Вся эта информация называется конфигурациями, а управление всей этой информацией называется управлением конфигурацией.
Хорошо сконфигурированный проект помогает команде поддерживать проект на этапе обслуживания и проводить гибкую разработку, не нарушая существующие функции, которые создают позитивную среду в команде для создания новых функций без каких-либо опасений. Когда код не настраивается, а добавление новой функции требует значительных изменений в существующей кодовой базе, это всегда приводило к некоторым новым ошибкам, и команда боялась разрабатывать новые функции.
Каждое конфигурируемое программное обеспечение должно иметь четыре эмпирических правила для конфигураций.
Гибкость
Безопасность
Детальность
Разделение конфигурации
Гибкость
В большинстве случаев задача управления конфигурацией переносится на панель команды Dev-Ops, что приводит к зависимости разработки. Конфигурация должна быть достаточно гибкой, чтобы разработчик мог изменить ее, запустить и воспроизвести проблему в среде разработки.
Безопасность
Управление конфигурацией должно быть безопасным, закрытые ключи и учетные данные не должны передаваться в репозиторий, чтобы избежать несанкционированного доступа к системе.
Подробность
Конфигурация должна быть подробной и не должна повторяться снова и снова для каждой среды. Обычный подход для этого — начать с базового файла конфигурации и переопределить значения в зависимости от среды.
Разделение конфигурации
Отделение конфигурации от кода является хорошим подходом и общей передовой практикой, работа по управлению конфигурацией может быть отделена как отдельный процесс и имеет слабую связь с кодовой базой и могут поддерживаться индивидуально, не касаясь кода.
При таком подходе мы ввели большую часть конфигурации в качестве переменной среды, и приложение получает доступ к этим переменным для запуска программного обеспечения в соответствии со средой.
Верно и то, что полное разделение конфигурации невозможно, поэтому мы используем смешанный подход Separation of Configuration as much as possible + load configuration based on environment variable.
Git клонирует это репо - https://github.com/vinaymavi/node-js-configuration-management-.git
Это простой пример сервера express.js, который загрузит конфигурацию в соответствии с предоставленным environment и запустит сервер.
Папка src/config/ содержит все файлы конфигурации. этот модуль конфигурации имеет базовый файл конфигурации
два других файла
и
для обновления конфигурации в соответствии со средой.
src/config/index.js файл модуля прочитан environment variable
из процесса и возвращает конфигурацию в соответствии с ним. по умолчанию сервер работает в режиме development
$ node index.js
и вернуть весь файл конфигурации в качестве ответа.
Мы можем изменить среду с помощью переменной среды export ENV=PROD, теперь тот же сервер работает с конфигурацией prod.
$ node index.js
мы можем установить переменные среды в файле .env.
этот подход обеспечивает разделение конфигурации путем установки переменной среды в соответствии с средой, теперь наше приложение будет работать в соответствии с средой, при условии, что переменная среды не требует изменения какого-либо кода в соответствии с средой.
У нас есть dotenv модуль https://www.npmjs.com/package/dotenv , который автоматически загружает .env файл и устанавливает все предоставляемые переменные в среду.
$ yarn add dotenv
добавить require(‘dotenv’).config() поверх файла сервера index.js
