За эти годы я создал и настроил набор сценариев NAnt для выполнения полной сборки проекта. Основной сценарий берет одну конечную точку приложения (например, проект веб-приложения) и выполняет полную, из исходного кода, его сборку. Сценарии предварительно сконфигурированы с необходимой информацией, касающейся местоположений выходных данных сборки, адресов управления исходным кодом и т. Д. Суть в том, что вы можете предоставить ему очень мало информации и построить данный проект с нуля. Это удовлетворяет «произвольной» части моего вопроса.
В прошлом я работал в компаниях, которые производят несколько программных продуктов (в основном, веб-приложений). Эта среда очень хорошо подходит для типичной установки непрерывной интеграции, где есть интегратор для каждого продукта. Я настроил интеграторов, которые будут служить как сборками CI, так и интеграторами для обработки полной сборки кандидата на выпуск и развертывания QA. Эти интеграторы используют сценарии мастер-сборки, поэтому сами интеграторы - это не что иное, как мониторинг исходного кода и вызов мастер-сценария NAnt.
Сейчас я работаю в группе разработчиков, которая создает много приложений. Зачастую разработчики призваны поддерживать приложения, изначально созданные другими. Когда я начинал, не было никакого управления сборкой. Я нахожусь в уникальном положении в группе как ведущий разработчик команды из 4 человек для набора продуктов одного бизнес-подразделения (около полдюжины законченных систем). Я реализовал CruiseControl.Net с помощью основных сценариев сборки для выполнения как сборок CI, так и сборок RC. Это работает для фиксированного набора проектов в наборе продуктов для бизнеса.
Я использую CCNet уже много лет, поэтому я полностью осознаю, на что он способен. Я с большим уважением отношусь к его вкладу в сферу непрерывной интеграции, поскольку использую его для всех проектов в своем наборе продуктов. Я подчеркнул для своей команды использование официального интегратора сборки RC в качестве основного компоновщика для всего, что предназначено для любого места, кроме разработки. Это обеспечивает отличный контроль над фиксированным набором проектов, находящихся под контролем CCNet.
Однако есть и другие разработчики, создающие другие приложения. Некоторые из них - это проекты разработчиков, которые часто даже не находятся в управлении исходными кодами, пока не попадают в жизненный цикл проекта (что-то еще, что я пытаюсь изменить). Многие из этих проектов являются уникальными, и после развертывания их жизнь не будет развиваться. Несмотря на это, их все равно нужно будет поддерживать. Неотъемлемой частью поддержки является тот факт, что без централизованного управления сборкой этих проектов сборки-кандидаты на выпуск, которые идут в QA, и в конечном итоге производство остаются на отдельных машинах разработчика. Это, конечно, дает нулевую гарантию того, что все находится в управлении исходным кодом среди других факторов сборки машины разработчика.
Проблема, которую я пытался решить, заключается в следующем: какую систему я могу использовать, чтобы обеспечить централизованный контроль над произвольными сборками такого типа? Это определенно не единственная проблема. Тем не менее, во многих материалах, которые я прочитал о централизованных сборках, автоматизации сборок и непрерывной интеграции, основное внимание уделяется фиксированным проектам / продуктам и задаче поддержки их дальнейшей разработки. Какие типы процессов используются бизнесом, который постоянно занимается разработкой новых проектов? Они не используют эти типы процессов?
Хотя основные сценарии сборки и работают на сервере сборки, они неуклюжи в использовании. Также я бы предпочел ограничить доступ консоли к серверу сборки. Таким образом, для обеспечения более легкого доступа к запуску произвольных сборок в центральной системе требуется некоторая система управления.
Я понимаю, что то, что я ищу, может лежать под обложками MS Team Build. К сожалению, всякий раз, когда я начинаю читать об этом, я испытываю это чувство зыбучих песков, когда начинаю проникать в маркетинговый материал MS, и быстро теряю свой путь, так и не узнавая, можно ли с этим что-то сделать. Кроме того, расходы на лицензирование рассматривались как вероятный ограничитель в некоторых общих обсуждениях по теме Team Foundation Server и Team System.
Я очень хочу услышать от любого, кто решил эту проблему, кто мог бы предложить предложения. Я проделал некоторую работу над централизованной системой сборки, основанной на моих основных сценариях сборки "build-any-project". Однако то, что у меня есть, находится в зачаточном состоянии и было построено для поддержки в основном только тех проектов, над которыми я работаю. На данный момент отсутствует какая-либо поддержка, необходимая для работы со многими типами приложений или множеством конфигураций проекта / решения, которые возможны в Visual Studio.