Как обычно внезапно захотелось на одном проекте собирать билды для предварительного тестирования изменений перед внесением в общий контроль версий. Инкредибилд в конторе есть, но это политика по перераспределению бюджета, которую увы нет смысла ковырять. Поэтому для дальнейшего рассмотрения можно эту опцию не учитывать. А вот компьютеры в серверной найти проще =)Старенькие но свое дело делают.
Специфика проекта в том что хотя сам 1 экзешник можно собрать минут за 20 (на обычном 2ГГц квадкоре, плюс еще 20 на шаманства с данными для инсталлятора), для проверки нужно как минимум компилировать еще 8(!) конфигураций. Соответственно общее время легко набегает в 2 с половиной часа.
Что где есть в публичном доступе и/или разумными ценами для таких запущенных случаев? Смысла чтото долго разрабатывать нет так как к тому моменту уже и шах и ишак помрут =)
Здравствуйте, SleepyDrago, Вы писали:
SD>Как обычно внезапно захотелось на одном проекте собирать билды для предварительного тестирования изменений перед внесением в общий контроль версий. Инкредибилд в конторе есть, но это политика по перераспределению бюджета, которую увы нет смысла ковырять. Поэтому для дальнейшего рассмотрения можно эту опцию не учитывать. А вот компьютеры в серверной найти проще =)Старенькие но свое дело делают. SD>Специфика проекта в том что хотя сам 1 экзешник можно собрать минут за 20 (на обычном 2ГГц квадкоре, плюс еще 20 на шаманства с данными для инсталлятора), для проверки нужно как минимум компилировать еще 8(!) конфигураций. Соответственно общее время легко набегает в 2 с половиной часа. SD>Что где есть в публичном доступе и/или разумными ценами для таких запущенных случаев? Смысла чтото долго разрабатывать нет так как к тому моменту уже и шах и ишак помрут =)
ps. windows only, кроссплатформенность в этом случае не нужна
Здравствуйте, SleepyDrago, Вы писали:
SD>Что где есть в публичном доступе и/или разумными ценами для таких запущенных случаев? Смысла чтото долго разрабатывать нет так как к тому моменту уже и шах и ишак помрут =)
Возможно я не до конца понял проблему, но мы для сборки используем Visual Build (http://www.kinook.com/VisBuildPro/). Очень довольны. Возм, вам тоже пригодится?
Здравствуйте, Lonely Dog, Вы писали:
LD>Здравствуйте, SleepyDrago, Вы писали:
SD>>Что где есть в публичном доступе и/или разумными ценами для таких запущенных случаев? Смысла чтото долго разрабатывать нет так как к тому моменту уже и шах и ишак помрут =) LD>Возможно я не до конца понял проблему, но мы для сборки используем Visual Build (http://www.kinook.com/VisBuildPro/). Очень довольны. Возм, вам тоже пригодится?
Спасибо! наши китайские коллеги пользуются. давали нам конфиги под него и рекомендовали триалку. Проблему 2,5 часа на один билд оно вроде бы никак не решает.
Сейчас вот думаю разделить все шаги на отдельные задачи (jobs) в терминах Jenkins и бросить несколько машинок их выполнять. Поддерживать тучу машинок выглядит весьма геморройно.
SD>Спасибо! наши китайские коллеги пользуются. давали нам конфиги под него и рекомендовали триалку. Проблему 2,5 часа на один билд оно вроде бы никак не решает.
Т.е. все-таки проблема в этом (2.5 часа на сборку). Visual Build тоже умеет запускать сборку на разных машинах. Но это вроде руками надо прописывать. Хз, насколько этот вариант вам подходит.
Здравствуйте, SleepyDrago, Вы писали:
... SD>Спасибо! наши китайские коллеги пользуются. давали нам конфиги под него и рекомендовали триалку. Проблему 2,5 часа на один билд оно вроде бы никак не решает. SD>Сейчас вот думаю разделить все шаги на отдельные задачи (jobs) в терминах Jenkins и бросить несколько машинок их выполнять. Поддерживать тучу машинок выглядит весьма геморройно.
По ускорению сборки:
А ЯП какой? Если C/C++, то можно посмотерть в сторону unity builds, для сборочных машинок с небольшим количеством ядер прирост можут быть ощутимым. Но с legacy кодом могут быть проблемы. Инструменты: rudebuild — плагин для Visual Studio, Сotire — то же для CMake (он умеет резать результирующий cpp на несколько частей, в некоторых сценариях это полезно).
-- Visual Studio specific ---
Если сборка осуществляется с помощью Visual Studio, то есть сценарий, в котором (при использовании параметров по умолчанию) сборка затягивается из-за недостаточного количества RAM: один sln + большое количество проектов + интенсивное использование шаблонов. В VS есть два параметра которые влияют на "параллелизм" сборки — количество одновременно собираемых проектов внутри sln + количество одновременно компилируемых *.cpp внутри проекта. По умолчанию оба этих параметра равны количеству логических ядер. Например, при компиляции на восьмиядерном процессоре Visual Studio может (а может и нет, зависит от многих параметров — времени сборки отдельного UT, зависимостей между проектами, количества файлов, параметров железа, etc.) запустить одновременно 64 процесса cl.exe. Если каждый из них будет потреблять 300-500mb RAM в пике (шаблоны, например), то вся эта конструкция очень легко может положить всю систему в своп, при этом общее время компиляции увеличится в несколько раз.
Здравствуйте, SleepyDrago, Вы писали:
SD>Что где есть в публичном доступе и/или разумными ценами для таких запущенных случаев? Смысла чтото долго разрабатывать нет так как к тому моменту уже и шах и ишак помрут =)
Это всё для найтли билдов? Если так, то есть решение для gcc — distcc, думаю, что для ms есть что-то подобное. Вы можеет использовать не только машины в серверной, но и свои рабочие машины с одним потоком.