2009-07-22 5 views
10

Мы разрабатываем большое электронное решение 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 

Util, что читает эти свойства имеет переключатель: isTest(), который префикс ключа с помощью «теста».

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

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

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

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

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

+0

Лоты изменили размер 2009 :) У Spring теперь есть способ сделать это в профилях: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-profiles.html – Tommy

ответ

4

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

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

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

+0

Я рассмотрю ресурс url JNDI. Чтение конфигурации непосредственно из SVN звучит хорошо. Если я понимаю это правильно? Как вы обрабатываете изменения в конфиге? Просто перезапустите EAR? Вы написали, что у вас был какой-то переход на другой ресурс. Что такое резерв? config-файлы в EAR? – Tommy

+0

Падение назад - это файлы конфигурации в EAR. Для дальнейшего разъяснения ... загружаются файлы конфигурации заказа 1. файл конфигурации по умолчанию 2. файл конфигурации с именем через имя хоста (конкретное имя узла, также в EAR). Таким образом, вы можете легко настроить приложения, работающие на разных узлах, например, чтобы каждый разработчик мог настроить свою среду. 3.файл конфигурации, просмотренный через jndi Последнее загруженное значение - это тот, который он использует, и 2 и 3 являются необязательными. Чтобы обновить конфигурацию, после ее изменения мы просто перезапустили EAR (поскольку мы используем Spring, файлы конфигурации считываются, когда при запуске создается контекст приложения). –

1

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

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

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

3

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

+1

это может сработать. Но, похоже, большая часть ручной работы позволяет синхронизировать все эти свойства по многим серверам. Как бы вы контролировали их версию? – Tommy

+0

Зависит от того, какой сервер вы используете. Я верю, например. JBoss позволяет настраивать записи JNDI путем развертывания архивов, подобных EAR и WAR, что позволяет использовать ту же процедуру, что и для вашего основного приложения. В противном случае выполните скрипт и версию скрипта. –

+0

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

1

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

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

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

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

1

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

  • личным: содержат пути для тестирования БД, сервера и т.д.
  • тест: содержит пути к серверам совместно со своими коллегами
  • продукции: содержит ... ну вы уже догадались

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

Смежные вопросы