Статьи по теме
Инструменты для разработки

Visual Studio 2017 RC

Непревзойденная производительность для любого способа разработки, любого приложения и любой платформы

Visual Studio Community 2015

Бесплатная среда разработки

Visual Studio Enterprise 2015

Комплексное решение для рабочих групп

Дополнительное ПО и SDK

Выберите необходимые инструменты.

Включение непрерывной интеграции на сервере 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 редакторе:

Шаги которые должны быть определены в этой схеме в первую очередь:

  1. Собственно компиляция (стандартный)
  2. Генерация WSP пакета (стандартный)
  3. Копирование на сервер Sharepoint (стандартная XCopy операция)
  4. Удаление предыдущих версий WSP с сервера (вызов PowerShell)
  5. Развертывание/апгрейд WPS (вызов PowerShell)
  6. Создание тестового сайта (при необходимости) (вызов 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 http://msdn.microsoft.com/library/ff622991.aspx

Для того чтобы корректно сконфигурировать Build Agent сервер, пригодится готовый PowerShell скрипт http://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 редактора.