Как автоматизировать или упростить мультиплатформенную сборку / тестирование перед фиксацией?

Question

Наше программное обеспечение построено на платформах Linux и Windows. В зависимости от предпочтений разработчика, вклад разрабатывается и тестируется на любой платформе, а затем передается в наш репозиторий Subversion. Затем выясняется, что вклад не опирается на другую платформу, и необходимо внести исправление. Исправление на другой платформе может снова сломать сборку на исходной платформе и т. Д.

Я бы предпочел увидеть, что вклад создается (и проверяется регрессионно) и на другой платформе, прежде чем будет зафиксирован. У нас есть сервер непрерывной сборки (CruiseControl), но этот сервер собирается из репозитория. Я ищу решение, в котором сервер непрерывной сборки собирается на другой платформе в качестве предварительной проверки, а затем фиксирует материал, если сборка и тестирование прошло успешно.

Есть предложения?

Answer 1

Teamcity обрабатывает предварительно протестированные коммиты, возможно, вы сможете что-то сделать с новыми функциями цепочки сборки в 4.0 (http://www.jetbrains.com/teamcity/features/newfeatures.html). Агенты являются кроссплатформенными и могут быть настроены для запуска только определенных битов сборки, поэтому могут быть настроены для запуска только поднабора тестов.

Обратите внимание, что я на самом деле не сделал этого:)

Answer 2

Может быть проще иметь две ветви: одну, в которой люди регистрируются, и другую, в которую они объединяют свои изменения после прохождения непрерывной интеграции.

Answer 3

Дуглас Лидер предложил ветку «интеграции» - хорошо, что есть возможность автоматизировать. Если тесты пройдены - слиться с «стволом».

Некоторые системы контроля версий (например, bzr / hg / git) делают это проще, чем другие, но это возможно на большинстве.

Answer 4

Matheiu Godlewski сделал хорошее предложение на CruiseControl wiki

Если вы объедините его предложение с элементом вето , я думаю, что вы должны быть установлены.

Answer 5

Мы использовали специальную сборочную и тестовую установку, которая могла удаленно развертываться в нескольких ОС (и в нескольких продуктах баз данных в нескольких ОС). Это было сделано как ночная сборка с правилом, что вы исправляете ошибки на следующее утро.

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

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