Удаленный компилятор Java

Я ищу способ повысить производительность своей команды, и один из способов сделать это - сократить время, затрачиваемое на компиляцию, и unit test, а также упаковать и развернуть наше приложение Java EE, которое становится все больше и больше.

Тривиальное решение, которое я знаю, - это создать мощный компьютер с N процессорами (N ~ = несколько разработчиков) и невероятно быструю дисковую систему и много памяти, и запустить все на этом компьютере и подключиться к нему через X удаленно. Это было бы намного быстрее, чем компиляция на наших ноутбуках, но все же дешевле и легче поддерживать, чем покупать каждому разработчику свой собственный суперкомпьютер.

Есть ли другой способ решить эту проблему? Например, можем ли мы запускать наши IDE локально, а затем сообщать об этом удаленному компилятору java-источника? Может ли Netbeans/Eclipse/IntelliJ/т.д. Сделать это? Или есть специальный инструмент, который позволяет удаленную компиляцию java, также использующую несколько процессоров? Он не должен быть свободным/открытым исходным кодом.

К сожалению, наши ноутбуки ДОЛЖНЫ запускать (управляемую компанией) Windows Vista, поэтому еще одна причина пойти на отдельный серверный компьютер - позволить нам использовать Linux на нем и, наконец, избавиться от раздражающей управляемой среды.

EDIT:, чтобы подытожить ответы до сих пор, один из способов сократить время сборки - оставить компиляцию для разработчиков по отдельности (поскольку компиляция должна быть быстрой), пропустить текущие модульные тесты и горячие -deploy (без упаковки) в контейнер.

Затем, когда разработчик решает проверить свой код, сервер непрерывной интеграции (например, Hudson) запускается для очистки, сборки и запуска тестов, а также для их развертывания и упаковки.

РЕШЕНИЕ. Я принял решение Thorbjørn, так как считаю, что это будет ближе всего к тому, как я планирую продолжить. Хотя из любопытства я все еще заинтересован в решении исходной проблемы (= удаленная компиляция Java)...

Ответы

Ответ 1

Вам необходимы два рабочих процесса.

  • Строка ОФИЦИАЛЬНАЯ, которая проверяет источники, строит все с нуля, запускает все модульные тесты, а затем создает биты, которые в конечном итоге отправятся клиенту после тестирования.
  • Горячее развертывание разработчиков после изменения каждого исходного кода в контейнере, о котором знает IDE.

Эти два могут быть совершенно разными!

Для официальной сборки запустите Jenkins и сообщите ему, чтобы посмотреть исходный репозиторий и строить каждый раз, когда происходит изменение (и рассказывать тем, кто нарушает сборку). Если вы можете получить большой компьютер для строительства, используйте его для этой цели.

Для разработчиков загляните в подходящий контейнер с очень хорошими вариантами развертывания IDE и настройте его для использования для каждого разработчика. Это ОЧЕНЬ быстро окупится! Ранее JBoss был очень хорош для этой цели.

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

Посмотрите, что Джоэл думает о Build Server: http://www.joelonsoftware.com/articles/fog0000000023.html

Если вам не нравится Дженкинс, существует множество других.

(2016): Хадсон изменился на Дженкинса. Смотрите fooobar.com/questions/16002/... историю изменений имени)

Ответ 2

Обычно для настройки сервера сборки, например. hudson выполнить компиляцию/упаковку/модульное тестирование/развертывание.

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

Ответ 3

Вы можете смонтировать каждую директорию разработчика с помощью ntfs на мощной машине, а затем создать внешнюю конфигурацию инструмента в Eclipse (доступ к графическому интерфейсу), которая будет запускать сборку на внешнем сервере.

Ответ 4

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

Ответ 5

Когда вещи начинают становиться слишком большими для эффективных сборок, возможно, пришло время исследовать разбивку вашего кода на модули /JAR (как он распадается, будет зависеть от многих особенностей проекта и от того, как ваша команда работает). Если вы найдете хорошую настройку, вы можете уйти с меньшим количеством компиляции (не всегда нужно перестраивать весь проект) и более/более быстрое копирование/запись, чтобы добраться до точки, где вы можете протестировать новый код.

Ответ 6

Для вашего проекта нужна система сборки, которая позволяет вам строить, тестировать и упаковывать. Hudson является хорошим примером такой системы построения непрерывной интеграции.