Java EE 5 Среда разработки

Question

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

• Sun IPLANET 6,1 SP7 (ж/Apache)
• JDK 1.6
• Oracle WebLogic 10 MP3-
• Oracle 10g
• 1024-битный SSL

Они также имеют некоторые корпоративные стандарты для веб-приложений:

• Tomcat
• Struts
• Совместимость с Safari, Firefox, IE6, IE7

Я также сказал, что это приложение, скорее всего, не потребует полной среды Java EE 5 (возможно, это только веб-контейнер), но ему необходимо будет общаться с одним размещенным в отдельном экземпляре weblogic через клиентские EJB и т. д., а также выполнять различные вызовы веб-сервисов другим корпоративные услуги.

Мне задали задачу принять некоторые решения относительно того, как будут выглядеть наши среды разработки и тестирования для этой новой команды (небольшие, возможно, 2 или 3 человека, включая меня, но могут расти в ближайшие месяцы). Я хочу создать тот, где люди могут использовать IDE, которую они любят, и имеют хороший опыт разработки на локальном хосте, но все же имеют плавный путь к развертыванию в тестовой среде, а затем снова в производственную среду. Я думаю, что на локальных рабочих станциях http отлично, но сервер тестирования интеграции должен выглядеть точно так же, как сервер производства, и весь трафик должен быть https, чтобы удостовериться, что мы получаем точное представление о том, что будет.

Зная, что локальные рабочие станции разработчиков будут очень разнообразными и могут работать под управлением Mac OS X 10.6 (Snow Leopard) или Windows 7 на своих локальных рабочих станциях, но также должен быть определен общий тестовый сервер: какая технология стек даст нам хороший плавный путь от местной разработки, тестирования и производства?

EDIT: Извините, когда я говорю о технологическом стеке, я имею в виду, например, Ant + JBoss + Tomcat + Oracle XE против Maven + Geronimo + Derby. В основном список конкретных реализаций спецификации, которые мы должны установить на каждой машине разработки и тестовом сервере, который дает нам гибкую среду разработки, и плавный переход к тестовым и производственным средам.

EDIT2: Возможно, стоит упомянуть, что это приложение, если оно должно постоянно сохраняться в любой информации (что я предполагаю, что будет иметь значение), что бы это ни было, определенно не будет сложным. По всей вероятности, это будет нечто похожее на рудиментарную базу данных продукта.

Answer 1

Я хотел бы пойти на:

1. Хадсон для ночных сборках (или для каждого оформленного)
2. Mercurial или Subversion для управления версиями (работает GRE на обеих Windows и Mac)
3. Весна, Весна, Весна. Да, я серьезно, Весна решает гораздо больше проблем, чем просто инъекция зависимости; как безопасность, пакетная обработка, обработка транзакций, системная интеграция.
4. EclipseLink для ORM. Много расширенных функций (которые Hibernate не хватает) часто меня спасали (например, приличная поддержка хранимых процедур).
5. Легкий контейнер, например Jetty, Tomcat или Смола. Вы собираетесь совершать командные игры, если используете тяжелые медленные вещи, такие как Geronimo или JBoss.
6. DeltaWalker для инструмента merge/diff (снова работает на всех платформах).
7. Если вы собираетесь использовать расширенные функции базы данных, перейдите по ссылке OracleXE (и SQLDeveloper). Оба являются хорошими инструментами. Если нет, то что-то светлое, как H2 или Derby в порядке.
8. JUnit (или TestNG) и Mockito для модульного тестирования/насмешками.
9. Не используйте Struts. Серьезно, по крайней мере, пойдите с Struts2 или желательно что-то вроде JSF2, Stripes или GWT.
10. Порядочный багтрекер как, JTrac, Redmine или FogBugz
11. Селена для интеграции тестирования
12. Sonar для качества кода

Если вы собираетесь использовать различную Иду затем Maven может быть хорошей идеей, так как позволяет каждой IDE настраиваться из pom.xml (отлично работает в IntelliJ/NetBeans). Но лучший совет, который я могу вам дать, - это.

• Пойдите с тем, что вы уже знаете и имеете опыт. Вы не отправляетесь из Струтса в JSF2 за одну ночь.
• Получить лучшие инструменты, которые вы можете получить, серьезно свободный материал - это не всегда путь (хотя это часто бывает).

Счастливого взлома

Answer 2

Испытательная среда должна точно воспроизводить продукцию. Также выполняйте тестирование производительности в тестовой среде. Если аппаратное обеспечение является проблемой, и количество серверов в кластере должно быть ограничено, тогда создайте меньшее количество серверов на Test, но повторите то же самое, что и у вас на prod, то есть, чтобы сказать iplanet (apache) + weblogic + oracle db so on ....

Что касается локальной среды, вы можете использовать Tomcat (так как вам нужен только веб-контейнер), а для клиента ejb вы можете связать банку и сделать удаленный (если вы делаете удаленные вызовы в какое-то удаленное приложение).Если вы делаете местные звонки через локальные ejbs, вам придется использовать weblogic в разработке на локальном поле.

Попробуйте использовать одну и ту же среду IDE (хотя это в основном зависит от разработчиков). Что касается OS, это не имеет значения, так как если вы используете совместимую среду IDE, вы будете строить код только из этого.

Также убедитесь, что IDE плотно соединена либо с tomcat (если вы используете это), либо с weblogic, чтобы запустить код в режиме отладки.

Одна очень важная вещь: сначала определите структуру кода, а затем проверьте, что в управлении версиями, так что из любого ide пользователь проверяет/проверяет в той же структуре. Таким образом, та же структура распределяется между всеми разработчиками. Вставьте код в cvs или управление версиями в каждом выпуске, а затем выйдите из главы. Также очень важно использовать один файл сборки и поддерживать установочный документ для создания среды в локальной коробке. Также в отношении используемой структуры выберите тот, который вам больше всего подходит при кодировании и обслуживании. Таким образом, вы уменьшите количество ошибок в коде. В настоящее время люди используют комбинацию Spring/Hibernate, но это зависит от того, подходит ли он вашему проекту. Надеюсь, это поможет.

Answer 3

Непонятно, о чем именно вы спрашиваете, когда говорите «технологический стек», вы имеете в виду серверы, библиотеки, инструменты сборки? Во всяком случае, вот некоторые легкомысленные рекомендации:

• Хадсон для непрерывной интеграции
• Избегайте Maven, если вы на самом деле, на самом деле не нужно. Это завлекает вас, как сирену, с обещанием декларативных зависимостей и условной конфигурации, но практика сильно отличается от теории.
• Используйте Spring везде, где это возможно, по сравнению со стандартными API Java SE/Java EE. В дополнение к более простым API-интерфейсам он также облегчает возможности тестирования и AOP, которые намного проще, чем работать с AspectJ напрямую. Конечно, это также обеспечивает зависимость инъекции, которая поддерживает слабосвязанность
• Hibernate для ОРМА, или если ваши требования Настойчивости очень просты, Spring-JDBC может быть достаточно