Централизация/управление произвольными сборками .NET-проектов и решений

Question

За эти годы я создал и настроил набор сценариев NAnt для выполнения полных проектов. Основной сценарий принимает конечную точку одного приложения (например, проект веб-приложения) и выполняет полный, из исходного управления, сборку. Сценарии предварительно сконфигурированы с необходимой информацией о местоположениях сборки, адресах контроля источника и т. Д. Главное, чтобы вы могли подавать очень мало информации и строить данный проект с нуля. Это удовлетворяет «произвольной» части моего вопроса.

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

Теперь я работаю для группы разработчиков, которая создает множество приложений. Часто разработчики призваны поддерживать приложения, созданные изначально другими. Когда я начал, не было никакого управления строительством. Я занимаю особую позицию в группе в качестве ведущего разработчика команды из 4 человек для набора продуктов одного подразделения (около полудюжины полных систем). Я применил CruiseControl.Net с основными скриптами сборки для выполнения как сборок CI, так и сборки RC. Это позволяет найти фиксированный набор проектов в бизнес-наборе продуктов.

Я использую CCNet уже много лет, поэтому я полностью понимаю, что он может сделать. Я очень уважаю его вклад в арену непрерывной интеграции, поскольку я использую его для всех проектов в своем наборе продуктов. Я подчеркнул своей команде использование официального интегратора сборки RC в качестве мастера-строителя для чего-либо, предназначенного для любого местоположения, кроме разработки. Это обеспечивает отличный контроль над фиксированным набором проектов, находящихся под контролем CCNet.

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

Проблема, которую я пытаюсь решить, заключается в следующем: какую систему я могу использовать для обеспечения централизованного управления этими произвольными сборками? Это определенно не уникальная проблема. Однако в большинстве случаев, которые я читал о централизованных сборках, автоматизации построения и непрерывной интеграции, основное внимание уделяется фиксированным проектам/продуктам и задачам поддержки их дальнейшего развития. Какие типы процессов используются бизнесом, которые постоянно разрабатывают новые проекты? Разве они не используют эти типы процессов?

В то время как скрипты master build работают на сервере сборки, они неуклюжи в использовании. Также я бы предпочел ограничить доступ к консоли сервером сборки. Таким образом, для управления провайдером требуется более простая система управления, позволяющая отключить произвольные сборки в центральной системе.

Я понимаю, что то, что я ищу, может находиться под обложками MS Team Build. К сожалению, всякий раз, когда я начинаю читать об этом, я получаю это зыбучие ощущения, когда я начинаю проникать в маркетинговый материал MS и быстро теряю свой путь, никогда не узнавая, что то, что я хочу сделать, можно сделать с этим.Кроме того, расходы на лицензирование были рассмотрены как вероятная пробная пробка в некоторых предыдущих общих дискуссиях по теме Team Foundation Server и Team System.

Я очень хочу услышать от всех, кто решил эту проблему, которая может предложить предложения. Я проделал некоторую работу над централизованной системой сборки, основанной на моих сценариях сборки «build-any-project». Однако то, что у меня есть, находится в зачаточном состоянии и было построено для поддержки, в основном, только тех проектов, над которыми я работаю. На данный момент не хватает поддержки, чтобы обрабатывать множество типов приложений или множество конфигураций проектов и решений, которые возможны в Visual Studio.

Answer 1

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

Я одобряю проектирование любой системы сборки для конкретного проекта, чтобы он требовал проверки одного модуля, например. MyProjectBuildEnvironment, а затем запускать один скрипт в очень нейтральном режиме инструмента, например. на системе windows build.bat

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

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

Центральная система сборки может быть простой системой, которая проверяет один модуль на проект и просто выполняет файл build.bat. Вы могли бы назвать это мета-сборкой.

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

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