Веб-Развертывание Java: создать код или развернуть .war?
7 ответов
Я твердо против построения на производственном поле, потому что это означает использование другой сборки, чем Вы протестировали с. Это также означает, что каждая машина развертывания имеет различный файл JAR/войны. Если ничто иное, сделайте объединенную сборку именно так это, когда отслеживание ошибок Вы не должны будете волноваться о несоответствиях между серверами.
Кроме того, Вы не должны помещать сборки в управление версиями, если можно легко отобразиться между сборкой и источником, который создал его.
Где я работаю, наш процесс развертывания следующие. (Это находится на Linux с Tomcat.)
Тестовые изменения и зарегистрировались в Подверсии. (Не обязательно в том порядке; мы не требуем, чтобы фиксировавший код был протестирован. Я - единственный полностью занятый разработчик, таким образом, дерево SVN является по существу моим ответвлением разработки. Ваш пробег может варьироваться.)
Скопируйте файлы JAR/войны в рабочий сервер в общем каталоге, названном в честь числа пересмотра Подверсии. Веб-серверы только имеют доступ для чтения.
Каталог развертывания содержит относительные символьные ссылки на файлы в названных пересмотром каталогах. Тем путем список каталогов будет всегда показывать Вам, какая версия исходного кода произвела рабочую версию. При развертывании мы обновляем файл журнала, который является немного больше, чем список каталогов. Это делает откаты легкими. (Один глюк, хотя; Tomcat проверяет на новые ВОЕННЫЕ файлы изменить датой реального файла, не символьную ссылку, таким образом, мы должны коснуться старого файла при откате.)
Наши веб-серверы распаковывают ВОЕННЫЕ файлы на локальный каталог. Подход масштабируем, так как ВОЕННЫЕ файлы находятся на единственном файловом сервере; мы могли иметь неограниченное количество веб-серверов и только сделать единственное развертывание.
Большинство мест я работал, использовало первый метод со средой определенная конфигурационная информация, развернутая отдельно (и обновляли намного более редко) за пределами войны/уха.
Я настоятельно рекомендую, "Развертывают собранные артефакты на производственном поле", такие как военный файл. Поэтому наши разработчики используют тот же сценарий сборки (Муравей в нашем случае) для построения войны с их песочницей разработки, как используется для создания наконец артефакт. Таким образом, это отлажено, а также сам код, не говоря уже об абсолютно повторяемом.
Я защитил бы использование непрерывного решения для интеграции, которое поддерживает распределенные сборки. Код зарегистрировался в Вашем SCM, может инициировать сборки (для непосредственного тестирования), и можно запланировать сборки для создания артефактов для QA. Можно затем способствовать эти артефакты производству и развертывать их.
Это в настоящее время, что я работаю над установкой, с помощью AnthillPro.
Править: Мы теперь используем Гудзон. Очень рекомендуем!
Там существуйте сервисы конфигурации, как тяжелый вес ZooKeeper, и большинство контейнеров позволяет Вам использовать JNDI для реализации некоторой конфигурации. Они разделят конфигурацию от сборки, но могут быть излишеством. Однако они действительно существуют. Много зависит от Ваших потребностей.
Я также использовал процесс, посредством чего артефакты создаются с заполнителями для значений конфигурации. Когда ВОЙНА развертывается, она взорвана, и заполнители заменяются соответствующими значениями.
Если Вы задаете этот вопрос относительно управления конфигурацией, то Ваш ответ должен быть на основе того, что Вы считаете управляемым артефактом. С точки зрения CM это - недопустимая ситуация, чтобы иметь некоторый набор работы исходных файлов в одной среде а не в другом. CM чувствителен к переменным среды, настройкам оптимизации, компилятору и версиям среды выполнения, и т.д. и необходимо объяснить эти вещи.
Если Вы задаете этот вопрос относительно повторяемого создания процесса, то ответ должен быть основан на местоположении и количестве боли, которую Вы готовы терпеть. Используя .war файл может включить более первичную боль, чтобы сэкономить усилия в циклах развертывания и тесте. Используя исходные файлы и сборку инструменты могут сохранить заранее стоимость, но необходимо будет вынести дополнительную боль имея дело с проблемами поздно в процессе развертывания.
Обновление для конкретного примера
Две вещи рассмотреть относительно Вашего примера.
A. военный файл является просто .zip файлом с альтернативным добавочным номером. Вы могли заменить конфигурационный файл на месте с помощью стандартных утилит zip.
Потенциально пересмотрите потребность поместить конфигурационный файл в .war файле. Было бы достаточно иметь его на пути к классу, или свойства указали в командной строке выполнения при запуске сервера.
Обычно я пытаюсь сохранить требования конфигурации развертывания характерными для местоположения развертывания.
Используя 1 упакованный военный файл для развертывается, хорошая практика.
мы используем муравья для замены значений, которые отличаются между средами. Мы регистрируем файл с @@@ переменной, которая будет заменена нашим скриптом Ant. Скрипт Ant заменяет корректный объект в файле и затем обновляет военный файл перед развертыванием на каждом
<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"/>
Для суммирования - муравей делает все это, и мы используем муравейник для управления муравьем. муравей создает военный файл, заменяет пути к файлам, обновляет военный файл, затем развертывается к цели environement. Один процесс, на самом деле один щелчок кнопки в муравейнике.