Slow Complex Builds & Hudson vs. Electric Cloud

Question

Является ли hudson правильным инструментом для сложных построений C++?

У меня есть сборка на C++, которая занимает около 4 часов. Компиляция и упаковка занимают около 1/2 времени, а тестирование потребляет другую половину. В настоящее время мы используем домашнюю систему, но есть некоторые шаги, чтобы пойти в hudson, так как мы используем ее для всех наших сборщиков java.

Моя проблема в том, что непрерывная интеграция не очень ... непрерывна с интервалом 4 часа. Я хочу инструмент, который позволит мне распараллелить сборку понятным образом.

Hudson был отлично подходит для небольших сборников или java-сборок, где я сижу на вершине большого проекта maven, но я не думаю, что он будет хорошо масштабироваться для сложных C++-сборок.

У вас был опыт?

Answer 1

Похож у вас есть несколько вопросов здесь:

1. Должен ли я использовать сервер CI для управления моим C++ build? Ответ на это однозначно ДА. Ваша доморощенная система может быть адекватной, но она не стандартная, ее распространение, вероятно, сложно, и ее сохранение отвлекает от работы, которую вы действительно платите.
2. Является ли Хадсон правильным выбором для моего проекта? Вероятно, он выполнит свою работу, и это имеет то преимущество, что вы уже находитесь на своем сайте. Однако вы специально указываете, что вам нужен инструмент, который хорошо поддерживает распараллеливание, и я не думаю, что Хадсон действительно соответствует законопроекту. Проблема в том, что Хадсон не был разработан с учетом параллелизма. См., Представление процесса сборки в Хадсоне - это «задание», которое представляет собой лишь последовательность шагов, выполняемых в последовательности - проверка, компиляция, тестирование, пакет и т. Д. Невозможно запустить эти шаги параллельно. Теперь вы можете обойти это, моделируя свой процесс несколькими заданиями. Каждая работа полностью независима, поэтому, конечно, их можно запустить параллельно; вы можете использовать что-то вроде Locks and Latches plugin для координации заданий, но весь процесс более сложный, чем это следовало бы, и вроде неуклюжий - вместо одного задания, представляющего один запуск процесса сборки, у вас есть несколько несвязанных заданий , в лучшем случае связаны между собой посредством соглашения об именах.
3. Может ли Electric Cloud помочь? Опять же, недвусмысленное ДА. Electric Cloud предлагает ElectricCommander, CI-сервер с параллельной поддержкой, встроенной с самого начала. Как и в случае с Хадсоном, для представления процесса сборки используется задание, но шаги в задании можно легко запускать параллельно (просто проверьте флажок «параллельный» на этих этапах), поэтому вам не нужно прибегать к добавлению, ons и kludges: один запуск процесса сборки - это одно задание, с таким количеством параллельных шагов, сколько вам нужно.
4. Будет ли правильный сервер CI помещать «непрерывный» обратно в мою интеграцию? Сервер CI доставит вам до сих пор. Дело в том, что сервер CI может предоставить вам крупнозернистый параллелизм - поэтому при небольшой работе вы можете настроить его, например, для запуска упаковки параллельно с тестами.С небольшой работой вы можете разделить свою тестовую фазу на несколько независимых частей, которые можно запускать параллельно.
       Вы не указали много деталей, но предположим, что ваша сборка составляет 90 минут компиляции, 30 минут упаковки и 2 часа испытаний, которые можно разбить на четыре 30-минутных куска. Предположим, что вы можете одновременно выполнять упаковку и тестирование. Это привело бы ваш 4-часовой процесс до 2 часов. На этом этапе «длинный полюс» в вашем процессе является фазой компиляции, и хотя вы можете разбить это вручную на части, которые могут выполняться параллельно с вашим CI-сервером, правда состоит в том, что сервер CI просто не правильный инструмент для этой работы.
       Лучшим вариантом является использование инструмента построения, который может дать вам автоматический мелкозернистый параллелизм в фазе компиляции. Например, если вы уже используете gmake, вы можете попробовать gmake -j 8 для запуска сразу 8 компиляций. Если ваши make-файлы чисты, а ваши зависимости правильны, и у вас есть мощный сервер сборки, это может дать вам довольно хорошее повышение производительности. Вы также можете использовать ElectricAccelerator, еще один продукт от Electric Cloud, специально разработанный для ускорения этой части процесса сборки, даже для сборок, которые не могут безопасно использовать gmake -j из-за неправильных или неполных зависимостей.

Надеюсь, что это поможет.

Answer 2

Не можете ли вы разбить сборку на несколько частей?

Вы отмечаете, что работа имеет несколько отдельных частей. Общее руководство с Hudson состоит в том, чтобы сделать часть сборки в одной работе, тестировать в другой, упаковывать в другую и т. Д.

Вы можете скомпилировать код в Job A и архивировать вывод, а затем сообщить Job B copy these artifacts из Job A и выполнить тесты на них. Между тем, другая работа А может быть ногами-офф из-за дополнительные фиксации в хранилище источника ..

Answer 3

Звучит для меня как проблема с вашим процессом сборки (создайте файлы ?, msbuild?), А не Hudson. Хадсон просто собирается выполнить процесс сборки так же, как пользователь из командной строки. Возможно ли оптимизировать процесс сборки?

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