Улучшение времени сборки CI (.NET)

Question

Мы разрабатываем инфраструктуру приложений + «плагины», используя TeamCity в качестве CI-сервера.

Информация о проекте

1. 4 решения Visual Studio
2. ~ 70 проектов (и увеличивается)
3. В настоящее время выполняется 2 сборки с использованием TeamCity: CI и полная сборка.

CI - срабатывает при каждом коммите.

FULL - работает по ночам.

Я бы хотел улучшить производительность обеих сборок (особенно сборки CI, так как она должна выдавать свой вывод как можно быстрее).

Существуют ли какие-либо руководящие указания относительно того, что можно эффективно и легко улучшить?

Процесс сборки просто создает файл .sln и запускает некоторые модульные тесты.

Направления рассматриваются:

• MSBuild распараллеливание
• Переопределение CopyFilesToLocal

Не уверен, что они применимы / приведет к увеличению производительности.

Я ищу другие способы улучшить время сборки (которое занимает около 3-4 минут).

Answer 1

Минимизируйте работу, выполняемую вашими сборками ci.

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

• убедитесь, что сборка ci использует инкрементное получение и инкрементную сборку.

• только для создания решений / проектов, которые вам нужны.Если ваши библиотеки меняются редко, можете ли вы предварительно скомпилировать их и включить двоичные файлы в систему контроля версий?Если проект в настоящее время не разрабатывается активно, не беспокойтесь о его сборке в ci builds.

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

• Аналогично, не собирайте документацию, не запутывайте, не устанавливайте установщики, не подписывайте сборки сертификатамии т. д. и отключите все процессы сборки, которые копируют выходные данные в папку удаления.Сборки CI сообщают вам, если вы сломали сборку как можно скорее, вам не нужно генерировать полезные двоичные выходные данные.

• оптимизируйте сборку в целом - объединяйте проекты вместе, используйтемногопоточные сборки, используйте несколько агентов сборки, чтобы сборки Си не ожидали завершения других типов сборки.Выполняйте только полную сборку в одночасье, поэтому ваш сервер сборки выделен для CI, пока вы работаете.Держите исходные файлы в чистоте (удаляйте неиспользуемый код, а не просто комментируйте его, удаляйте неиспользуемые статьи / включите и т. Д.)

• инвестируйте в лучшее оборудование для сборки сервера.Если у вас нет машины с лучшими характеристиками, добавьте в нее больше оперативной памяти и SSD для дешевого повышения скорости.Убедитесь, что ваш сервер сборки предназначен для сборки CI и не используется ни для чего другого, что может замедлить его.Убедитесь, что сеть между сервером сборки и сервером tfs является гигабитной.Убедитесь, что на сервере не запущено антивирусное программное обеспечение или что по крайней мере его запланированные проверки выполняются в одночасье, а папки сборки находятся в списках исключений из проверки в режиме реального времени.

• Используйте проверку TFS в политиках, чтобы прекратить проверку разработчиков, если сборка CI не удалась, так что вы немедленно остановитесь и исправите поломки.

Answer 2

Я работаю над 500+ проектами C # приложения. Проекты компилируются параллельно, а copylocal устанавливается в false. Время компиляции составляет около 37 минут без юнит-тестов и покрытия кода. 13 минут для инкрементальной сборки без каких-либо изменений в коде. Если я выключу параллельную компиляцию и установлю copylocal в true, время компиляции будет> 1h40min. У меня другая конфигурация для локальной сборки, сборок со стробированием и серверных сборок с фазой развертывания (ночные сборки).

Вот мой опыт:

1. Копирование выходных файлов в один каталог не является хорошей идеей, если вы хотите строить свои проекты параллельно, если для CopyLocal установлено значение false. Мои сборки иногда блокировались, когда несколько проектов ссылались на одну и ту же сборку, и MSBuild пытался одновременно скопировать эту ссылку в выходную папку. Это решение было очень полезно для меня. Для всех ссылок я установил для copylocal значение false, а размер директории сборки был уменьшен в 10 раз (в 10 раз меньше операций ввода-вывода). У меня разные настройки для локальной сборки и для сборки сервера. Различные настройки для закрытой сборки регистрации и для полной сборки развертывания.
2. Если я включу параллельную сборку, сборка будет быстрее, намного быстрее. Если у вас сильный сервер сборки, ваша сборка / m: 2 должна быть в 2 раза быстрее, чем сборка / m: 1. Это не имеет никакого отношения к зависимостям между проектами (если copylocal имеет значение false).
3. Вы должны уменьшить зависимости между проектами, если хотите иметь быструю инкрементную сборку. Это не влияет на полную сборку (copylocal false). Время инкрементной компиляции зависит от измененного местоположения проекта в дереве сборки.

Да, MSBuild использует временную метку зависимых проектов, чтобы определить, нуждается ли проект в перестройке. Он сравнивает временные метки входных файлов (файлы кода, ссылочные сборки, временные файлы и т. Д.) С выходной сборкой. Если что-то изменилось, ваш проект перекомпилирован. Попробуйте уменьшить количество зависимостей между проектами, чтобы минимизировать перекомпиляцию. Если ваше изменение было только в «частной» части проекта, ваша выходная сборка будет изменена, метка времени сборки будет изменена, и все связанные проекты также будут перестроены. Вы не можете сделать много с этим.

Выполните сборку 2 раза с подробным диагностическим описанием без каких-либо изменений в коде и проверьте «Полное построение целевого« CoreCompile »», как я описал здесь . В файлах вашего проекта может быть что-то не так, и ваши проекты каждый раз перекомпилируются. Если вы ничего не измените, ваш журнал сборки не должен содержать журналы «Цель сборки« CoreCompile »полностью».

Наш сервер сборки - это виртуальная машина, а не реальная часть оборудования. Не очень хорошая идея использовать виртуальную машину для сборки сервера, но это было не мое решение.

Если у вас много ГБ ОЗУ, попробуйте использовать его как жесткий диск в памяти. Ваша сборка должна быть намного быстрее:)

SSD-накопители чувствительны к высокому количеству операций ввода-вывода в день. Это влияет на гарантию.

Надеюсь, это кому-нибудь поможет ...;)

Answer 3

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

1. Только строит то, что вы изменили. Это означает разделение ваших проектов на более мелкие.
2. Постройте решение в Debug или Release (не в обоих). Пусть ночная постройка в обоих.
3. Делайте юнит-тесты небольшими и быстрыми, чтобы обеспечить быструю обратную связь результатов с разработчиками.
4. Храните некритические задачи только для ночных сборок (документация, более длительные тесты автоматизации и т. Д.).
5. Цепочка всех зависимых конфигураций, поэтому при успешной сборке они будут собраны с последними изменениями; если зависимые конфиги терпят неудачу, вы сразу же знаете, что изменения не интегрируются с существующим кодом.

Мы попробовали Parallel MSBuild, но я не помню, предлагал ли он нам намного больше; может быть из-за агентов, которые у нас были.

Кроме того, время проверки / регистрации имело огромное влияние на общее время, поэтому, возможно, игра с VCS, так что он только проверяет измененные файлы, поможет.

Answer 4

1. Установите для параметра Локальное копирование значение false, конечно, это может сэкономить тонны секунд.

2. Кроме того, использование RAM-диска также является хорошей идеей,

3. Сократите номер вашего проекта (объедините их, если это возможно)

Список литературы:

http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx

http://www.simple -talk.com / содержание / print.aspx? статья = 1237