Веб-развертывание Java:создать код или развернуть .war?

Question

Два основных способа развертывания веб-приложения J2EE / Java (в очень упрощенном смысле):

Разместите собранные артефакты в рабочей коробке

Здесь мы создаем .war (или что-то еще) в другом месте настройте его для производства (возможно, создав многочисленные артефакты для многочисленных ящиков) и разместите полученные артефакты на производственных серверах.

• Плюсы:Нет инструментов разработки в производственных блоках, можно повторно использовать артефакты из тестирования напрямую, персоналу, выполняющему развертывание, не нужны знания процесса сборки.
• Минусы:два процесса создания и развертывания артефактов;потенциально сложная конфигурация готовых артефактов может затруднить сценарий / автоматизацию процесса;должны быть версифицированы двоичные артефакты

Создавайте артефакты вкл . производственная коробка

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

• Плюсы:Один процесс для поддержания;и это тщательно протестировано / подтверждено частым использованием.Потенциально проще настроить конфигурацию во время создания артефакта, чем настраивать предварительно созданное послесловие к артефакту;управление версиями двоичных артефактов не требуется.
• Минусы:Потенциально сложные инструменты разработки, необходимые для всех производственных блоков;сотрудники по развертыванию должны понимать процесс сборки;ты не являются развертывание того, что вы тестировали

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

Однако корпоративные приложения Java настолько чувствительны к конфигурации, что возникает ощущение, что напрашиваются на неприятности из-за наличия двух процессов настройки артефактов.

Мысли?

Обновить

Вот конкретный пример:

Мы используем OSCache и включаем дисковый кэш.Файл конфигурации должен находиться внутри файла .war и указывать путь к файлу.Этот путь отличается в каждой среде.Процесс сборки определяет настроенное местоположение пользователя и гарантирует, что файл свойств, размещенный в war, соответствует его среде.

Если бы мы использовали процесс сборки для развертывания, это был бы вопрос создания правильной конфигурации для производственной среды (например production.build.properties).

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

Это создает два процесса для достижения одной и той же цели.

Итак, вопросы заключаются в следующем:

• Можно ли этого избежать без "компиляции на производстве"?
• Если нет, то стоит ли это того?Значение "не компилировать на производстве" больше, чем "Не повторяйся"?

Answer 1

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

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

Там, где я работаю, наш процесс развертывания выглядит следующим образом.(Это в Linux, с Tomcat.)

1. Протестируйте изменения и зайдите в Subversion.(Не обязательно в таком порядке;мы не требуем, чтобы зафиксированный код тестировался.Я единственный разработчик, работающий полный рабочий день, поэтому дерево SVN - это, по сути, моя ветвь разработки.Ваш пробег может отличаться.)

2. Скопируйте файлы JAR / WAR на рабочий сервер в общий каталог, названный в честь номера редакции Subversion.Веб-серверы имеют доступ только на чтение.

3. Каталог развертывания содержит относительные символические ссылки на файлы в каталогах с именами версий.Таким образом, список каталогов всегда будет показывать вам, какая версия исходного кода создала текущую версию.При развертывании мы обновляем файл журнала, который представляет собой немного больше, чем список каталогов.Это упрощает откат.(Впрочем, один попался;Tomcat проверяет наличие новых файлов WAR по дате изменения реального файла, а не по символической ссылке, поэтому при откате нам приходится касаться старого файла.)

Наши веб-серверы распаковывают файлы WAR в локальный каталог.Этот подход является масштабируемым, поскольку файлы WAR находятся на одном файловом сервере;мы могли бы иметь неограниченное количество веб-серверов и выполнять только одно развертывание.

Answer 2

Большинство мест, где я работал, использовали первый метод с информацией о конфигурации конкретной среды, развернутой отдельно (и обновляемой гораздо реже) за пределами war / ear.

Answer 3

Я настоятельно рекомендую "Развернуть собранные артефакты в production box", например файл war.Вот почему наши разработчики используют тот же сценарий сборки (в нашем случае Ant) для создания war в своей песочнице разработки, что и для создания артефакта finally.Таким образом, он отлаживается так же, как и сам код, не говоря уже о полной повторяемости.

Answer 4

Существуют службы настройки, такие как heavy weight Смотритель зоопарка, и большинство контейнеров позволяют вам использовать JNDI для выполнения некоторой настройки.Они будут отделять конфигурацию от сборки, но могут оказаться излишними.Тем не менее, они действительно существуют.Многое зависит от ваших потребностей.

Я также использовал процесс, посредством которого артефакты создаются с использованием заполнителей для значений конфигурации.Когда WAR развернут, он разлагается, а заполнители заменяются соответствующими значениями.

Answer 5

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

В настоящее время это то, над настройкой чего я работаю, используя Муравейникпро.

Редактировать:Сейчас мы используем Хадсон.Очень рекомендую!

Answer 6

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

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

Обновление для конкретного примера

Две вещи, которые следует учитывать относительно вашего примера.

1. Файл .war - это просто zip-файл с альтернативным расширением.Вы могли бы заменить файл конфигурации на месте, используя стандартные утилиты zip.

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

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

Answer 7

Использование 1 упакованных файлов war для развертывания является хорошей практикой.
мы используем ant для замены значений, которые отличаются в разных средах.Мы проверяем файл с помощью переменной @@@, которая будет заменена нашим ant-скриптом.Сценарий ant заменяет правильный элемент в файле, а затем обновляет файл war перед развертыванием для каждого

<replace file="${BUILDS.ROOT}/DefaultWebApp/WEB-INF/classes/log4j.xml" token="@@@" value="${LOG4J.WEBSPHERE.LOGS}"/>


<!-- update the war file We don't want the source files in the war file.-->
<war basedir="${BUILDS.ROOT}/DefaultWebApp" destfile="${BUILDS.ROOT}/myThomson.war" excludes="WEB-INF/src/**" update="true"/>

Подводя итог - ant делает все это, и мы используем ant hill для управления ant.ant создает файл war, заменяет пути к файлам, обновляет файл war, затем развертывает в целевой среде.Один процесс, фактически одно нажатие кнопки в anthill.