Мы находимся в процессе оптимизации/автоматизации построения, интеграции и тестирования модулей, а также развертывания. Наше программное обеспечение разработано в Visual Studio, где в наших проектах используются как C#, так и VB.NET. Один проект может содержаться в нескольких решениях (т. Е. Проект Utils используется как в решениях ProductA, так и ProductB)Структура сценариев сборки NAnt и структура решения на сервере сборки
По историческим причинам наш репозиторий кода не так хорошо структурирован, как можно было бы надеяться. . Проект 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, поэтому простое автоматическое создание будет огромным шагом для нас.
Благодаря
Я немного экспериментировал с вашим предложением, и это кажется правильным. Я все еще настраиваю сценарии NAnt для запуска сборников, но используя фактический файл решения проекта для запуска сборки с помощью задачи MSBuild от Nant. Я также собираюсь принять относительные ссылки, которые вы предлагаете, хотя это добавит много дополнительных каталогов. Я считаю, что изоляция важна. Скорее всего, мы перейдем на марш TFS2008, и я надеюсь, что эти усилия по настройке сервера сборки не будут потрачены впустую. Благодарим вас за помощь. – llykke