Сборка команды, теперь Крайне Медленная

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

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

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

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

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

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

Таким образом, необходимо упростить стратегию сборки.

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

Вот мысль:

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

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

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

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

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

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

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

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