NAnt с интеграционными тестами DB и, в конечном счете, непрерывной интеграцией

Question

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

Цель интеграции с другой стороны занимает достаточно много времени, поэтому я не хочу делать это очень часто - идеально, прежде чем я буду готов к развертыванию. Это похоже на разумную стратегию? IOW, я делаю это правильно?

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

Любые хорошие источники чтения по этому вопросу также будут оценены. Благодаря!

Answer 1

Да, вы на правильном пути. Теперь вам нужно подключить свою потенциальную цель к автоматизированному процессу. Я рекомендую использовать Team City или Cruise Control в качестве инструмента CI. После того, как у вас установлена ​​автоматическая настройка сервера, вы можете запускать свои сборные и модульные тесты при каждой проверке (непрерывная интеграция). Затем ваши интеграционные тесты можно запустить в ночное время или в выходные дни, так как они обычно занимают больше времени. Если ваши интеграционные тесты успешны, вы можете затем выполнить задание, которое будет развертываться на каком-то QA или другом сервере.

Answer 2

Звучит так, будто вы на 99% оттуда. Мой совет - просто погрузиться и начать делать это. Вы узнаете намного больше, фактически сделав решительный шаг и сделав это, чем думая о том, делаете ли вы все правильно.

Моя компания в настоящее время использует CruiseControl, и я лично считаю, что это здорово.

Answer 3

Смотреть это связано нить What is a good CI build process?

Вы на правильном пути. Если вы используете достойный инструмент CI, вы должны установить каждую настройку в качестве отдельного проекта, который запускает следующий шаг в цепочке ... т.е. успешно запускает триггеры, которые запускают развертывание, которое запускает интеграцию и т. Д.

Таким образом, ваш самый «перерыв» останавливает линию, так сказать.

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