Именованные файлы конфигурации - горячие или нет? - PullRequest
Новая
       7

Именованные файлы конфигурации - горячие или нет?

1 голос
/ 27 июня 2011

Я выбрал решение для нашего процесса файла конфигурации и должен его обосновать.Я был бы признателен за понимание и критику.Спасибо!

Проблема: У наших веб-приложений есть один файл application.cfm, содержащий переменные и условия 

<cfif url = "*dev*" or "jargon123">
    this is a dev enviroment, do devy things
</cfif>

Так что новый разработчик приложения развернет локальный экземпляр.Зажги его и начинай ковыряться.Проблема в том, что файл конфигурации содержит производственные значения.Он начинает получать производственные данные и отправлять производственные электронные письма.Кроме того, поскольку URL-адрес, по которому они попадают, равен http://App_name:PORT или http://localhost - условия dev никогда не устанавливаются.Так что в dev происходит больше производственного материала.

Что хотят другие сотрудники:

  • Оператор Switch.В app.cfm будет задана переменная окружения «development», а затем объявлены общие переменные.Затем он перейдет в оператор switch и объявит переменные, специфичные для среды.Я не согласен с этим методом, так как некоторые из наших конфигурационных файлов имеют 100 - 250 строк.Это может быть массивным оператором Switch, который я не хочу обыгрывать.

Мое выбранное решение:

  • App.cfm былудален и удален из контроля версий.Теперь у нас есть несколько файлов Applicaiton.Enviroment.cfm, то есть Applicaiton.Prod.cfm, Application.Dev.cfm, Applicaiton.MyName.cfm и т. Д. Этот файл содержит все данные, относящиеся к среде.Я переместил специфичные для Производства настройки из условных выражений в App.Prod.cfm.Развертывания в новых средах теперь 1. Дублируйте App.Dev.cfm как App.Me.cfm и подтвердите.2. Обновите все переменные до моих личных данных (адрес электронной почты, логин и т. Д.) 3. Дублируйте App.me.cfm как App.cfm и используйте для файла конфигурации.

Я не буду вдаваться в причинуЯ не делаю другие решения, но вот моя причина для моих решений:

  • Вынуждает инженера по развертыванию выбрать правильный файл конфигурации для среды.Приложение не будет работать без app.cfm
  • Ограничивает вероятность ошибки пользователя.Сценарий - это то, что пользователь копирует данные в новый режим среды и случайно копирует производственный контент.
  • С ним проще и проще работать - значения конфигурации полностью отделены друг от друга.

Я нашел много статей о работе с конкретными конфигурационными файлами, но не о том, почему они лучше.Это мотивация этого поста.

Ответы [ 2 ]

1 голос
/ 28 июня 2011

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

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

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

Это сильные «плюсы» для отдельных файлов конфигурации - они перевешивают второстепенный «минус»: вы должны определить, где находится файл конфигурации по тому или иному механизму. Это может быть через переменную окружения или через параметр командной строки, с подходящим значением по умолчанию, если ни один не указан. Командная строка должна переопределять окружение.

1 голос
/ 27 июня 2011

Я бы также удалил производственный конфиг и предоставил только разрабатываемые версии конфигурационного файла. Причины:

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