Как различать тестовые и производственные свойства в приложении?

Мы разрабатываем большое решение для электронной продажи J2ee. Он получил множество интеграций: CMS, ERP, почтовый сервер и т.д. Все эти системы разделены на тестовые и производственные среды.

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

То, что мы пробовали до сих пор, следующее:

Все наши файлы свойств содержат тестовые свойства и производственные свойства

test.mvxapi.server = SERV100TS
test.mvxapi.username = user
test.mvxapi.password = password
test.mvxapi.port = 6006
test.mvxapi.cono = 600

mvxapi.server = SERV10001
mvxapi.username = user
mvxapi.password = password
mvxapi.port = 6001
mvxapi.cono = 100

Утилита, которая считывает эти свойства, имеет переключатель: isTest(), который префикс ключа "test".

public String getProperty(String property)
{
    return properties.getProperty(prefix + "" + property);
}

Переключатель устанавливается другим свойством, созданным нашим сервером сборки. Когда .EAR построен, script для наших производственных серверов внедряет (input to build.xml) "isProduction = true" в system.properties.

<propertyfile file="${buildDir}/system.properties">
        <entry  key="isProduction" value="${systemType}"/>
    </propertyfile>

Я не уверен, что это лучший способ сделать это. Если по какой-либо причине "isProduction = false" ошибочно совершается в нашей производственной среде, весь ад свободен.

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

Ответ 1

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

Скорее развертывайте один и тот же EAR на каждом сервере, но настройте каждый сервер с другим ресурсом URL. iow, добавьте ресурс URL JNDI для всех серверов, которые вы развертываете для этой точки, в файл конфигурации для этого ресурса. Если у вас есть только доступ SVN к вашему репо, тогда создайте файлы конфигурации в репозитории svn или любое репо, к которому вы можете получить доступ через URL-адрес. Холодная вещь здесь в том, что вся ваша конфигурация централизована и, таким образом, управление ими легко.

Что я сделал (путем настройки с помощью spring), убедитесь, что ресурс JNDI URL необязателен. Итак, если он там, приложение будет использовать его, если нет, это не произойдет. Приложение запускает его там или нет. Таким образом, даже при работе без ресурса JNDI, приложение все еще работает (например, среда разработки).

Ответ 2

Вы развертываете EAR? Затем добавьте свойства, необходимые в JNDI.

Ответ 3

Я не могу сказать, что это лучший способ, однако, что мы делаем, это клиентская и серверная банка, в которой есть свойства. Затем мы включаем эти банки в файл EAR. Таким образом, во время нашего процесса сборки мы включаем соответствующие (QA, TEST, PROD) банки для среды, в которой мы развертываем.

Недостатком является то, что нам нужно управлять тремя наборами флагов среды, и команда сборки должна быть осторожна, чтобы не развернуть неправильный. На самом деле, однажды это произошло, когда у нас была платформа PROD, развернутая в нашей среде QA, и данные QA начали внедряться... да, что сосало и было основным беспорядком для очистки.

Я буду смотреть эту дискуссию, потому что часто задаюсь вопросом, как сделать этот процесс лучше/безопаснее. Отличная статья +1

Ответ 4

В предыдущем проекте J2EE мы делали именно это. Процесс сборки (ant script) собрал правильные файлы конфигурации, добавил их в определенную банку, которая затем была помещена в файл EAR для производственных сред, тестирования, обучения, QA и т.д.

В имени файла EAR указано имя целевой среды, поэтому было невозможно развернуть файл в неправильной среде. Если мы построим для цели 156p2 (factory 156, production env. 2), это будет частью имени файла EAR, а ant будет включать config_156p2.xml. Если цель была неправильной, имя файла EAR было бы неправильным и в качестве последнего отказоустойчивого решения заметил бы тот, кто его развернул.

Файл сборки должен содержать следующее: one ant target, чтобы начать сборку для каждой среды, которая установила свойство, которое сообщило ant, какой файл конфигурации должен быть включен.

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

Ответ 5

У нас есть 3 папки для этой цели в наших проектах, каждый из которых содержит файлы конфигурации (имена файлов одинаковы между папками):

  • personal: содержит пути для тестирования db, сервера и т.д.
  • test: содержит пути к серверам, совместно используемым с моими коллегами.
  • продукция: содержит... ну вы догадались

Когда я создаю свой проект, я добавляю подходящий профиль в сборку проекта Intellij Idea, в запрошенном модуле это в основном означает, что я добавляю другую структуру в структуру проекта, но поскольку имена файлов одинаковы, какие изменения относятся только к профилю свойства.

Ответ 6

Очень старый пост все еще отвечает, если кто-то его проверяет. На каждом сервере приложений вы можете установить свойства системы, например:

Консоль управления Wildfly → Конфигурация → Свойства системы

  • Там я добавляю переменную SERVER_ENVIRONMENT со значением как DEV/UAT/PROD.

В моем Java-коде я использую: System.getProperty("SERVER_ENVIRONMENT")

который дает мне значение с сервера.