Ускорение сервера сборки непрерывной интеграции PHP на Hudson CI

Я пытаюсь ускорить свои сборки и искал некоторые мысли о том, как это сделать. В настоящее время я использую Hudson в качестве сервера непрерывной интеграции для PHP проекта.

Я использую файл Ant build.xml для сборки, используя файл, аналогичный php-hudson-template < / а>. Однако на данный момент (из-за некоторых странных проблем с отказом Hudson в противном случае) я использую только phpDocumentor, phpcpd и phpUnit. phpUnit также создает Clover отчеты о покрытии кода.

Вот несколько возможных узких мест:

  1. phpDocumentor: занимает 180 секунд. В мой проект включены несколько больших библиотек, например awsninja, DirectedEdge, oauthsimple и phpMailer. Я не уверен, что мне действительно нужно разрабатывать документацию для них. Я также не уверен, как игнорировать целые подкаталоги с помощью моего файла build.xml.
  2. phpUnit: занимает 120 секунд. Это единственная часть сборки, которая не запускается как parallelTask. Чем больше тестов будет написано, тем дольше будет увеличиваться это время. На самом деле не уверен, что с этим делать, кроме, возможно, запуска нескольких ведомых устройств сборки Hudson и раздачи отдельных наборов тестов каждому ведомому устройству. Но я тоже не знаю, как это сделать.
  3. phpcpd: занимает 97 секунд. Я уверен, что могу сократить время синтаксического анализа и преобразования, игнорируя эти включенные библиотеки. Не знаю, как это сделать в моем файле build.xml.
  4. Мой сервер: сейчас я использую один сервер Linode. Кажется, весь процесс облагается налогом.

Любые другие возможные узкие места, о которых вы можете подумать, я добавлю к списку.

Как можно сократить время сборки?


person Josh Smith    schedule 12.09.2010    source источник


Ответы (3)


Я совсем не эксперт по PHP, но вы должны иметь возможность разделить свои тесты PHPUnit на несколько ведомых устройств Hudson, если вам нужно. Я бы просто разделил ваш набор тестов и запустил каждое подмножество как отдельное параллельное задание Hudson. Если у вас есть машина с несколькими процессорами / ядрами, вы можете запускать на ней несколько ведомых устройств.

Одна очевидная вещь, которую вы не упомянули - как насчет того, чтобы просто обновить свое оборудование или посмотреть, что еще работает на хосте Hudson и, возможно, занимает ресурсы?

person gareth_bowles    schedule 13.09.2010
comment
Да, я упомянул свой сервер как одну из возможностей. И это то, чем я пользуюсь прямо сейчас. У меня был только Linode с 512 МБ, поэтому я увеличил его до 1024 МБ; посмотрим, какая разница. - person Josh Smith; 13.09.2010
comment
Оборудование было, по-видимому, самым большим и лучшим изменением, которое я мог сделать. Уменьшено время моей документации до 52 секунд. Я не мог быть счастливее. Спасибо! - person Josh Smith; 13.09.2010

  1. phpDocumenter: phpdoc -h показывает параметр -i, который позволяет указать список файлов / каталогов, разделенных запятыми, которые следует игнорировать. Это можно добавить в тег arguments вашего тега phpdoc build.xml.

  2. phpUnit: я заметил, что при выполнении тестов с базой данных может возникнуть задержка, но я не знаю, как это исправить.

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

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

person Robin    schedule 13.09.2010
comment
Робин, хорошие мысли по документации. Не возражаете ли вы предоставить синтаксис для игнорирования нескольких каталогов? Кроме того, я отправлю уведомление о том, что тесты с базой данных занимают намного больше времени, чем другие тесты. Вы пробовали использовать моки или подобные вещи? Я лично не уверен, что понимаю, почему использование моков лучше, чем использование тестовой базы данных ... - person Josh Smith; 13.09.2010
comment
Из вывода phpdoc -h: -i --ignore file(s) that will be ignored, multiple separated by ','. Wildcards * and ? are ok На мой взгляд, если я тестирую класс MySQL, я хочу протестировать его с помощью тестовой базы данных, поскольку это более точный тест на функциональность. Если я тестирую что-то, что на самом деле не зависит от базы данных, я бы использовал фиктивные данные, которые ускорили бы тесты. - person Robin; 29.09.2010

Когда у нас возникла аналогичная проблема, мы прибегли к запуску документации в отдельной ночной сборке (вместе с нашими скриптами функционального тестирования в Selenium, так как это тоже довольно медленно). Таким образом, наша основная сборка CI не замедлилась из-за создания документации по API.

Тем не менее, я отмечу, что PHP Documentor теперь обновлен до версии 2, в которой значительно улучшена скорость по сравнению с медленной старой версией 1. Похоже, что он примерно в два-три раза быстрее, чем v1. Это будет иметь большое значение для вашего процесса CI. См. http://phpdoc.org/ для получения дополнительной информации.

В качестве альтернативы вы можете взглянуть на apiGen и phpDox, оба являются альтернативой PHPDoc. Оба они определенно быстрее, чем PHPDoc v1; Я еще не сравнивал их с v2.

person SDC    schedule 27.04.2012