Управление жизненным циклом приложений SharePoint
Применяет общие концепции и практики управления жизненным циклом приложений (ALM) к разработке приложений с использованием технологий SharePoint.
Предоставлено: Эрик Чарран, Microsoft Corporation
Авторы: Веса Ювонен, Microsoft Corporation | Стив Пешка, Microsoft Corporation
Важное замечание: Этот раздел относится к автоматически размещаемым надстройкам SharePoint. Программа предварительного просмотра для автоматически размещенных приложений закончилась. Не обращайте внимания на все ссылки на надстройки SharePoint с автоматическим размещением.
Обзор управления жизненным циклом приложений (ALM)
Microsoft SharePoint предоставляет разработчикам несколько вариантов создания и развертывания приложений, основанных на технологиях SharePoint, как для локальных, так и для размещенных или общедоступных облачных платформ. SharePoint предлагает дополнительные возможности в вопросах форм приложений, а также новые варианты использования стандартизованных технологий в приложениях. Хотя эти возможности приложений и варианты развертывания, которые возможны благодаря новой модели приложений в SharePoint, предоставляют разработчикам эффективные средства для создания новых и иммерсивных приложений, разработчикам необходимо иметь возможность вводить аспекты качества, тестирования и управления жизненным циклом приложения в процесс разработки. В этой статье применяются общие концепции и практики ALM для разработки приложений с использованием технологий SharePoint.
Новые возможности
SharePoint устанавливает новую парадигму для реализации приложений. Из-за этого изменения в разработке приложений с использованием технологий SharePoint разработчики и архитекторы должны иметь полное представление о новых шаблонах, практиках и моделях развертывания приложений для SharePoint. Важно отметить, что хотя модель приложений для разработки приложений с SharePoint изменилась, многие шаблоны разработки решений, включая выбор технологий, и методы реализации соответствуют имеющимся технологиям разработки веб-приложений.
Следующие ресурсы описывают типы приложений, которые могут быть созданы с использованием технологий SharePoint, и содержат рекомендации как для локальных, так и для облачных приложений. Дополнительные сведения о вариантах размещения надстроек SharePoint см. в статье Выбор шаблонов для разработки и размещения надстройки SharePoint.
Кроме того, Microsoft рекомендует клиентам оценить технологии, используемые при разработке приложений с SharePoint, поскольку существует более широкий набор вариантов реализации решения. Создавая приложения, клиенты могут сосредоточить внимание на использовании технологий на основе стандартов, таких как HTML5 и JavaScript, для уровня представления данных и уровня взаимодействия с пользователями, а OData и OAuth можно использовать для основанного на службах доступа к внутренней службе, включая SharePoint. Клиенты должны тщательно проанализировать, необходим ли код полного доверия (то есть, развертывание скомпилированных сборок в SharePoint). Хотя использование такой модели разработки по-прежнему возможно и необходимо в некоторых ситуациях, оно существенно увеличивает количество служебных данных в процессе управления жизненным циклом приложения.
Дополнительные сведения о новых гибких технологиях разработки для приложений в SharePoint см. в статье Обзор разработки SharePoint.
Преимущества и изменения
Так как поддерживаемые SharePoint технологии разработки приложений сейчас предлагают более гибкий набор языков и архитектур программирования, разработчикам необходимо адаптировать имеющиеся методики управления жизненным циклом приложения к основным методам разработки для настройки их присутствия в SharePoint. Такие концепции, как тестирование, установка сборки, развертывание и контроль качества, могут быть расширены, чтобы включать развертывание в SharePoint как приложение SharePoint. Это может означать, что, хотя многие разработчики, привыкшие к написанию и развертыванию серверных фермерских решений, расширяющих основные возможности SharePoint, к процессу внедрения должны применяться общие методы ALM для новой гибкой модели разработки, поддерживаемой приложениями SharePoint.
Поскольку клиенты продолжают переходить к облачным реализациям SharePoint, разработчикам необходимо понимать, как расширить концепции ALM, включив в них целевые среды разработки, тестирования и развертывания, которые находятся за пределами физических границ организации. Это включает оценку стратегий технологий для разработки, тестирования и развертывания приложений.
Как разработчики, так и архитекторы могут научиться синтезировать решения, состоящие из различных компонентов приложений, которые охватывают или сочетают в себе различные типы вариантов размещения. В ходе этого процесса адаптации необходимо в одностороннем порядке применять к приложениям эти процедуры управления жизненным циклом приложения. Например, разработчикам может потребоваться развернуть приложение, охватывающее развертывание локальных служб (то есть IIS, ASP.NET, MVC, WebAPI и WCF), Microsoft Azure, SharePoint и SQL Azure, а также иметь возможность тестирования компоненты приложения для определения качества или наличия каких-либо регрессий со времени предыдущей сборки. Эти требования могут означать существенный сдвиг в отношении разработчиков и команд к процессу ежедневной сборки и разработки, который является хорошо известной процедурой для локальных и серверных решений.
Аспекты рабочих групп разработки
Для организаций, в которых имеется более одного разработчика или архитектора приложений, необходимо тщательно спланировать групповую разработку для SharePoint, чтобы предоставлять приложения самого высокого качества, а также поддерживать достаточную производительность разработчиков. В связи с увеличением гибкости метода разработки приложений группам необходимо внести ясность и быть уверенными не только относительно моделей и шаблонов управления жизненным циклом приложения, но и того, как каждый разработчик будет писать код и гарантировать, что в процесс сборки приложений будет попадать качественный код.
Для этого сначала необходимо выбрать надлежащую среду разработки. Традиционно разработка выполнялась раздельно на виртуальных машинах, подключенных к общему хранилищу кода, который предоставлял возможности сборки, развертывания и тестирования, например Visual Studio TFS 2012. TFS по-прежнему остается мощным инструментальным компонентом стратегии управления жизненным циклом приложения, имеющим центральное значение в процессе разработки, но рабочим группам следует рассмотреть возможности использования TFS в различных типах сред разработки.
В зависимости от целевой среды и типа решения (то есть, какие компоненты должны быть размещены локально, а какие в облачной инфраструктуре или службах), сейчас разработчики могут выбирать различные комбинации новых сред разработки. Такие варианты будут состоять из новых предложений, таких как шаблон сайта разработчика SharePoint, клиент разработчика Office 365, а также традиционные варианты, такие как разработка на основе виртуальных машин с использованием Hyper-V в Windows 8 или Windows Server 2012.
В следующем разделе описаны вопросы среды разработки для разработчиков приложений и рабочих групп разработки.
Что необходимо учитывать при создании среды разработки
Выбирать среду разработки следует на основе многих факторов. Выбор будет значительно зависеть от типа разрабатываемого приложения, а также целевой платформы для приложения. Традиционно при разработке приложений для SharePoint Server 2010 разработчики настраивали виртуальные машины и проводили разработку изолированно. Это было связано с тем, что разработка решений с полным доверием могла требовать перезапуска базовых зависимостей SharePoint, таких как IIS, что не позволило бы многим разработчикам использовать одну среду SharePoint. Так как технологии разработки изменились и перед разработчиками открылось больше возможностей для создания приложений, разработчики и рабочие группы должны понимать, какие варианты сред разработки им доступны. На рисунке 1 показана среда разработки и набор различных средств, а также указаны типы решений, которые можно развернуть в целевых средах.
Рис. 1. Компоненты и средства среды разработки
[
Философия среды разработки
Из-за инвестиций в то, как приложения могут быть спроектированы и реализованы с использованием SharePoint, разработчики должны определить, нужно ли проводить разработку с использованием серверного кода. Так как разработчики создают приложения, использующие модель с размещением в облаке, снижается требование проводить разработку на основе виртуализированных сред, в частности для SharePoint. Разработчикам следует стремиться создавать решения с удаленной моделью разработки, использующей имеющуюся инфраструктуру на основе облака (как общедоступную, так и частную). Если среды разработки можно быстро и легко подготовить к работе без необходимости создавать и организовывать виртуализацию, разработчики могут уделять больше времени производительности и качеству разработки, а не управлению инфраструктурой.
Решение о необходимости виртуализированного экземпляра SharePoint по сравнению с новым шаблоном сайта разработки SharePoint будет зависеть от того, требуется ли для приложения развертывание кода полного доверия в SharePoint и его запуск там. Если нет необходимости в коде полного доверия, мы рекомендуем использовать шаблон сайта разработчика, который можно найти в клиентах разработки Office 365 или в реализации локального SharePoint организации. Шаблоны сайта разработчика позволяют разработчикам развертывать приложения непосредственно в SharePoint из Visual Studio. Сайты разработчика Office 365 предварительно настроены для изоляции приложений и OAuth, таким образом разработчики могут сразу приступать к написанию и тестированию приложений.
В следующих разделах подробно описано, когда разработчики могут использовать различные варианты сред для создания приложений.
Сайты разработки O365 (общедоступное облако)
На рисунке 2 показано, как разработчики могут использовать Office 365 в качестве среды разработки, и приведены типы средств для создания приложений SharePoint, которые могут размещаться в Office 365.
Рис. 2. Разработка приложений Office 365
[
Разработчики с подписками MSDN могут получить клиента разработки, который содержит сайт разработчика SharePoint. Сайт SharePointDeveloper предварительно настроен для разработки приложений. Пользователи могут использовать не только Visual Studio 2012 для разработки приложений, но и на сайтах разработчиков Office 365, Napa можно использовать на сайте для создания приложений. Дополнительные сведения о начале работы с сайтом разработчиков Office 365 см. в разделе Настройка среды разработки для надстроек SharePoint в Office 365.
Разработчики могут начать создавать приложения, которые будут размещаться в Office 365, локально или в другой инфраструктуре в модели, размещаемой у поставщика. Преимущество этой среды состоит в том, что эта инфраструктура, виртуализация и другие аспекты размещения для среды разработки SharePoint, абстрагируются с помощью Office 365, благодаря чему разработчики могут быстро создавать приложения. Главный недостаток среды разработки данного типа состоит в том, что в нее нельзя включить приложения, которым необходим код полного доверия для развертывания в SharePoint. Microsoft рекомендует как можно больше использовать клиентскую объектную модель SharePoint (CSOM) и клиентские технологии, такие как JavaScript. Если понадобится код полного доверия (но развертывание кода для работы в SharePoint не требуется), мы рекомендуем развернуть код на стороне сервера в модели с автоматическим размещением или размещением у поставщика. Обратите внимание, что эти решения с кодом полного доверия, которые развертываются в инфраструктуре, размещаемой у поставщика, также используют CSOM, но и могут использовать языки, например C#. Также важно отметить, что эти приложения, развернутые в модели, размещенной поставщиком, могут использовать другие технологические стеки и все еще использовать CSOM для взаимодействия с SharePoint.
Рабочим группам разработки, создающим отдельные компоненты или приложения, содержащие большое решение, понадобится централизованная цель развертывания для интеграции тестовых компонентов. Так как каждый разработчик создает компоненты или приложения на собственном сайте разработчика Office 365, необходимо подготовить к работе централизованное семейство веб-сайтов на целевом клиенте или в локальной среде, чтобы иметь возможность развертывать в них компоненты приложений каждого разработчика. Этот подход создаст централизованное место для тестирования интеграции компонентов решения. В разделе данного документа, посвященном тестированию, этот процесс рассматривается подробнее.
Разработка сайтов (удаленная разработка)
Организации или разработчики, которые решили не использовать сайты разработчика Office 365 как основное средство разработки приложений SharePoint, могут использовать локальные сайты разработчика для создания приложений SharePoint. В такой модели возможность сайтов разработчика Office 365 заменяется локальными сайтами разработчика, размещаемыми в ферме SharePoint. Клиенты могут создать частное облако разработки, развернув ферму SharePoint на экземплярах сайта разработчика в компании. Клиенты могут применять собственную автоматизацию управления, чтобы обеспечить создание шаблона сайта разработчика, или использовать возможности продукта SharePoint для подготовки к работе экземпляров сайта разработчика. Эта проиллюстрировано на рисунке 3.
Рис. 3. Локальная разработка приложения с шаблоном сайта разработчика
[
На рисунке 3 показаны средства разработки и типы приложений, доступные благодаря сайтам разработчика при использовании локальной фермы SharePoint в качестве узла. Обратите внимание, что средства разработки NapaOffice 365 нельзя использовать в этой среде, потому что такая возможность есть только на сайтах разработки Office 365.
Фермы SharePoint, на которых размещаются экземпляры Сайт разработчиков, должны отслеживаться и соответствовать целевым значениям для обслуживания, точки восстановления и времени, чтобы разработчики, использующие их для создания приложений, могли работать эффективно и без прерываний. Клиенты могут применять к этой среде концепции частного облака, например гибкость, масштабируемость и структура управления. Управление и операции должны применяться к ферме SharePoint, в которой также размещены сайты разработчика. Это поможет контролировать неотслеживаемую группу из многочисленных сайтов разработчика, которые устарели или не используются, и понимать, когда необходимо масштабировать среду.
Клиенты могут решить использовать возможности инфраструктуры как услуги (IaaS), например Microsoft Azure, чтобы размещать фермы SharePoint, в которых содержатся и размещены сайты разработчика, или свои собственные локальные виртуальные или физические среды. Обратите внимание, что для использования этой модели не требуется устанавливать SharePoint для каждого разработчика. Для удаленной разработки приложений требуются только инструменты разработки Visual Studio и Office и SharePoint на рабочей станции разработчика.
Разработчики должны установить инфраструктуру с размещением у поставщика, чтобы развертывать приложения, размещаемые у поставщика. Хотя размещаемые у поставщика компоненты приложения SharePoint могут быть реализованы на широком спектре технологий, разработчики должны подготовить инфраструктуру для размещения тех компонентов приложения, которые работают за пределами SharePoint. Например, если команда разрабатывает приложение SharePoint, компоненты взаимодействия с пользователем и другие компоненты находятся в приложении ASP.NET, группе разработчиков следует использовать локальные версии IIS, SQL Server и др., чтобы применять традиционные шаблоны коллективной разработки управления жизненным циклом приложения для ASP.NET.
Автономные среды фермы (разработка виртуальной фермы)
Для тех решений, которые требуют развертывания кода полного доверия для запуска в ферме SharePoint, потребуется полная (часто виртуализированная) реализация SharePoint. Инструкции по созданию локальной среды разработки для SharePoint см. в статье Настройка локальной среды разработки для надстроек SharePoint.
На рисунке 4 показаны типы приложений, которые можно создавать, используя локальную виртуализированную среду.
Рис. 4. Локальное развертывание с виртуальной средой
[
Разработчики могут удаленно развертывать SharePoint и размещаемые в облаке приложения в собственных фермах SharePoint, а также разрабатывать решения ферм с полным доверием. Эти фермы часто размещаются на сервере виртуализации, работающем на рабочей станции разработчика или в централизованном частном облаке виртуализации, к которому могут легко получать доступ разработчики. Среда фермы SharePoint обычно отделена от других ферм разработчиков и предоставляет уровень изоляции, необходимый при разработке кода полного доверия, который может требовать перезапуска критически важных служб (то есть IIS).
В автономной ферме можно выполнять удаленную разработку, а также разработку кода полного доверия, так как каждая ферма разработки является изолированной и выделенной для одного разработчика.
Организациям или разработчикам придется управлять фермами SharePoint, работающими на виртуальных компьютерах, и обновлять их. Для разработчиков, занимающихся одним приложением, необходимо поддерживать равенство в различных фермах разработки, работающих внутри виртуальных компьютеров. Такой подход гарантирует согласованность каждого компонента кода, разрабатываемого для приложения. Другим распространенным вопросом является стандартная конфигурация для ферм, включая доступ к домену и учетные данные, учетные данные приложения-службы, идентификаторы проверок или учетные записи и другие элементы конфигурации среды (например, сертификаты).
Подобно централизованной ферме для сайтов разработки эти виртуальные машины, на которых работают фермы разработчика SharePoint, могут размещаться на платформах IaaS, например Microsoft Azure, и предложениях локального частного облака.
Обратите внимание, что хотя виртуальные машины предлагают существенную изоляцию и независимость от других виртуальных машин разработчика, рабочим группам необходимо стремиться к поддержанию единообразия между конфигурациями виртуальных машин. Это включает общие настройки домена, учетных записей, безопасности и SharePoint, а также подключение к хранилищу системы управления версиями, например Visual Studio Team Foundation Server (TFS).
Особенности проектирования ALM
При создании приложений SharePoint необходимо учесть несколько аспектов, чтобы внедрить управление и общие методы разработки для единообразия и качества. Применяя принципы управления жизненным циклом приложения к разработке приложения SharePoint, разработчики должны сосредоточить внимание на технических аспектах и вопросах, связанных с процессами.
Обычно при разработке приложений требуется поддержка платформы управления жизненным циклом приложения, например Visual Studio Team Foundation Server 2012, особенно для групп разработчиков, занимающихся одним набором проектов. Для приложений SharePoint, как и других технических решений, требуется управление хранилищем кода и версиями, службы сборки, службы тестирования и методы управления выпусками. В следующем разделе описаны соображения по поводу применения управления жизненным циклом приложения к различным моделям приложений для приложений SharePoint.
Обзор
Соображения управления жизненным циклом приложения должны применяться к каждому типу приложений SharePoint без различий в концепции. Но необходимо настраивать методы и процедуры, касающиеся управления сборкой, тестированием и изменениями.
В некоторых приложениях SharePoint будут использоваться клиентские технологии. Большинству разработчиков, имеющих опыт разработки приложений SharePoint Server 2010, будет необходимо приспосабливаться к разработке и применению принципов управления жизненным циклом приложения к некомпилированному коду. Это включает применение таких концепций, как "сборка", к решению, в котором может не быть скомпилированного кода. В платформах управления жизненным циклом приложения, например Visual Studio 2012, есть встроенные средства проверки сборок, которые сначала компилируют код, а затем запускают тесты проверки сборки.
Процесс сборки и тестирования приложений SharePoint должен оставаться согласованным с традиционными процессами разработки приложений. Это включает создание плана сборки платформой управления жизненным циклом приложения, который скомпилирует решение и развернет его в целевую среду.
Процессы сборки
Платформа управления жизненным циклом приложения упрощает процессы сборки приложений SharePoint. Visual Studio Team Foundation Server 2012 предлагает услуги сборки и тестирования, которые могут запускаться при возврате решений из Visual Studio 2012 (непрерывная интеграция) или с определенными запланированными интервалами.
Компоненты сборки SharePoint
Планируя процессы сборки для разработки приложений SharePoint, разработчикам необходимо учитывать взаимодействия между компонентами, как показано на рисунке 5.
Рис. 5. Компоненты сборки приложения, размещаемого в SharePoint
На рисунке 5 проиллюстрировано логическое представление приложения SharePoint. На этой иллюстрации показано Надстройки, размещаемые в SharePoint и выделены ключевые объекты приложения в составе проекта Visual Studio 2012Надстройки, размещаемые в SharePoint. Проект приложения SharePoint содержит функции, пакет и манифест, которые будут зарегистрированы в SharePoint. Проект также содержит страницы, библиотеки сценариев и другие элементы взаимодействия с пользователем, которые составляют приложение SharePoint. Кроме того, в проекте SharePoint есть поддерживающие файлы, которые включают сертификаты, необходимые для развертывания в целевую среду SharePoint.
Рисунок 6. Компоненты сборки приложения с автоматическим размещением и размещением у поставщика
На рисунке 6 показано приложение SharePoint с размещением в облаке (то есть с автоматическим размещением или с размещением у поставщика). Основное различие в структуре проекта заключается в том, что решение Visual Studio 2012 содержит проект приложения SharePoint в дополнение к одному или нескольким проектам, содержащим компоненты приложения, размещенные в облаке. К ним могут относиться веб-приложения, проекты баз данных SQL или приложения-службы, которые будут развернуты в Azure, или размещенной локальной инфраструктуре поставщика (например, ASP.NET) и другие компоненты решения. Рекомендации по упаковке и развертыванию приложений с высоким уровнем доверия см. в статье Упаковка и публикация надстроек SharePoint с высоким уровнем доверия.
Рис. 7. Управление жизненным циклом приложения с Visual Studio Team Foundation Server
На рисунке 7 показан TFS в качестве платформы управления жизненным циклом приложения. Рабочие группы будут применять TFS для хранения кода и коллективной разработки, используя локальные или размещаемые в облаке службы TFS корпорации Майкрософт. TFS можно настроить для выполнения действий по сборке и развертыванию приложений SharePoint с помощью определений сборок. TFS также можно использовать для проведения тестов проверки сборки (BVT), которые можно автоматизировать путем выполнения выраженных с помощью кода тестов пользовательского интерфейса, которые входят в определение сборки.
Рис. 8. Цели сборки TFS
На рисунке 8 показаны целевые среды, в которых сценарии, выполняемые определением сборки TFS, будут развертывать компоненты приложения SharePoint. Для приложений, размещаемых в SharePoint, это включает развертывание в SharePoint Online или локальные каталоги приложений SharePoint.
Для приложений SharePoint, размещаемых в облаке, компоненты решения, требующие дополнительной инфраструктуры за пределами SharePoint, развертываются в целевые среды. Для приложений с автоматическим размещением это будет Microsoft Azure. Для приложений с размещением у поставщика такой инфраструктурой может быть Microsoft Azure или другие локальные или размещаемые в IaaS среды.
Создание сборки для приложений SharePoint
TFS предоставляет службы сборки, которые могут компилировать решения, возвращенные в систему управления версиями, и помещать результат в централизованное заданное место для автоматического развертывания в целевые среды. Основной метод настройки TFS для автоматизированных сборок, развертываний и тестирования приложений SharePoint заключается в создании определения сборки в Visual Studio. Определение сборки содержит информацию о том, какие проекты кода следует компилировать, и действиях после компиляции, таких как тестирование и фактическое развертывание в целевые среды. Дополнительные сведения о службе сборки Team Foundation см. в разделе Настройка Службы сборки Team Foundation.
Для непрерывной интеграции определение сборки может запускаться, когда разработчики возвращают код. Кроме того, можно запланировать выполнение определения сборки с установленными интервалами.
Для приложений SharePoint разработчики должны использовать проект непрерывной интеграции Office/SharePoint с определениями сборок TFS 2012 для выполнения запланированных сборок или непрерывной интеграции. Этот проект содержит определения сборок, сценарии Windows PowerShell и инструкции по процессу настройки служб Visual Studio Team Services или локальной версии TFS для создания и развертывания приложений SharePoint в модели непрерывной интеграции. Разработчики должны загрузить компоненты в этом проекте и соответствующим образом настроить свой экземпляр TFS. Инструкции по настройке TFS с предоставленным определением сборки для приложений SharePoint и настройке определения сборки для использования сценариев Windows PowerShell для развертывания приложения SharePoint в целевой среде см. в документации по непрерывной интеграции Office / SharePoint с TFS 2012.
Настройка процедур сборки и развертывания
На рисунке 9 показан стандартный процесс для сборок и развертываний приложения SharePoint, когда определение сборки создано, настроено и развернуто в экземпляр TFS рабочей группы.
Рис 9. Процесс сборки и развертывания с TFS
[
Разработчик проверяет решение Приложения SharePoint Visual Studio 2012. В зависимости от требуемой конфигурации (то есть непрерывной интеграции или запланированной сборки) службы сборки TFS будут выполнять шаги, определенные определением сборки приложения SharePoint. Это определение, настроенное разработчиками, содержит шаблон процесса сборки непрерывной интеграции, а также инструкции после сборки для выполнения Windows PowerShell скриптов для развертывания приложений. Обратите внимание, что для развертывания приложения в SharePoint Online потребуются расширения командной консоли SharePoint Online. Дополнительные сведения о расширениях оболочки управления SharePoint Online см. на странице SharePoint Online Management Shell в Центре загрузки.
Как только будет активирована сборка, TFS скомпилирует проекты, связанные с приложением SharePoint, и выполнит сценарии Windows PowerShell, чтобы развернуть решение в целевую среду SharePoint.
Доверие к приложению SharePoint
После развертывания компонентов приложения в целевую среду важно обратить внимание, что прежде чем кто-либо получит доступ к приложению, включая автоматические тесты, которые могут быть частью сборки, администратор клиента (или семейства сайтов) должен указать доверие для приложения на странице информации о приложении в SharePoint. Это требование применяется к приложениям с автоматическим размещением и размещением в SharePoint. Этот выполняемый вручную процесс представляет собой изменение в процессе сборки, так как понадобится приостановить тесты, которые обычно выполняются после развертывания в целевую среду, пока не будет указано доверие для приложения.
Обратите внимание, что для размещаемых в облаке (автоматически или у поставщика) приложений разработчики могут развертывать компоненты, не относящиеся к SharePoint, в инфраструктуру с размещением в облаке отдельно от пакета приложений, развернутого в SharePoint.
Рис. 10. Развертывание компонентов, не относящихся к SharePoint
[
Как показано на рисунке 10, когда разработчики вносят изменения в решение, представляющее приложение SharePoint, могут возникать условия, в которых изменения проектов в рамках решения не распространяются на сам проект приложения SharePoint. При таких обстоятельствах нет необходимости повторно развертывать проект приложения SharePoint, так как он не изменился. Изменения, связанные с размещаемыми в облаке проектами, должны быть повторно развернуты.
Можно внести изменения в приложение, которое будет развернуто в инфраструктуру вне SharePoint, отдельно от компонентов приложения, которые развертываются в целевое семейство сайтов или клиент. Для разработчиков это означает, что можно создать процесс автоматической сборки, чтобы развертывать размещаемые в облаке компоненты часто (путем активации) и отдельно от проекта приложения SharePoint. Таким образом, не требуется выполнять вручную действия по утверждению разрешения для приложения на странице информации о приложении в SharePoint, что позволяет более выполнять непрерывные процессы развертывания и тестирования для определения сборки. Компонент приложения SharePoint решения необходимо развертывать только в ситуации, когда элементы этого проекта изменяются и требуют развертывания.
Тестирование
Как описано в разделе о процессах сборки, тестирование приложения — это метод определения того, успешно ли выполнена компиляция и развертывание приложения. Используя тестирование в качестве средства проверки сборки и развертывания приложения, рабочая группа получает представление о качестве, а также узнает о том, когда последние изменения в коде приложения привели к ошибкам в приложении SharePoint.
На рисунке 11 показаны типы подходов тестирования, которые лучше всего использовать с моделями приложений SharePoint.
Рис. 11. Подходы к тестированию
[
На рисунке 11 показано использование различных типов тестов для тестирования приложений SharePoint по типу. Закодированные тесты пользовательского интерфейса следует выполнять для приложений с размещением в SharePoint, где бизнес-логика и пользовательский интерфейс размещаются в одном слое. Тогда как бизнес-логика может быть абстрагирована в библиотеки JavaScript, основным средством тестирования является испытание логики в работе пользователями.
Размещаемые в облаке приложения (то есть, с автоматическим размещением и размещением у поставщика) могут использовать полностью закодированные тесты пользовательского интерфейса, при этом также используя модульные тесты для проверки компонентов служб решения. Благодаря этому разработчик может быть уверен в качестве реализации размещаемой инфраструктуры приложения с функциональной точки зрения.
В следующих сценариях рассматриваются вопросы закодированных тестов пользовательского интерфейса и других типов тестов в отношении приложений SharePoint.
Клиентский код и тесты с закодированным пользовательским интерфейсом
Для тестирования проверки сборки (BVT) и полного тестирования системы рекомендуется использовать закодированные тесты пользовательского интерфейса. В них используются записанные действия для тестирования не только бизнес-логики и среднего уровня приложения, но и взаимодействия с пользователем. Для приложений SharePoint, использующих клиентский код, большая часть точек входа и выполнения бизнес-логики может существовать на уровне взаимодействия с пользователем. Поэтому с помощью закодированных тестов пользовательского интерфейса можно проверять не только взаимодействие с пользователем, но и бизнес-логику приложения. Дополнительные сведения о закодированном тесте пользовательского интерфейса см. в разделе Проверка кода с помощью модель автоматизации пользовательского интерфейса.
Закодированные тесты пользовательского интерфейса можно использовать в Надстройки, размещаемые в SharePoint, в которых может быть объединена значительная часть пользовательского интерфейса с бизнес-логикой. Эти тесты, как и другие, можно запускать из определения сборки в TFS, чтобы проверять с их помощью функциональные возможности приложения после развертывания (и приложение является доверенным для SharePoint).
Некодированные тесты пользовательского интерфейса
В ситуациях, когда логика приложения находится вне уровня пользовательского интерфейса приложения, например в приложениях, размещенных в облаке, следует использовать комбинацию из закодированных и незакодированных тестов пользовательского интерфейса. Можно использовать тесты, например традиционные модульные тесты, для проверки качества сборки логики службы, реализованной в инфраструктуре, размещенной у поставщика. Благодаря этому разработчик получает полную уверенность в размещаемых у поставщика компонентах функции решения, которые также охватываются тестами.
Веб-производительность и нагрузочные тесты
Веб-тесты производительности и нагрузочные тесты предоставляют разработчикам уверенность в том, что нагрузка пользователей на функции приложения меньше ожидаемое или прогнозируемой. Такое тестирование включает определение возможности приложения параллельно обрабатывать прогнозируемую базу пользователей, которая будет изменяться со временем. Как закодированные тесты пользовательского интерфейса, так и модульные тесты можно использовать как веб-тесты производительности и нагрузочные тесты. С помощью платформ управления жизненным циклом приложения, например TFS, эти тесты можно использовать для нагрузочного тестирования приложения.
Обратите внимание, что тестирование инфраструктуры не является главной целью этих тестов, когда они используются для проверки приложений SharePoint. Для инфраструктуры (с размещением в SharePoint или у поставщика) необходимо установить аналогичную базу нагрузки и производительности. Веб-тесты производительности и нагрузочные тесты для приложения определяют проблемы инфраструктуры, но их следует рассматривать в первую очередь как средства тестирования производительности приложения.
Дополнительные сведения о веб-тестах производительности и нагрузочных тестах см. в статье Выполнение тестов производительности в приложении перед выпуском.
Качество и условия тестирования
Во многих организациях есть несколько сред тестирования, которые могут быть физическими или виртуальными и отдельными друг от друга. Эти среды могут различаться в зависимости от процесса управления жизненным циклом приложения, законодательных требований и комбинации обоих этих факторов. Чтобы определять количество и типы тестовых сред, которые следует использовать рабочим группам, следующее руководство основывается на функциональных методиках, свойственных приложениям SharePoint, а также использует общие методики управления жизненным циклом приложения для разработки программного обеспечения.
Тестирование разработчика
Тестирование силами разработчиков можно применять в средах, где разработчики создают свой компонент решения. Многие разработчики, работающие над различными аспектами или компонентами более крупного приложения, будут проводить собственные модульные тесты, закодированные тесты пользовательского интерфейса и развертывание кода приложения на своих сайтах разработки.
Рисунок 12. Процесс тестирования силами разработчиков
[
Разработчики выполняют проверки Visual Studio для компонентов решения, развернутых на собственном сайте Office 365 или локальном сайте разработчика. Тесты для приложений, размещаемых в облаке, также будут выполняться из Visual Studio на компонентах решения, находящихся в инфраструктуре, размещаемой у поставщика. Эти компоненты будут находиться в подписке Microsoft Azure разработчика.
Обратите внимание, что для этого подхода предполагается, что у разработчиков есть как индивидуальные сайты разработчика Office 365, так и подписки Microsoft Azure, предоставляемые через подписки MSDN. Даже если разработчики создают приложения для локального развертывания, эти службы разработчика можно использовать для разработки и тестирования.
Если у разработчиков нет этих служб или им необходимо выполнять всю разработку локально, они будут выполнять тесты для своих компонентов на семействе сайтов разработчика локальной фермы и в зависящей от разработчика инфраструктуре, размещаемой у поставщика. Инфраструктура, размещаемая у поставщика, может находиться на выделенных виртуальных машинах разработчика. Для разработки решений полного доверия разработчикам будет необходима собственная виртуальная ферма SharePoint и размещаемая у поставщика инфраструктура.
Интеграция и тестирование систем
Для тестирования приложения все компоненты разработки должны быть собраны и развернуты в централизованной среде. Эта среда интеграции предоставляет место, где разработчики могут развертывать созданные ими компоненты решения и наблюдать за их взаимодействием с другими компонентами решения, написанными другими разработчиками.
Рисунок 13. Среда тестирования интеграции
[
Для этого типа тестирования платформа ALM будет создавать и развертывать приложение SharePoint и все необходимые компоненты в целевых средах. Для приложений, размещенных на SharePoint, это будет либо сайт Office 365, либо локальное семейство сайтов IaaS SharePoint, специально созданное для интеграции и тестирования систем. Для приложений SharePoint, размещаемых в облаке, TFS также будет развертывать компоненты в централизованную подписку Microsoft Azure, где службы будут специально настроены для тестирования интеграции или систем. Затем TFS выполнит закодированные тесты пользовательского интерфейса или модульные тесты приложения SharePoint и других компонентов, необходимые для решения в размещаемой инфраструктуре.
UAT и QA тестирование
Для приемочного тестирования пользователями у организаций часто есть отдельные среды, где эта функция выполняется отдельно от тестирования интеграции и систем. Разделение этих сред тестирования позволяет избежать влияния срока автоматического постоянного выпуска и тестирования на действия приемочного тестирования пользователями, когда пользователи могут выполнять тесты на определенной сборке приложения в течение длительного срока.
Рисунок 14. Приемочное тестирование пользователями
[
Как показано на рисунке 14, пользователи, которым поручено проводить приемочное или организационное тестирование, выполняют тестовые сценарии в стабильной среде, которая фокусируется на известной сборке приложения. Пока будет выполняться развертывание и тестирование кода в интегрированной среде, пользователи будут вручную проводить тесты для проверки того, соответствует ли приложение необходимым вариантам использования или тестовым случаям. Приложение и размещаемая у поставщика среда будет развернута (обычно выполняется диспетчером выпусков) в эту тестовую среду. Автоматическое развертывание также возможно. В таком виде развертывания используется выделенное определение сборки приемочного тестирования пользователями в сервере TFS, который зеркалирует сервер, выполняющий развертывание для тестирования интеграции и среды тестирования систем.
Для инфраструктуры, размещаемой в облаке, можно выполнять развертывание в подписку Microsoft Azure, используемую совместно с тестовой средой интеграции или систем, если службам присвоены имена и они настроены для параллельного развертывания в качестве отдельных служб или баз данных. Этот подход предлагает набор служб и баз данных в подписке тестирования Microsoft Azure для тестирования интеграции и систем, а также приемочного тестирования пользователями и тестирования контроля качества, как показано на рисунке 15.
Рисунок 15. Тестирование интеграции и приемочное тестирование пользователями
[
Практика продвижения кода
Процесс распространения кода между средами разработки и тестирования, а также рабочей средой должен выполняться с использованием хорошо определенного процесса управления выпусками. На рисунке 16 показано, как разработчики развертывают компоненты своего решения в среды разработки для модульного тестирования.
Рисунок 16. Процесс управления выпусками
[
После возврата в TFS процедура автоматической сборки компилирует и развертывает решения в целевой среде тестирования интеграции и систем, где в рамках определения сборки в TFS выполняются соответствующие проверки. Этот подход включает развертывание компонентов решения, размещаемых у поставщика, в целевую среду (Microsoft Azure или локальные среды). Обратите внимание, что для инфраструктуры Microsoft Azure можно использовать ту же подписку Microsoft Azure, которая использовалась для тестирования интеграции и системы, приемочного тестирования пользователями и тестирования контроля качества, предполагая, что они развернуты в различных пространствах имен и отдельных базах данных SQL.
Диспетчер выпусков или отдельное определение сборки TFS, в большинстве случаев запускаемое вручную, может развертываться в среду агента пользователя или TQA. Этот подход помогает контролировать версию сборки, которую будут тестировать пользователи. Диспетчеры выпусков могут комплектовать сборки из общей папки TFS и самостоятельно выполнять процесс развертывания. Управление выпусками будет применяться в течение всего процесса, от распространения до выпуска, для развертывания приложения в рабочей среде и отслеживания его установки и проверки сборки путем тестов.
Обновление и обновление приложений
У корпорации Майкрософт есть специальное руководство по обновлению приложений разработчиками. Платформа SharePoint поддерживает уведомление пользователей о новых версиях приложений.
Рекомендации по созданию стратегии обновления приложений SharePoint и установки исправлений см. в статье Обновление надстроек SharePoint.
Рекомендуемый шаблон изменений приложений согласуется с имеющимися шаблонами разработки кода и инженерной поддержки. Это включает упорядоченное ветвление и объединение устранений ошибок и разработки компонентов, а также добавочных развертываний в целевые каталоги приложений. Предыдущее руководство можно использовать для внесения изменений в приложения для SharePoint и их развертывания в целевые каталоги приложений или магазин.
Сведения о процессе обновления надстроек SharePoint содержат дополнительные тактические рекомендации по методам обновления приложений SharePoint. Это включает ускорение тестирования развертывания путем сокращения цикла обновления, в ходе которого обновления приложения отражаются в ферме в тестовых средах. Кроме того, в этой статье приведено руководство по согласовывать состояние в различных моделях развертывания приложений.