Share via

Включение непрерывной интеграции на сервере TFS при сборке проектов Sharepoint 2010

  • Article

Непрерывная интеграция (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 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 редактора.