Я сильно отредактировал этот вопрос, потому что ответы указали, что я не был ясен
проблема: изменения пользовательского интерфейса в веб-проекте Java могут быть утомительными и трудоемкими, поскольку каждый файл веб-приложения содержится в WAR
Мое предлагаемое решение: управляйте JSP, CSS, JS и тегами отдельно от базы кода приложения, которую для целей этого вопроса я определяю как:
- Весь исходный код Java
- Библиотеки пользовательских тегов со скомпилированной Java (расширение TagSupport)
- Файлы конфигурации Spring
- web.xml
- Jar в
+ Source
+ WEB
- WEB-INF
- JSP
- Tags
- lib
- HTML
- CSS
- JS
Было бы неплохо, если бы после основного начального цикла выпуска и обслуживания изменения в просмотре файлов можно было рассматривать как выпуск другого типа, чем изменение в Source. Изменения в исходном тексте будут зафиксированы как обычно, а версия приложения изменится. Тем не менее, изменение в CSS / JS / HTML и даже в JSP может быть сделано в тестовой среде, которая является внутренне видимой для тестирования нового внешнего вида, добавления ссылок и так далее. Технически, JSP может быть даже добавлен, и, если контроллеры (например, мои) могут быть настроены на отображение новых JSP без каких-либо модификаций Source, страницы могут быть добавлены без развертывания.
ИСПОЛЬЗОВАТЬ СЛУЧАЙ - Владелец сайта проводит рекламную акцию, у него есть причудливый рисунок для ссылки на информационную страницу в чистом HTML и он хочет добавить ее на домашнюю страницу.
Теперь представьте себе этот рабочий процесс:
Пользовательский интерфейс пользователя открывает Dreamweaver и может перевести FTP в Staging (staging может быть дурным именем, но в основном это живой тестовый сервер). Он может видеть:
- JSP
- Tags
- HTML
- CSS
- JS
Теперь он вводит HTML-файл с информацией о нем, добавляет его в каталог HTML. Затем он заходит в JSP / home.jsp и находит компонент, который отображает рекламу в правом столбце, непосредственно под ним он добавляет свое изящное изображение, сохраняет свои изменения, открывает браузер и переходит к действующему тестовому URL-адресу. Он видит свое изображение, но компонент больше не отображает рекламу. К сожалению, он звонит разработчику, и разработчик говорит, что нет проблем
$ staging - > ./rollbackView -mostRecentBackup
Парень из пользовательского интерфейса проверяет сайт, все возвращается, как будто он никогда не трогал его ... теперь он более тщательно добавляет свою графику и HTML, понимая, что раньше он обрезал пользовательский тег JSP. Теперь QA, что бы ни смотрело на проекте, запускает селен, что угодно. Все выглядит отлично. Разработчик получает право выпустить изменения
$ production - > ./updateProductionView
скрипт проверяет версии приложений, проверяя их идентичность, затем копирует файлы представлений. Сейчас 8:45, и владелец сайта (для нас внутренний) очень рад, что его новая идея была реализована в первые 15 минут дня
Теперь разработчик хочет создать патч, который позволяет что-то классное, он обновляет свой проект, и новые файлы представлений присутствуют. Может быть, это невозможно, но он мог запустить скрипт или использовать второй исходный репозиторий, например Mercurial, для управления представлениями (идеями?), И у него есть проект и просмотр необходимых ему файлов. Он вносит свои изменения в источник и взгляды, все, что ему нужно. Теперь, когда все готово, он может проверить свои изменения и вывести WAR в каталог Staging
.
$ staging - > ./deployStaging -overwriteView
Развернута полная война, и JSP теперь являются тем, что он имел в своем проекте. Если ребята из UI внесли изменения в постановку, они будут перезаписаны (возможно, сохранены резервные копии?). Он мог оставить флаг '-overwriteView', и файлы просмотра остались бы нетронутыми. На этом этапе были проведены полная регрессионная проверка, интеграционные и модульные тесты, пора исправлять основное приложение
$ staging - > ./deployProduction
Есть полное развертывание, версия приложения теперь V1.1, и все довольны
Мои вопросы:
Во-первых, кто-нибудь сделал что-то подобное? Если да, есть ли хорошие рекомендации, которые вы можете дать? Разработка ведется на Windows, но на производственных и промежуточных серверах работает Unix. На всех серверах установлена одна и та же версия Tomcat.
Я ищу идеи для сценариев, которые позволили бы создавать резервные копии веб-файлов Staging, и, надеюсь, даже для основного проекта, а также сценариев, которые могли бы
Что упустили из виду? Могу ли я сохранить проект таким же структурированным? Это вызовет проблемы с CVS?
Есть ли здесь что-нибудь невозможное или технически осуществимое?