2009-11-26 2 views
6

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

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

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

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

+0

Действительно? Два часа для развертывания войны на 80 МБ? – Jherico

+0

Мы используем websphere, и иногда нам нужно развернуть EAR/WAR не только для производства, но и для постановки/тестирования и т. Д. Машин, часто виртуализированных и обладающих не очень большими характеристиками. Кроме того, иногда архивы необходимо отправлять по проводам в другие страны/континенты, и это может занять некоторое время. – Dan

ответ

1

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

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

Второй был более спорным. Весь наш html был развернут как отдельные файлы на сервере. Не было ВОЙНЫ. Поэтому, когда возникли обстоятельства, нам нужно было быстро что-то изменить текст, мы могли бы это сделать. Если java необходимо изменить, мы всегда делали FULL-сборку и развертывание.

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

Точка WAR - это то, что все развертывается одновременно. Если вы используете WAR, это означает, что вы хотите, чтобы он был развернут сразу.

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

+0

@MatthieuF: «Весь наш html был развернут как отдельные файлы на сервере. WAR не было». Как вы думаете, вы можете быть более конкретным? Что значит, не было ВОЙНЫ? Мы все еще говорим о стандартных Java-приложениях, работающих на Tomcat и т. Д.? – Dan

+0

Это стандартное приложение (по сути, в Weblogic), но вместо развертывания одного файла WAR мы дезактивировали все файлы и поместили их в правильные каталоги (мы сохранили JAR как JAR, конечно). Сервер не запускался во время развертывания, поэтому не было бы никаких несоответствий. –

0

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

1

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

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

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

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

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

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

+0

@ Rolf: «Причина в том, что когда вы делаете небольшие изменения, становится все труднее и труднее обнаруживать различия между производством и развитием. Шансы на то, что вы отправляете неправильный файл классов и сломаете производственный сервер, со временем увеличивается». Я думаю, что есть инструменты, которые могут сравнивать два файла с большой уверенностью, даже не текстовыми? – Dan

+0

Да, есть инструменты для этого, и некоторые из них описаны в некоторых ответах. По моему опыту, отправка файлов классов для обновления производственной войны ВСЕГДА плохая идея. Не проблема всегда лучше, чем наличие инструментов для решения проблемы. – Rolf

0

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

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

На данный момент у меня есть SVN SVVEL и LIVE SVN. ANT-сборка объединяет DEV в LIVE и передает снова в репозиторий LIVE. На этом этапе удаленный сервер может выполнить SVN UP, и вы автоматически получите запрашиваемый файл.

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

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

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

0

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

0

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

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

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

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

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

  • Счета клиентов - Сервер
  • Поиск - Сервер B
  • Online Booking - Сервер C
  • Payment Services - сервер D

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

0

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

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

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

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