Структура сценариев сборки NAnt и структура решения на сервере сборки

Question

Мы находимся в процессе оптимизации/автоматизации построения, интеграции и тестирования модулей, а также развертывания. Наше программное обеспечение разработано в Visual Studio, где в наших проектах используются как C#, так и VB.NET. Один проект может содержаться в нескольких решениях (т. Е. Проект Utils используется как в решениях ProductA, так и ProductB)

По историческим причинам наш репозиторий кода не так хорошо структурирован, как можно было бы надеяться. . Проект Utils может быть расположен в рамках решения ProductA (потому что это было его первое использование), но позже он был признан полезным для разработки productB и просто включен в решение продукта B (но все еще находится в подкаталоге productA).

Я хотел бы использовать непрерывное интеграционное тестирование и настроить сервер сборки CC.NET, где я намерен использовать NAnt для создания реальных сборок.

Вопрос 1: Как я должен строить свои сборки на сервере-сборщике? Должен ли я поручить CC.NET получить все проекты для продукта B в одну библиотеку, например. файл структура похожа на

-ProductB 
--Utils 
--BetterUtils 
--Data 

или я должен выбрать для filestructure похож на этот

-ProductA 
--Utils 

-ProductB 
--BetterUtils 
--Data 

, а затем просто иметь NAnt построить сценарии обработки ссылок? Наши ссылки в VS не совпадают с фактическим местоположением в репозитории кода, поэтому сегодня невозможно просто выгрузить решение productB и сразу же построить его (к сожалению). Надеюсь, этот вопрос имеет смысл?

Вопрос 2: ли это лучше, чтобы проверить весь исходный код, расположенный в различных проектах в одну папку (сохраняя при этом какую-то структуру), а затем построить каждую вещь на один или несколько проектов в ЦК. NET, а затем позволить серверу CC.NET обрабатывать зависимости? Пример: Должен ли я иметь отдельный проект в CC.NET для мониторинга автоматической сборки/тестирования проекта Utils, когда он никогда не выпускается самостоятельно? Или я должен просто строить/тестировать его при его создании в составе ProductB?

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

Прямо сейчас наша сборка состоит из развертывания через VS clickonce или нажатия F5, поэтому простое автоматическое создание будет огромным шагом для нас.

Благодаря

Answer 1

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

Если ваши решения уже ссылаться на проекты от относительных путей, вы можете в конечном итоге со структурой, как это:

-CCNetBuilds 
--ProductASource 
---Utils 
---... 
--ProductBSource 
---ProductA 
----Utils 
---ProductB 
----BetterUtils 
----Data 

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

Чтобы ответить на второй вопрос, я предпочитаю Утилиты, являющиеся его собственной сборкой. Если у меня есть модульные тесты на моей сборке Utilities, я бы не хотел, чтобы они запускались для каждого продукта, который использует утилиты. Кроме того, если у вас есть отдельная сборка для Утилитов, вы можете установить зависимость в CC.Net, чтобы Продукт A и B не пытались построить, если сборка Утилиты нарушена. Это обеспечивает более быструю обратную связь, что-то не так.