Автоматическая сборка .NET с cruisecontrol.net + nant - структура множественной сборки / лучшие практики - PullRequest
0 голосов
/ 27 января 2009

Я делаю некоторую работу с несколькими общими сборками .NET и универсальным веб-приложением, которое я бы хотел лучше обрабатывать в нашей среде сборки CC.NET/NAnt.

В настоящее время у нас есть несколько сборок .NET (общий общий код, который мы используем в клиентских проектах), которые существуют в разных решениях .NET в разных репозиториях в нашей SCM (кстати, Vault). Все они настроены под CC.NET отдельно, поэтому в настоящее время мы имеем достаточный контроль над их сборкой и развертыванием.

Мы разработали систему CMS, которая использует некоторые из сборок .NET и включает в себя общий проект веб-сайта администрирования и пример шаблона веб-сайта. Из этого единственного решения у нас есть следующие элементы, которыми нужно управлять отдельно:

  • Интерфейс администратора не привязан к .NET, поэтому он основан на шаблонах, и в настоящее время мы разрабатываем для него бэкэнд PHP.
  • Сборка с общей сборкой CMS поверх других распространенных сборок нашей компании.
  • Контроль функциональности в каждой основной сборке / выпуске CMS.

Я бы хотел, чтобы результатом сборки этого решения был шаблон Visual Studio, который мы можем использовать для разработки других клиентских сайтов и лучшего управления изменениями версий в самой CMS, поскольку мы добавляем функции в базу кода.

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

Основные соображения для нас:

  • Используем ли мы функциональность очереди интеграции в CC.NET, чтобы обеспечить порядок сборки и собрать сборки, необходимые для CMS во время сборки?
  • Отладка на клиентском сайте CMS, т. Е. Вход в код общих сборок, когда клиентское решение является версией базовой системы CMS и, следовательно, отдельным.
  • Разработка и расширение CMS, когда она использует общие сборки, т. Е. Добавляем ли мы проекты сборки в магистральное решение во время разработки (через репозитории управления исходным кодом), а затем полагаемся на сборку, чтобы собрать ее вместе, или же мы полностью используем другой подход
  • Какие-нибудь другие проблемы, которые могли возникнуть у людей, могли бы изменить наше мышление?

Надеюсь, этот вопрос не слишком расплывчатый, и некоторые из вас будут иметь дело с этими проблемами. С нетерпением ждем опыта каждого.

Большое спасибо! Тим

1 Ответ

1 голос
/ 29 января 2009

Я, к сожалению, не могу ответить на все ваши вопросы, но позвольте мне начать с этого:

  • Используем ли мы функциональность очереди интеграции в CC.NET для обеспечить порядок сборки и сплотить сборки, которые нам нужны для CMS на время сборки?

Короткий ответ: да, вы должны. Атрибут очереди обеспечивает порядок сборки в работающем экземпляре CC.NET и дает вам сериализацию сборок, которые зависят друг от друга. Чтобы указать, какие проекты зависят друг от друга, вы должны использовать триггеры проекта . не полагается на queuePriority для этой задачи.

Скорее всего, вы тянете кусочки, необходимые для сборки во время сборки. Если у вас нет временных ограничений для ваших индивидуальных сборок.

Re:

  • Разработка и расширение CMS, когда она использует общие сборки, т. Е. Добавляем ли мы проекты сборки в магистральное решение во время разработки (через репозитории управления исходным кодом), а затем полагаемся на сборку, чтобы собрать ее вместе, или же мы полностью используем другой подход

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

...