Включение непрерывной интеграции на сервере TFS при сборке проектов Sharepoint 2010 Непрерывная интеграция (Continuous Integration) уже давно используется на средних и больших проектах как средство обеспечения качества и понимания общего прогресса. ALM без этого механизма скорее всего даже не является полноценным процессом обеспечения жизненного цикла продукта. В мире .NET это принятый стандарт в опытных командах. Но когда речь заходит об автоматизации сборок, юнит тестирования и обеспечения CI для проектов на Sharepoint 2010, многие опытные программисты и менеджеры проектов порой начинают сомневаться что этот механизм может работать в такой среде и его настройка не будет сопряжена с массой сложностей. Действительно, если ваш деплоймент порой занимает несколько команд XCOPY, все просто. В мире SharePoint все немного не так. Тем не менее, настроить CI для такой среды можно, и, в общем-то, не так уж сложно. Зато сулит массу выгод и удобств. В первую очередь это: Консистентные сборки. Если в ваш процесс сборки вовлечен человек, он все же потенциально может ошибиться. Настроенный скрипт ошибаться в тех же условиях не будет, а если что и случится, то это влечет за собой только фиксацию ошибки. Автоматическое версионирование .NET сборок. Мелочь, которая тем не менее позволяет более точно вести диагностику проблем и воспроизведение ошибок. Возможность трекинга кода относительно версий бинарных файлов в боевом окружении через метки исходного кода. Вы легко можете получить те самые исходники из БД контроля версий которые запущены у заказчика. Меньшее время, требуемое для программистов на развертывание окружения для разработки. Сплоченность команды в желании не порушить билд и коммитить качественный код. Автоматическое тестирование. Серебряная пуля CI, которая при некоторых условиях может поубивать немало багов в вашем продукте. Юнит тесты, UI тесты, нагрузочные тесты плюс Code Coverage. Соответствие канонам ALM. Теория Первое с чем предстоит определиться, это тип CI который будет использован на проекте. По большому счету их два – 1) воссоздавать полное исходное окружение и 2) делать апдейты к текущему состоянию системы. Каждый из этих подходов имеет свои достоинства и недостатки, но второй тип при кажущейся очевидности на самом деле более сложен чем первый. Ценой за это является тяжеловесность инфраструктуры CI окружения. Первый тип соответствует тому подходу, который может быть использован в среде Lab Management, когда у вас есть заранее сконфигурированный чистый виртуальный бокс, в который вы в идеальных условиях устанавливаете вновь собранные компоненты вашего решения. Во втором случае, вы работаете «по живому», и должны «подчищать» состояние системы до момента развертывания ваших компонент. Другими словами настраивать ваш скрипт сборки, чтобы он удалял с сервера SharePoint предыдущие веб-части и Solutions, делал retract и прочие действия. В механизмы Build Workflow для TFS 10 уже есть готовые Actions которые выполняют эти шаги. Определение текущего билда находится в БД контроля версий проекта, просто получите последнюю версию файла xaml на локальный диск и вы уже сможете редактировать его в workflow редакторе: Шаги которые должны быть определены в этой схеме в первую очередь: Собственно компиляция (стандартный) Генерация WSP пакета (стандартный) Копирование на сервер Sharepoint (стандартная XCopy операция) Удаление предыдущих версий WSP с сервера (вызов PowerShell) Развертывание/апгрейд WPS (вызов PowerShell) Создание тестового сайта (при необходимости) (вызов PowerShell) При всей кажущейся сложности этих пунктов, стандартный Build Definition уже работоспособен после конфигурации Build Agent, и дополнительные шаги зависят уже от вашего окружения. Конфигурация По умолчанию «из коробки» Build Agent TFS 2010 будет не в состоянии скомпилировать проект для SharePoint 2010, в первую очередь из-за того что он ссылается на .NET сборки из поставки SPS 2010. Их надо обязательно скопировать на сервер Build Agent. Вот необходимый минимум: Microsoft.Office.Server.dll Microsoft.Office.Server.UserProfiles.dll Microsoft.SharePoint.Client.dll Microsoft.SharePoint.Client.Runtime.dll Microsoft.SharePoint.Client.ServerRuntime.dll Microsoft.SharePoint.Linq.dll Microsoft.SharePoint.Portal.dll Microsoft.SharePoint.Publishing.dll Microsoft.SharePoint.Taxonomy.dll Microsoft.SharePoint.WorkflowActions.dll Microsoft.Web.CommandUI.dll Возможно вы будете использовать дополнительные компоненты, не забудьте добавить их в этот перечень и обработать на сервере Build Agent. Более детально шаги, которые необходимо проделать, описаны в MSDN https://msdn.microsoft.com/library/ff622991.aspx Для того чтобы корректно сконфигурировать Build Agent сервер, пригодится готовый PowerShell скрипт https://archive.msdn.microsoft.com/SPPwrShllTeamBuild/Release/ProjectReleases.aspx?ReleaseId=4210 Этот скрипт соберет всю необходимую информацию с машины программиста: .\SharePointProjectToTfsBuildServer.ps1 –Collect и затем произведет необходимые изменения на сервере Build Agent: .\SharePointProjectToTfsBuildServer.ps1 –Install Заключение CI для проектов Sharepoint 2010 сулит немало выгод. Для того чтобы сделать первые шаги в этом направлении достаточно сконфигурировать Build Agent чтобы он был способен компилировать WSP проекты, что может быть проделано с помощью готового PowerShell скрипта. В дальнейшем определение этого билда, в зависимости от вашего окружения может быть дополнено шагами (Actions) с помощью XAML редактора.