Java Web Deployment: сборка кода или развертывание .war?

Question

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

Развертывание собранных артефактов в производственную коробку

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

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

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

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

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

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

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

Мысли

Обновление

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

Мы используем OSCache и включаем дисковый кеш. Файл конфигурации должен находиться внутри .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

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

Answer 3

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

Это то, над чем я сейчас работаю, используя AnthillPro .

РЕДАКТИРОВАТЬ: Мы сейчас используем Гудзон . Настоятельно рекомендуем!

Answer 4

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

Answer 5

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

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

Answer 6

Хорошей практикой является использование 1 упакованных военных файлов для развертывания.
мы используем муравей для замены значений, которые различны в разных средах. Мы проверяем файл с помощью переменной @@@, которая будет заменена нашим скриптом 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"/>

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

Answer 7

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

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

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

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

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

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

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