Советы по ускорению времени сборки в Linux с использованием ANT, Javacc, JUnit и компиляции классов Java - PullRequest
5 голосов
/ 29 сентября 2008

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

Проект состоит из нескольких проектов, которые могут быть собраны в группы, но мы стремимся к полной сборке менее чем за 10 минут

Какие есть советы по сокращению времени сборки?

Спасибо

Ответы [ 8 ]

3 голосов
/ 29 сентября 2008

Одним из быстрых решений, которое может сократить время ожидания, является обеспечение запуска Ant с использованием JVM сервера (по умолчанию он использует клиентскую виртуальную машину). Установите для ANT_OPTS значение «-server».

2 голосов
/ 29 сентября 2008
  • Профилируйте процесс сборки и посмотрите, где находятся узкие места. Это может дать вам некоторые идеи относительно того, как улучшить процесс.
  • Попробуйте построить независимые проекты параллельно на многоядерных / процессорных компьютерах. В качестве расширения этой идеи вы можете поискать Java-эквивалент distcc (не знаю, существует ли он) для распределения вашей сборки по нескольким машинам.
  • Станьте лучше машины.
1 голос
/ 23 октября 2012

несколько советов по сокращению времени сборки:

  1. выполнять меньше работы. например удалить ненужные записи / эхо-файлов и консоль

  2. сделать вашу сборку инкрементной . Компилировать только изменения классов.

  3. устранить дублирующее усилие. Легче сказать, чем сделать, но если вы запустите сборку в режиме отладки ("ant -debug") иногда можно увидеть избыточные задачи или цели.

  4. избегайте дорогостоящих операций. копирование файлов и упаковка jar-файлов в войны необходимы для выпуска. Подписание jars является дорогостоящим и должно выполняться только, если возможно, для выпусков этапов, а не для каждой сборки

1 голос
/ 30 сентября 2008

Теперь, когда вы объяснили процесс более подробно, вот еще два варианта:

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

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

1 голос
/ 29 сентября 2008

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

0 голосов
/ 30 сентября 2008

Разве очень важно, чтобы сборка вся длилась менее 10 минут? Если вы сделаете подпроекты независимыми друг от друга, вы можете работать над одним подпроектом, уже скомпилировав другие (например, Maven или Ivy для управления зависимостями).

Другое решение (и если ваши модули достаточно стабильны) состоит в том, чтобы рассматривать ваши подпроекты как отдельные проекты. Каждый проект будет следовать своему собственному циклу выпуска и быть доступным из локального репозитория Maven / Ivy. Это, конечно, хорошо работает, если хотя бы части проекта достаточно стабильны.

0 голосов
/ 29 сентября 2008

Какова разбивка по затраченному времени:

  1. генерация классов
  2. составление классов
  3. выполнение тестов

В зависимости от проекта вы можете значительно увеличить время сборки, выделив больший размер кучи для javac (memoryMaximumSize) и junit (maxmemory).

0 голосов
/ 29 сентября 2008

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

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

...