Производство против конфигурации QA

Question

Снова и снова я сталкиваюсь с проблемой наличия нескольких сред, которые должны быть настроены индивидуально для приложения, которое будет работать во всех из них (например, QA, региональные производственные среды, dev, staging и т. Д.), И мне интересно Каков наилучший способ организации различных конфигураций?

Будет ли это в базе данных? Разные конфигурационные файлы для каждой среды? Или, может быть, один и тот же файл с разными разделами / тегами XML? Как они будут тогда развернуты? Встроено в приложение? Или положить вручную после установки, чтобы изменить на месте?

Этот вопрос не относится к конкретной технологии - я работал с .net и Java, веб-приложениями и настольными приложениями, и эта проблема возникает снова и снова. Я хочу изучить различные подходы, чтобы, возможно, адаптировать гибрид для решения этой проблемы.

РЕДАКТИРОВАТЬ: я должен отметить одно предостережение: когда конфигурация является частью развернутого решения, она обычно устанавливается на хосте под пользователем root. В крупных организациях разработчики обычно не имеют корневого доступа к рабочим хостам, поэтому любые изменения в конфигурации требуют новой сборки и развертывания. Излишне говорить, что это не самый хороший подход - особенно в организациях, где очень строгий процесс выпуска с участием нескольких команд и уровней одобрения ... ( вздох Я знаю!)

Answer 1

Заимствованные из книги Джеза Хамбла и Дэвида Фарли " Непрерывная доставка (стр. 41) ", вы можете:

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

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

По моему опыту, вы можете запекать все файлы конфигурации для каждой среды (кроме конфиденциальной информации) в файл развертывания (war, jar, zip и т. Д.). Кроме того, вы разрабатываете свое приложение так, чтобы при запуске оно получало дополнительный параметр, чтобы выбрать правильные наборы файлов конфигурации (из вашего извлеченного файла развертывания или из локальной / удаленной файловой системы, если они чувствительны, или из базы данных) во время запуска приложения. .

Answer 2

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

Я не знаком с .net, но с java популярным подходом является настройка maven с различными профилями . Каждый профиль специфичен для конкретной среды. Затем вы можете определить различные файлы свойств, которые имеют специфические для среды значения, например, из приведенной выше ссылки:

• environment.properties - это конфигурация по умолчанию, которая по умолчанию будет упакована в артефакт.
• environment.test.properties - это вариант для тестовой среды.
• environment.prod.properties - Это в основном то же самое, что и тестовый вариант, и будет использоваться в производственной среде.

Затем вы можете построить свой проект следующим образом:

mvn -Pprod package

Answer 3

У меня хорошие и плохие новости.

Хорошей новостью является то, что Config4 * (из которого я являюсь сопровождающим) аккуратно решает эту проблему благодаря поддержке адаптивной конфигурации . По сути, это возможность файла конфигурации адаптироваться к среде (включая имя хоста, имя пользователя, переменные среды и параметры командной строки), в которой он работает. Прочитайте главу 2 руководства «Приступая к работе» для получения подробной информации. Не волнуйтесь: это короткая глава.

Плохая новость заключается в том, что в настоящее время реализации Config4 * существуют только для C ++ и Java, поэтому вашим .Net-приложениям не повезло. И даже с приложениями на C ++ и Java прагматичный смысл не будет превращать Config4 * в существующее приложение. Из-за этого я бы посоветовал использовать Config4 * только в новых приложениях.

Несмотря на плохие новости, я думаю, что вам стоит прочитать вышеупомянутую главу документации Config4 *, поскольку это может дать вам идеи, которые вы можете адаптировать под свои нужды.