Компиляция на нескольких хостах

Question

Предположим, что вы разрабатываете код, который необходимо скомпилировать и запустить на нескольких хостах (скажем, Linux и Windows), как бы вы это сделали наиболее эффективным способом, учитывая, что:

• У вас есть полный доступ к оборудованию для каждого хоста, для которого вы компилируете (в моем случае хост Linux и хост Windows стоят на моем столе).
• Сборка через сетевой диск обходится слишком дорого
• Не требуется никаких коммитов в центральный репозиторий - предположим, что есть движок CI, который пытается выполнить сборку, как только что-либо проверено

"Эффективный" означает, что цикл компиляции-редактирования-запуска должен быть как можно короче и проще.

Answer 1

Большинство серверов сборки, упомянутых в других ответах, проверяют ваши изменения в системе контроля версий.Учитывая ваш "Никаких коммитов в центральный репозиторий не требуется" поэтому я бы посоветовал вам попробовать Jetbrains Командный город Сервер CI.

Он имеет плагины для Visual Studio и Eclipse и позволяет вам запрашивать "частная постройка", отправляя ваши изменения прямо на сервер сборки.Для каждого проекта вы можете определить несколько конфигураций сборки с различными требованиями (операционная система - одно из возможных требований).Если сборки пройдут успешно, плагин предложит вам зафиксировать внесенные изменения.

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

Похоже, что Pulse также обладает та же функция, но у меня нет опыта работы с этим из первых рук.

Answer 2

Лучшее, что я могу порекомендовать, - это потрясающий кроссплатформенный проект под названием "BuildBot".

BuildBot может автоматически запускать сборку на каждой поддерживаемой вами платформе каждый раз, когда вы проверяете новую версию в своей системе управления версиями.Создайте его на OSX, Linux (ubuntu), Linux (debian), Linux (Redhat), Vista, Windows XP и т.д., и отправляйте электронные письма или что угодно, что вы предпочитаете, в случае сбоя сборки.

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

Вот несколько URL-адресов:

• Buildbot.net домашняя страница
• Python.org buildbot

Answer 3

Мы находим, что Хадсон это отличный сервер CI, который может выполнять сборки из системы управления версиями по мере необходимости.Поскольку он написан на Java, он может работать на выбранной вами целевой платформе, а поскольку интерфейс основан на веб-интерфейсе, вы можете управлять им из любого места.Есть плагины для выполнения большинства вещей, которые вы хотите сделать, и, самое главное, это бесплатно!

Answer 4

Выберите одну машину в качестве блока разработки.

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

Конечно, прежде чем делать настоящий релиз, вы все равно хотите провести тестирование на людях.Но это сохраняет нормальную жизнь в остальное время.

Answer 5

Использование http://ccache.samba.org для ускорения компиляции в более крупном проекте было изменено всего несколько файлов,

и когда были внесены большие изменения, используйте http://en.opensuse.org/Icecream в то же время для общей распределенной компиляции.

Вероятно, это должно значительно ускорить ваш цикл компиляции-редактирования-выполнения.

Answer 6

Поскольку вы используете CI, я предполагаю, что вы уже правильно настроили процесс сборки.Что мы делаем, так это то, что мы используем окна Windows в качестве машин для разработки, а CI работает на Solaris.Это гарантирует, что код хорошо компилируется на нескольких платформах.Код написан на Java, и мы не используем никаких собственных библиотек, поэтому вполне гарантировано, что код будет работать.Мы используем бамбук в работе - это здорово, но не бесплатно:-)

Для своих частных проектов я использовал Continuum, но Husdon выглядит аккуратно (я попробую) - спасибо, Питер.

Answer 7

Создать простую настройку для такой задачи очень просто.
Я предложу Лебедин для использования на платформе Windows.Таким образом, вы можете писать полностью переносимое программное обеспечение / скрипты как для платформ Linux, так и для Windows.Из вашего сообщения неясно, на какой стадии проекта вы находитесь, но предполагая, что вы только начинаете, я предложу использовать сделать для создания вашего программного обеспечения.Вы можете использовать cron, чтобы запланировать частоту для вашего круга проверки / сборки.Вы даже можете отправить электронное письмо с журналом сборки, если он сломан.
Существует ряд готовых ежедневных тестов сборки, как коммерческих, так и с открытым исходным кодом, вы можете поискать их в Google или, возможно, кто-нибудь добавит сюда предложения.
Для этой задачи мы используем самодельный инструмент, поэтому я не могу предложить ничего готового.

Хорошо, я упустил момент, что вы не хотите использовать систему управления версиями (что странно, но вы босс :)) в этом случае просто замените проверку на rsync, все остальное останется таким же.

Answer 8

Одним из вариантов было бы Каскад, который позволяет вам тестировать ваши изменения на всех ваших платформах до, а не после фиксации, "устанавливая контрольные точки" для них на сервере.

Answer 9

Одно слово: Круиз (не круиз-контроль) очень приятный.

Вы можете получить двух агентов бесплатно и по одному агенту на платформу.Настройка на Mac и ПК занимает буквально минуты, и, судя по тому, что я слышал, в Linux это не так уж плохо.