Инкрементное развертывание Java-приложений

Question

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

Как мы можем автоматизировать и устанавливать изменения постепенно? Например, сгенерируйте новую разнесенную войну, сравните файлы с разнесенной войной в рабочей среде, а затем замените в рабочей среде только файлы, затронутые изменениями: .jsp .html .class и т. Д.

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

Мы используем Maven для автоматизации нашего процесса сборки. Ключевой вопрос заключается в том, чтобы автоматизировать весь процесс, чтобы я мог быть уверен, что приложение v2.2.3 в моем Subversion - это именно то, что у меня в работе после инкрементного развертывания.

Answer 1

Раньше мы все время так делали. Мы работали в банке, и иногда возникали изменения в юридических фразах или условиях, которые необходимо было изменить сегодня (или, как правило, вчера).

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

Второй был более спорным. Весь наш HTML был развернут в виде отдельных файлов на сервере. Там не было никакой войны. Поэтому, когда возникли обстоятельства, что нам нужно было быстро изменить что-то текстовое, мы смогли это сделать. Если java нужно было изменить, мы всегда выполняли полную сборку и развертывание.

Это не то, что я бы рекомендовал, но это было хорошо для нашей ситуации.

Смысл ВОЙНЫ заключается в том, что все развертывается одновременно. Если вы используете WAR, это означает, что вы хотите, чтобы он был развернут все сразу.

Одно из предложений - не делать такие исправления так часто (раз в неделю?). Тогда у тебя не так много боли.

Answer 2

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

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

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

Для клиента это важно, но технически глупо развертывать 80 МБ по медленной линии, чтобы исправить небольшую опечатку.

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

Надеюсь, это поможет.

Answer 3

У меня раньше была похожая ситуация. Это действительно проблема разделения проблем, и она не слишком прямолинейна. Что вам нужно сделать, это отделить текст от шаблона / HTML-страницы.

Мы решили это, поместив наш текст в таблицу базы данных и используя таблицу в качестве ресурса сообщений - так же, как люди используют myMessages.properties для интернационализации (i8n). Это дает вам два преимущества: вы можете быстро и легко вносить изменения в текст без развертывания кода. Мы также кэшировали таблицу, чтобы производительность не сильно пострадала.

Не решение для всех, но оно действительно сработало для нас.

Answer 4

Я не думаю, что есть прямой ответ на этот вопрос. T

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

Я видел решения, где люди помещают классы в контейнер сервера приложений / сервлета, я не согласен с этим, но, похоже, он работает ... Я уверен, что есть ужасные истории!

Maven, безусловно, облегчает задачу, разбивая приложения на модули, но если вы делаете это и развертываете модули независимо, вам нужно убедиться, что разные версии хорошо играют вместе в тестовой среде, чтобы начать с ...

Альтернативой является разделение вашего приложения по функциональности и размещение отдельных функций на различных серверах, например:

• Учетные записи клиентов - сервер A
• Поиск - Сервер B
• Онлайн бронирование - Сервер C
• Платежные услуги - Сервер D

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

Answer 5

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

Answer 6

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

Вы можете автоматизировать развертывание одним щелчком, используя putty / plink [если вы используете windows], создав простой скрипт на локальном компьютере, а другой - на удаленном.

На данный момент у меня есть SVN РАЗВИТИЯ и LIVE SVN. Сборка ANT объединяет DEV в LIVE и коммит снова в LIVE репозиторий. На этом этапе удаленный сервер может выполнить SVN UP, и вы автоматически получите запрошенный файл.

Вы можете улучшить скрипт обновления, чтобы перезапустить сервер в случае изменения некоторых классов и не перезапускать в случае обновления скриптов / JSP.

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

Для улучшения процесса слияния SVN этот инструмент довольно полезен. : http://www.orcaware.com/svn/wiki/Svnmerge.py

Answer 7

diff и patch:

http://stephenjungels.com/jungels.net/articles/diff-patch-ten-minutes.html

Answer 8

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