Сборка сейчас больно медленная

Question

Мы сталкиваемся с проблемами производительности при реализации Team Foundation Build Server, и у меня заканчиваются идеи о том, как ускорить процесс. Мы уже добавили несколько элементов PropertyGroup для повышения производительности за несколько шагов (SkipClean, SkipLabel, SkipInitializeWorkspace), но я думаю, что нам нужно провести серьезную реструктуризацию, чтобы все исправить. Вот наша установка:

• У нас есть около 40 веб-приложений, каждое из которых сильно отличается друг от друга, но запускает несколько общих сборок
• Каждое из этих веб-приложений имеет собственное решение;
• Существует около 10-25 общих сборок, на которые ссылается каждое из этих веб-приложений;
• Существует определение сборки, содержащее все решения, которые запускаются при каждой регистрации в транк;

А вот основные проблемы, с которыми мы сталкиваемся

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

За последние несколько месяцев мы поддались летаргии и проигнорировали эту проблему, но теперь время сборки составляет от часа до полутора часов.

Я возился с идеей обучения и перехода на круиз-контроль для большего контроля, который у меня был бы. Кто-нибудь не согласен с этим?

Любая помощь наиболее ценится. Спасибо!

Answer 1

Итак, вот что я сделал, и я сократил сборку до 9 минут. Что касается количества проектов, которые я компилирую, меня это устраивает.

• Создано решение, которое содержит все общие библиотеки и все сети. На этом этапе было проделано много дополнительной работы, потому что мне пришлось исправить несколько ссылок, которые были устаревшим кодом или иным образом сохранялись в нескольких местах.
• Больше всего времени удалось сэкономить на выполнении файловой системы move вместо сетевой копии всех выходных файлов. Поскольку наше расположение на самом деле находится на сервере сборки, это имеет смысл.

Чтобы выполнить перемещение, я просто переопределил цель CoreDropBuild в файле TFSBuild.proj:

<Target Name="CoreDropBuild"
        Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
        DependsOnTargets="$(CoreDropBuildDependsOn)" >
             <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>    
</Target>

Answer 2

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

Во-вторых, разделите общие сборки на их собственный командный проект. После того, как вы переехали, у вас есть пара вариантов, вы можете ветвиться либо с исходной, либо скомпилированной библиотекой DLL в командные проекты, которым они нужны. У них могут быть свои собственные модульные тесты, и вы можете расширить групповую сборку, чтобы автоматически объединяться при успешном тестировании, если вы так склонны.

Подводя итог, вам нужно упростить вашу стратегию сборки.

Answer 3

Вам действительно нужно собрать все в каждом веб-приложении? Если общие сборки не изменились, зачем собирать их снова и снова?

Вот мысль:

1. Пусть каждое веб-приложение имеет собственную папку \ lib.
2. Поместите каждую общую сборку в папку lib.
3. Разрешить веб-приложению ссылаться только на общие сборки из локальной папки lib.
4. Проверьте все в.

Теперь сборка не должна начинаться, если что-то не изменилось, и сборка не будет включать общие сборки.

• Должна быть центральная папка, содержащая все общие сборки.
• Любое изменение здесь должно распространяться на все локальные папки \ lib.
• Наконец, любая общая сборка должна копироваться в центральную папку всякий раз, когда они изменяются.

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

Центральная папка должна управляться таким образом, чтобы любые изменения были скопированы во все ссылающиеся веб-приложения.

Answer 4

Исходя из личного опыта по предложению CruiseControl - помните, что это "интегрированная среда" непрерывной интеграции. Это не решит все ваши проблемы "из коробки" (сборка по компонентам, запуск при каждом изменении компонента и сериализованные сборки, хотя и улучшат ситуацию). Потребуется определенная настройка (и, возможно, даже настройка), чтобы получить все, как вы хотите, так что будьте готовы потратить некоторое время. Конечно, вы получите огромную отдачу в долгосрочной перспективе, если время сборки сократится - если вы больше не можете игнорировать проблему, стоит потратить некоторое время на лучшее решение CI.

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

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