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

Ответ 1

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

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

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

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

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

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

• оптимизировать сборку в целом - объединить проекты вместе, использовать многопоточные сборки, использовать несколько агентов сборки, поэтому ci builds не придется ждать завершения других типов сборки. Только делайте полную сборку в одночасье, чтобы ваш сервер сборки был посвящен ci во время работы. Храните исходные файлы в порядке (удалите неиспользуемый код, а не просто комментируйте его, удалите неиспользуемые usings/includes и т.д.)

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

• использовать tfs для проверки политик, чтобы остановить проверку devs, если ci build завершилась с ошибкой, так что вы немедленно прекратите и исправляете поломки.

Ответ 2

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

Вот мои впечатления:

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

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

Запустите свою сборку 2 раза с помощью диагностической многословия без каких-либо изменений в вашем коде и проверьте, что "Создать цель" CoreCompile "полностью", как я описал здесь. Вы можете иметь что-то не так в ваших файлах проекта, и ваши проекты перекомпилируются каждый раз. Если вы ничего не измените, ваш журнал сборки не должен содержать "полностью настраиваемые" записи "Building target" CoreCompile.

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

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

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

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

Ответ 3

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

• Создавайте только то, что вы изменили. Это означает разделение ваших проектов на более мелкие.
• Создайте решение в Debug или Release (не для обоих). Пусть ночная сборка в обоих.
• Сохраняйте модульные тесты малыми и быстрыми, чтобы дать разработчикам быстрые отзывы о результатах.
• Сохраняйте некритические задачи только для ночной сборки (документация, более длительные тесты автоматизации и т.д.).
• Цепочка всех зависимых конфигураций, поэтому, когда ваша сборка будет успешной, они будут строить с недавними изменениями; если зависимые конфиги терпят неудачу, вы сразу же знаете, что изменения не интегрируются с существующим кодом.

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

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

Ответ 4

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

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

• Уменьшите свой номер проекта (если возможно, слейте их)

Литература:

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

http://www.simple-talk.com/content/print.aspx?article=1237