Какие автоматизированные системы сборки вы используете? Сколько времени занимает сборка? - PullRequest
3 голосов
/ 11 февраля 2009

Мой текущий проект имеет 5 отдельных автоматических сборок, которые запускаются после каждой регистрации:
Модульные тесты (отключены вызовы БД): ~ 6 минут
Интеграционные тесты (только для БД): ~ 40 минут
Интерфейс веб-сайта 1 (Selenium, от UI до DB): ~ 80 минут
Веб-сайт 2 UI1 (Selenium, от UI до DB): ~ 90 минут
Веб-сайт 2 UI2 (Selenium, от UI до DB): ~ 100 минут

Мы используем Maven2, JUnit и Selenium.

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

Мне интересно, какие стратегии, которые вы нашли, помогли сократить время сборки больших проектов.

Ответы [ 8 ]

2 голосов
/ 11 февраля 2009

У нас примерно одинаковое время выполнения сборки, может быть, чуть меньше на селене (я бы сказал, время выполнения около 3x50 минут, те же тесты на сайте на Firefox, то есть на Opera). Наше решение состояло в том, чтобы добавить больше ресурсов процессора, и у нас есть кластерная бамбуковая среда, состоящая из 7 двухъядерных узлов.

Мы обнаружили, что запуск selenium-rc и браузера в отдельном окне из теста веб-контейнера / селена значительно улучшил время работы селена.

1 голос
/ 11 февраля 2009

Я использую GNU make для автоматизации всего. В зависимости от проекта от 2 минут до 30 минут.

0 голосов
/ 11 февраля 2009

У моего текущего клиента, к сожалению, BuildForge (от ClearCase SCC): от одного до трех дней. Seriosuly. Я действительно не знаю, что они делают в сборке или почему это так долго.

0 голосов
/ 11 февраля 2009

Все наши автоматизированные сборки выполняются с помощью Team City.

Самый автоматизированный проект, с которым мы работаем, - это, по сути, компилятор. Наш набор тестов состоит из около 20000 тестовых запросов, которые компилируются и выполняются, что выполняется при каждой регистрации. Раньше это занимало большую часть часа, но хранение полного набора тестов в ОЗУ на сборочной машине (вместо того, чтобы проверять его каждый раз) сокращает это до нескольких минут.

Каждую ночь запускается вторая сборка, которая запускает те же тесты, но под 4 различными профилями, в то время как работает под NCover, который выдает отчет о покрытии кода. Этот сценарий занимает несколько часов, поэтому он выполняется как ночная сборка. Другие внутренние отчеты создаются одновременно, чтобы гарантировать, что все работает как надо.

Обновления самого набора тестов запускаются отдельно и извлекаются на ОЗУ, готовые к следующему запуску. В противном случае проверка тестов занимала большую часть времени сборки. Часть набора тестов поступает из удаленного хранилища CVS, находящегося вне нашего контроля, и даже запрос об обновлениях добавляет несколько минут ко времени сборки, так что это также делается в сборке «Обновление тестов». Эта слабая связь означает, что нам пришлось ограничить сборки этого проекта одной машиной, но поскольку обратная связь очень быстрая, это не большая проблема.

Оказалось чрезвычайно полезным поддерживать "обычную" тестовую сборку как можно быстрее, сохраняя высокий охват кодовой базы. Любые медленные тесты (более секунды или около того) были перенесены в ночные сборки. В нашем случае проведение тестов в ОЗУ действительно помогло, хотя наш сценарий довольно специфичен. Я думаю, что издевательство над вашей базой данных является ближайшим аналогом. Мой совет, чтобы одна сборка была «скудной и подлой», удаляя любые «короткие» или медленные тесты, позволяя быстро реагировать, чтобы знать, что вы, вероятно, ничего не сломали. Другие сборки можно запускать на отдельных машинах или ночью, чтобы обеспечить быстрый отклик от быстрой сборки.

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

0 голосов
/ 11 февраля 2009

Общий тест Эрланга - в основном фокусируется на системных тестах, а не на модульных тестах.

0 голосов
/ 11 февраля 2009

Мы используем Hudson для создания большого решения на C #, содержащего несколько служб Windows, веб-служб и исполняемых файлов. Около 800 или около того тестов с помощью MSTest.exe, и это занимает около 12-15 минут на сборку. Тесты занимают большую часть, так как MSTest является slooow.

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

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

0 голосов
/ 11 февраля 2009

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

0 голосов
/ 11 февраля 2009

Система команд: до 1 часа на все

...