Групповая разработка в SharePoint Framework
SharePoint Framework — это новая модель разработки настроек SharePoint. В отличие от других доступных на сегодняшний день моделей разработки SharePoint, SharePoint Framework ориентирована на разработку на стороне клиента и основана на популярных средствах с открытым кодом, таких как Gulp и webpack. Одним из больших преимуществ этого изменения является то, что разработчики на любой платформе могут создавать настройки SharePoint.
SharePoint Framework — это модель разработки и, несмотря на различия в основной технологии, к ней применяются те же понятия, что и к другим моделям разработки SharePoint, использовавшимся в прошлом. Разработчики создают и проверяют решения с помощью цепочки инструментов SharePoint Framework, а затем сдают пакет решения, который развертывается на клиенте SharePoint для дополнительной проверки и выпуска.
SharePoint Framework состоит из нескольких пакетов. Эти пакеты, каждый из которых находится на собственной стадии разработки, составляют выпуск SharePoint Framework. Например, общедоступная версия SharePoint Framework, выпущенная в феврале 2017 г., состоит из следующих пакетов версии 1.0.0:
- @microsoft/sp-client-base
- @microsoft/sp-core-library
- @microsoft/sp-webpart-base
- @microsoft/sp-build-web
- @microsoft/sp-module-interfaces
- @microsoft/sp-webpart-workbench
Проект, предназначений для определенного выпуска SharePoint Framework, должен ссылаться на правильные версии пакетов. При создании новых проектов генератор Yeoman автоматически добавляет необходимые ссылки на пакет из соответствующего выпуска SharePoint Framework. Но при переносе проекта на новую версию SharePoint Framework разработчики должны правильно обновить номера версий пакетов SharePoint Framework.
Подготовка среды разработки
Для создания SharePoint Framework разработчиков решений на компьютерах разработки требуются специальные инструменты. В отличие от других моделей разработки SharePoint, SharePoint Framework не ограничивает разработчиков в выборе средств и операционной системы.
Разработчики могут настроить среду разработки несколькими способами. Каждый из них имеет свои преимущества, и важно, чтобы команды разработчиков были знакомы со всеми вариантами.
Цепочка инструментов SharePoint Framework
При создании решений SharePoint Framework необходимо использовать определенный набор инструментов. Ниже представлен основной набор инструментов, обязательный для всех сред разработки SharePoint Framework.
Node.js
На компьютере разработчика должна быть установлена платформа Node.js. Node.js используется как среда выполнения для средств разработки и упаковки проекта. Node.js устанавливается на компьютере разработчика по всему миру, и при необходимости существуют решения для поддержки нескольких версий Node.js параллельно.
Дополнительные сведения см. в статье Как настроить среду разработки SharePoint Framework
NPM
npm — это аналог NuGet в проектах .NET: он позволяет разработчикам приобрести и установить пакеты для использования в проектах SharePoint Framework. npm также используется для установки цепочки инструментов SharePoint Framework. Обычно разработчики используют последнюю версию npm и устанавливают ее глобально на компьютере. Npm — это пакет Node.js, поэтому, если вы используете несколько версий Node.js одновременно, для каждой будет установлена собственная версия npm.
Gulp
Gulp является эквивалентом MSBuild в проекте .NET и отвечает за выполнение таких задач, как создание или упаковка проекта SharePoint Framework. Gulp распространяется как пакет Node.js и обычно устанавливается глобально с помощью npm.
Yeoman и генератор SharePoint Framework Yeoman
Разработчики создают проекты SharePoint Framework с помощью Yeoman и генератора SharePoint Framework Yeoman. Yeoman и генераторы распространяются в виде пакетов Node.js и обычно устанавливаются глобально с помощью npm. Преимущество глобальный установки заключается в том, что разработчики могут установить Yeoman и генераторы один раз и использовать их для создания проектов.
Генератор Yeoman связан с определенной версией SharePoint Framework. Проекты, созданные с помощью генератора, ссылаются на определенные версии пакетов SharePoint Framework, а созданные веб-части — на определенные части платформы. Генератор SharePoint Framework Yeoman используется для создания проектов, а также для добавления веб-частей в существующие проекты. Если установить ее глобально и добавить новую веб-часть в существующий проект, созданный ранее, новая веб-часть может быть несовместима с остальной частью проекта, что может даже привести к ошибкам сборки. Это ограничение можно обойти несколькими способами, которые рассматриваются далее в этой статье.
TypeScript
SharePoint Framework использует TypeScript, чтобы разработчики могли работать эффективнее, оптимизируя написание кода и находя ошибки во время самой разработки. SharePoint Framework проекты поставляются с собственной версией TypeScript, которая используется в процессе сборки и не требует, чтобы разработчики устанавливали ее отдельно.
Создание среды разработки SharePoint Framework
В прошлом в качестве среды разработки SharePoint обычно использовались виртуальные машины. Они позволяли создать решение, которое точно будет работать в среде, используемый в определенной организации. На виртуальных машинах разработчики устанавливали SharePoint и обновляли его в соответствии с рабочей средой, используемой в конкретной организации. В некоторых случаях они устанавливают дополнительное программное обеспечение в соответствии с целевой средой, в которой решение будет работать как можно ближе. Этот подход был сложным и подразумевал управление различными средами, но позволял разработчикам раньше находить ошибки, вызываемые разницей в средах.
Переход на решения разработки для облака только частично решил эти проблемы. Разработчикам больше не нужно было запускать ферму SharePoint на своих компьютерах разработки, но им приходилось учитывать способ размещения решения и взаимодействия с SharePoint Online.
Так как SharePoint Framework фокусируется на разработке на стороне клиента, на компьютерах разработки больше не требуется устанавливать SharePoint. За редким исключением, все зависимости от платформы и другие пакеты указываются в проекте и содержатся в папке проекта. Поскольку SharePoint Framework имеет свое происхождение в облаке и часто развивается, разработчики должны убедиться, что они используют правильную версию цепочки инструментов, соответствующую их SharePoint Framework проекту.
Общая или личная среда разработки
Среди настроек SharePoint есть как простые сценарии, добавляемые прямо на страницу, так и сложные решения, развертываемые как пакеты решений. SharePoint Framework — это модель разработки, предназначенная для структурированной и стандартной модели развертывания настроек SharePoint. При создании решений SharePoint Framework каждый разработчик в команде использует собственную среду разработки и делится исходным кодом проекта с другими разработчиками через систему управления версиями. Таким образом, разработчики могут одновременно работать над тем же проектом и тестировать свое решение, не влияя на производительность друг друга.
В прошлом многим организациям было сложно оправдать предоставление разработчикам SharePoint мощных компьютеров разработки, и в некоторых случаях нескольким разработчикам приходилось совместно использовать один и тот же компьютер за счет производительности. С помощью SharePoint Framework разработчики могут использовать стандартные для рынка компьютеры разработчиков для создания настроек SharePoint.
Разработка на хост-компьютере
Вероятно, самый простой вариант настройки среды разработки для SharePoint Framework проектов — установить все средства непосредственно на хост-компьютере. Если ваша команда работает только над проектами SharePoint Framework, разработчики могут установить Node.js на своих компьютерах. Если они работают с другими Node.js проектами, они могут использовать сторонние решения, такие как nvm , для параллельного запуска нескольких версий Node.js.
После средств, необходимых для цепочки инструментов SharePoint Framework, разработчики устанавливают Yeoman и генератор Yeoman для SharePoint Framework. Обычно оба эти средства устанавливаются глобально. Так как генератор Yeoman для SharePoint Framework связан с определенной версией SharePoint Framework, разработчикам может потребоваться удалить генератор, а затем установить версию для проекта, над которым они работают в данный момент. Более целесообразно установить Yeoman глобально, а генератор Yeoman для SharePoint Framework — локально в проекте. Несмотря на определенные издержки, таким способом разработчики могут обеспечить совместимость новых элементов с остальной частью проекта.
Преимущество разработки на узле заключается в том, что разработчики могут настроить свой компьютер в зависимости от своих предпочтений один раз и использовать его во всех проектах. Кроме того, когда программное обеспечение выполняется на узле, оно имеет прямой доступ к ЦП, памяти и дисковому вводу-выводу без уровня виртуализации между ними, что приводит к более высокой производительности, чем при запуске того же виртуализированного программного обеспечения.
Разработка на виртуальной машине
В прошлом наиболее распространенным подходом среди разработчиков SharePoint было использование виртуальных машин в качестве основной среды разработки для создания решений SharePoint. С помощью виртуальных машинах разработчики могли обеспечить соответствие разным требованиям к разным проектам.
При создании решений в SharePoint Framework организации получают те же преимущества, что и при создании решений SharePoint в прошлом. С помощью виртуальных машин можно изолировать программное обеспечение разработки от операционной системы узла, что является распространенным требованием, особенно в крупных организациях. Создав отдельную виртуальную машину для каждого проекта, разработчики могут убедиться, что используемая цепочка инструментов совместима с проектом, даже если им потребуется выбрать конкретный проект в будущем.
Использование виртуальных машин не лишено недостатков. Виртуальные машины являются большими и требуют, чтобы разработчики использовали компьютеры, достаточно мощные, чтобы выполнять их с приемлемой производительностью. Кроме того, особенно в течение более длительных периодов времени, разработчики должны поддерживать операционную систему в актуальном состоянии и обеспечивать выполнение всех необходимых обновлений для системы безопасности. По мере того как разработчики работают на виртуальной машине, они либо должны потратить некоторое время в начале нового проекта, чтобы настроить стандартную виртуальную машину в своих предпочтениях, либо уступить стандартной настройке за счет их производительности. Так как виртуальные машины работают под управлением полной операционной системы со всеми ее компонентами, гораздо сложнее обеспечить согласованность всех виртуальных машин, используемых всеми разработчиками в команде. По сравнению с другими средами разработки, создание решений SharePoint Framework с помощью виртуальных машин требует больше денег и времени.
Разработка с использованием Docker
Использование Docker — это интересный компромисс между разработкой на хост-компьютере и виртуальной машине. Docker — это технология виртуализации программного обеспечения, аналогичная виртуальным машинам с несколькими отличиями. Наиболее важные преимущества использования образов Docker по сравнению с виртуальными машинами заключаются в том, что образы Docker проще создавать, обслуживать и распространять, они более легкие (несколько сотен МБ по сравнению с десятками ГБ дискового пространства, необходимого для виртуальных машин) и позволяют разработчикам использовать средства и настройки, которые они уже установили и настроили на своем хост-компьютере.
Так же как на виртуальных машинах, в контейнерах Docker запускается виртуализированный экземпляр операционной системы (обычно на основе Linux). Все программное обеспечение, установленное в образе, используемом для создания контейнера, выполняется изолированно внутри этого контейнера и имеет доступ только к части файловой системы хост-компьютера. Так как все изменения, внесенные в файловую систему внутри контейнера Docker, отменяются после закрытия контейнера, разработчики используют общие папки на хост-компьютере для хранения исходного кода.
Дополнительные сведения см. в статье Использовании Docker для создания решений SharePoint Framework.
Схема разработки проектов SharePoint Framework
SharePoint Framework основана на цепочке инструментов с открытым кодом и соответствует общему рабочему процессу разработки, который присутствует в других проектах, построенных на том же стеке. Ниже описана схема разработки типичного проекта SharePoint Framework.
Создание проекта SharePoint Framework
При создании настроек SharePoint с помощью SharePoint Framework сначала формируется шаблон нового проекта SharePoint Framework. Для этого используется генератор SharePoint Framework Yeoman. Генератор попросит вас ответить на несколько вопросов о названии проекта или его расположении. Кроме того, с его помощью вы сможете создать первую веб-часть или расширение. Несмотря на то что вы можете выбрать другую платформу JavaScript для каждого из компонентов, в общем случае рекомендуется использовать не более одной платформы для каждого проекта SharePoint Framework.
Фиксирование версии зависимостей
Новый проект SharePoint Framework, сформированный генератором SharePoint Framework Yeoman, имеет зависимости от пакетов SharePoint Framework и других пакетов, необходимых для правильной работы. При создании веб-частей может потребоваться включить дополнительные зависимости, такие как Angular или jQuery. В проектах SharePoint Framework зависимости устанавливаются с помощью npm. Каждая зависимость — это пакет Node.js определенной версии. По умолчанию на зависимости ссылаются с помощью диапазона версий, который помогает разработчикам поддерживать их зависимости в актуальном состоянии. Результатом такого подхода является то, что восстановление зависимостей для одного и того же проекта в два момента времени может дать разные результаты, что может даже привести к нарушению проекта.
Чтобы избежать изменения зависимостей в проекте, основанном на цепочке инструментов с открытым кодом, заблокируйте версии всех зависимостей. При добавлении зависимости в проект разработчики могут установить зависимость определенной версии, а не диапазон версий, вызвав команду npm install с аргументом --save-exact.
Однако это никак не влияет на дочерние зависимости пакета. Чтобы заблокировать версии всех зависимостей и их дочерних зависимостей в проекте, разработчики могут использовать встроенную возможность блокировки файлов, поддерживаемую NPM. Дополнительные сведения см. в статье npm-package-locks: пояснения к файлам блокировок NPM.
Добавление проекта в систему управления версиями
Чтобы все члены команды могли работать над одним проектом, добавьте его в систему управления версиями. Необходимые действия зависят от системы, которую использует ваша команда.
Проекты SharePoint Framework создаются с файлом .gitignore, в котором указывается, какие файлы следует исключить из системы управления версиями. Если ваша команда использует систему управления версиями, отличную от Git (например, систему Visual Studio Team System с репозиториями Team Foundation System), убедитесь, что в систему управления версиями включаются соответствующие файлы из проекта. Кроме того, исключение зависимостей и созданных автоматически файлов во время сборки позволяет обеспечить эффективную работу команды.
Особенно важно не включать в систему управления версиями папку node_modules. Эта папка содержит пакеты, от которых зависит проект и которые автоматически устанавливаются при восстановлении зависимостей с помощью команды npm install. Некоторые пакеты компилируются в двоичные файлы, при этом процесс компиляции зависит от операционной системы. Если команда работает с другой операционной системой, включение папки node_modules в систему управления версиями, скорее всего, нарушит сборку для некоторых участников команды.
Получение проекта из системы управления версиями
При первом получении проекта из системы управления версиями вы получите исходный код проекта, но не библиотеки SharePoint Framework, необходимые для его сборки. Так же, как при работе с проектами .NET и использовании пакетов NuGet, сначала необходимо восстановить зависимости. В проектах SharePoint Framework, так же как во всех проектах, основанных на Node.js, для этого необходимо выполнить команду npm install в командной строке. NPM использует сведения из файлов package.json и package-lock.json и установит все пакеты.
Примечание.
Обычно для восстановления зависимостей с помощью команды npm install необходимо подключение к Интернету, так как пакеты скачиваются с сайта https://registry.npmjs.org.
Если у вас есть проблемы с подключением к сети или реестр NPMJS недоступен, выполнить сборку не удастся. Обойти это ограничение можно несколькими способами. Вы можете скачать tar-архивы всех зависимостей с помощью команды shrinkpack и сохранить их в системе управления версиями. Shrinkpack автоматически обновляет файл npm-shrinkwrap.json для использования локальных tar-архивов, позволяя устанавливать зависимости проекта в автономном режиме.
Некоторые пакеты во время установки компилируются в двоичные файлы. Этот процесс зависит от архитектуры и операционной системы. Если вы восстановите зависимости в контейнере Docker под управлением Linux, а затем попробуйте выполнить сборку проекта на хост-компьютере с Windows, возникнет ошибка из-за несоответствия типа среды, используемого для сборки и выполнения двоичных файлов.
В ходе разработки решения в проект могут добавляться новые или обновленные зависимости. Если файл package.json изменился с момента последнего получения проекта из системы управления версиями, нужно выполнить команду npm install в командной строке, чтобы установить отсутствующие зависимости. Если вы не уверены, изменился ли файл package.json, вы можете выполнить команду npm install в командной строке, просто чтобы убедиться, что у вас есть последние зависимости, не нарушая работу проекта.
Добавление пакетов в проект
Использование существующих пакетов для выполнения определенных задач позволит повысить продуктивность. https://www.npmjs.com — это общедоступный реестр пакетов, которые можно использовать в проекте.
Важно!
Так как перед публикацией на сайте https://www.npmjs.com пакет не проходит проверку, перед использованием тщательно изучите его содержимое и лицензию.
Чтобы добавить пакет в проект SharePoint Framework, выполните команду npm install {package} --save или npm install {package} --save-dev в командной строке, например npm install angular --save. Использование аргумента --save или --save-dev гарантирует, что пакет будет добавлен в файл package.json и другие разработчики в команде также получат его при восстановлении зависимостей. Без него не удастся выполнить сборку проекта на другом компьютере. При добавлении пакетов, необходимых решению при запуске, например Angular или jQuery, используйте аргумент --save. При установке пакетов, необходимых в процессе сборки, например дополнительных задач Gulp, используйте аргумент --save-dev.
Если не указана версия, npm устанавливает последнюю версию, доступную в реестре пакетов (https://www.npmjs.com по умолчанию). Версию пакета необходимо указать, если вы используете файл npm-shrinkwrap.json и хотите обновить существующий пакет до новой версии. По умолчанию npm устанавливает версию, указанную в файле npm-shrinkwrap.json. Если в команде npm install указан номер версии, например npm install angular@1.5.9 --save, будет установлен этот пакет и обновлен номер версии в файле npm-shrinkwrap.json.
Работа с внутренними пакетами
По мере разработки клиентских решений вы, скорее всего, соберете общие библиотеки кода, которые захотите использовать во всех проектах. Во многих случаях такие библиотеки содержат проприетарный код, доступный за пределами организации только в пакетах, развернутых в рабочей среде. Ваша команда может использовать внутренние библиотеки в своих проектах SharePoint Framework несколькими способами.
Размещение частного реестра пакетов
В прошлом многие организации, создающие решения .NET, размещали частные репозитории NuGet на своих серверах, чтобы использовать систему управления пакетами NuGet для своих внутренних пакетов. Так как SharePoint Framework использует систему npm для управления пакетами, организации так же могут использовать частный реестр для своих внутренних пакетов. После публикации эти пакеты можно будет использовать во всех проектах организации.
Частный реестр пакетов можно разместить в облаке или на собственном сервере.
С помощью частного реестра пакетов организации могут централизованно управлять общим кодом, используемым в разный проектах. Составив отдельный план действий по добавлению изменений в общую базу кода, организации могут обеспечить высокое качество библиотеки и надлежащую эффектность использования для всех разработчиков.
Организации, использующие Visual Studio Team Services или Team Foundation Server, могут удобным способом создать частный реестр пакетов npm непосредственно в Visual Studio Team Services или Team Foundation Server. Организации, использующие другие системы управления источниками, могут использовать другие решения для размещения своих пакетов. Популярным облачным частным реестром является npm Enterprise. Организациям, которые хотят разместить реестр самостоятельно, предлагается на выбор несколько реализаций с открытым кодом, например Sinopia или ее развилка Verdaccio либо Nexus.
Примечание.
Разные подсистемы для размещения частных реестров пакетов находятся на разных стадиях разработки, и вам следует внимательно проверить, соответствует ли определенная подсистема вашим требованиям с точки зрения функций, лицензии и поддержки.
Чтобы упростить установку частного реестра пакетов и управление им, большинство подсистем предлагаются с готовыми образами Docker.
Связывание пакетов с помощью команды NPM link
Не обязательно использовать частный реестр — пакеты можно связывать. При этом не требуется настройка реестра, но требуется четкая координация действий на всех компьютерах для разработки и сервере сборки.
Сначала каждый разработчик в команде должен скачать копию общего пакета на свой компьютер для разработки. В командной строке они должны изменить рабочий каталог на каталог общего пакета, а затем выполнить команду npm link. Эта команда регистрирует пакет как глобальный пакет на этом компьютере для разработки. После этого разработчики должны изменить рабочий каталог на каталог проекта, в котором они хотят использовать общий пакет. Затем они устанавливают пакет так же, как и любой другой пакет, выполнив команду npm install {shared_package} --save в командной строке. Так как общий пакет установлен глобально, npm будет использовать эту версию для установки пакета. На этом этапе пакет установлен так же, как любой другой общедоступный пакет, и разработчики могут выбрать способ связывания пакета с проектом.
Связывание пакета необходимо выполнить на всех компьютерах для разработки, а также на сервере сборки. Если общий пакет не связан с помощью команды npm link, восстановление зависимостей проекта разрушит сборку.
Полезно ссылаться на связанные пакеты в начале проекта при одновременной разработке общего пакета и проекта. Благодаря связыванию не нужно публиковать новую версию пакета в реестре, чтобы использовать последний код в проекте. Обратите внимание, что если разработчики будут ссылаться на версию общей библиотеки, измененную локально и не добавленную в систему управления версиями, это разрушит сборку для остальных членов команды.
Сочетание частного реестра пакетов и связывания пакетов
Связывание пакетов можно сочетать с частным реестром. Например, можно работать таким образом, чтобы разработчики ссылались на связанный пакет, а сервер сборки извлекает общую библиотеку из частного реестра. С точки зрения проекта ничего не меняется: ссылку на пакет в файле package.json можно обработать как из связанного пакета, так и из частного реестра. Команде остается только публиковать последние изменения в общей библиотеке в частном реестре перед выполнением сборки.
Так как код общей библиотеки со временем стабилизируется и для отдельных проектов требуется меньше изменений, разработчики, скорее всего, будут просто ссылаться на опубликованный пакет из частного реестра, а не изменять его.
Обеспечение единообразия и качества кода
Часто командам разработчиков программного обеспечения тяжело обеспечить единообразие и высокое качество своих проектов. У разных разработчиков разные стили написания кода. В каждой команде есть квалифицированные специалисты и разработчики, у которых меньше опыта в определенной сфере. Кроме того, у многих организаций и отраслей есть требования, которым должно соответствовать программное обеспечение. Из-за всех этих задач разработчикам сложнее не выбиться из графика. Особенно перед сдачей проекта разработчики часто не обращают внимание на качество, что в долгосрочной перспективе оказывается хуже, чем не уложиться в сроки.
Выберите библиотеку JavaScript для команды и используйте стандарты кодирования
Если ваша команда не впервые создает настройки SharePoint, скорее всего, у вас есть стандарты кодирования, описывающие применяемые способы, а также средства и библиотеки, используемые в проектах. Использование стандартов кодирования позволяет обезличить код, что упрощает его восприятие другими членами команды. Кроме того, стандарты кодирования отражают многолетний опыт вашей команды, позволяя вам создавать настройки эффективнее и качественнее.
В отличие от других доступных на сегодняшний день моделей настройки, SharePoint Framework связана с клиентской разработкой. SharePoint Framework рекомендует использовать TypeScript, который позволяет разработчикам писать более качественный код и находить несоответствия уже в процессе сборки. Для этой же цели предназначены сотни клиентских библиотек. Если ваша команда не впервые выполняет разработку клиентских решений, вероятно, вы уже выбрали подходящую библиотеку. Если нет, советуем изучить информацию о наиболее популярных библиотеках и выбрать одну из них для команды или всей организации (рекомендуется).
Использование одной библиотеки во всех проектах позволяет легче адаптироваться новым членам команды и легче переключаться с одного проекта на другой. Опыт в разработке клиентских решений пригодится вашей организация во всех проектах. Стандартизация проектов по всей организации также сокращает срок выполнения заказов и снижает затраты на обслуживание проектов. Новые библиотеки публикуются в Интернете каждый день, и если постоянно переходить с одной на другую, вы не сможете эффективно работать и создавать качественные решения.
Стандартизация библиотек в организации также поможет оптимизировать работу решений. Так как во всей организации используется одна библиотека, пользователям нужно скачать ее всего один раз, что значительно сокращает время загрузки решений, повышая удобство использования.
Выбор одной из наиболее популярных библиотек позволяет воспользоваться знаниями и опытом других разработчиков, которые используют эту библиотеку в течение длительного времени и уже решили многие проблемы, которые могут возникнуть у вас самих. Кроме того, для наиболее популярных библиотек доступны стандарты кодирования, что может использовать ваша команда. Используя существующие рыночные стандарты для определенной библиотеки, вашей организации будет проще расширять команду, нанимая разработчиков и помогая им быстрее адаптироваться.
Например, для создания собственных решений на платформе SharePoint корпорация Майкрософт выбрала React. Кроме того, многие другие команды в корпорации Майкрософт, такие как OneDrive или Delve, используют React в своих проектах. Это не значит, что вы также должны использовать React во всех своих проектах SharePoint Framework, но подтверждает, что важно выбрать клиентскую библиотеку, которая подходит для вашей организации. Например, если у вашей команды есть опыт работы с Angular или Knockout, эта платформа может эффективно использоваться при создании решений SharePoint Framework.
Применение стандартов кодирования и правил на протяжении всего жизненного цикла решения
Использование стандартов кодирования дает очевидные преимущества, но одно их наличие не означает, что они активно используются на всех стадиях разработки и тестирования настройки SharePoint. Чем дольше разработчики не могут подтвердить, что решение соответствует стандартам кодирования и правилам организации и чем тяжелее вашей команде это сделать, тем дороже будет исправлять ошибки, найденные в проекте. Ниже описано несколько способов реализации плана управления для решения SharePoint в процессе разработки.
Линтинг
Линтинг — это процедура проверки кода на соответствие определенным правилам. По умолчанию проекты SharePoint Framework создаются с помощью TypeScript. При каждой сборке TSLint (анализатор кода для TypeScript) анализирует проект на соответствие стандартному набору правил и сообщает о несоответствиях. Разработчики могут выбирать активные правила и при необходимости создавать собственные.
Разработчики могут использовать линтинг не только для проверки содержимого файлов TypeScript. Анализаторы кода доступны для наиболее популярных языков, таких как CSS, JavaScript или Markdown, и если у команды есть определенные правила для этих языков, будет полезно реализовать их в анализаторе кода, чтобы они проверялись автоматически каждый раз, когда разработчик выполняет сборку проекта.
Автоматическое тестирование
С помощью автоматических тестов разработчики могут легко убедиться, что после применения последних изменений в проекте все элементы продолжают работать должным образом. Чем старше проект, тем важнее автоматические тесты: чем больше кодовая база, тем больше влияние каждого изменения и риск повреждения других фрагментов кода. Автоматические тесты позволяют разработчикам проверить работу решения и найти все возможные ошибки на ранней стадии.
SharePoint Framework поддерживает средство выполнения тестов Karma и платформу Mocha, на которой разработчики могут писать тесты. При необходимости разработчики могут использовать дополнительные элементы, доступные в SharePoint Framework, такие как Jest и PhantomJS, чтобы расширить сферу действия тестов. Все тесты в проектах SharePoint Framework можно выполнять с помощью стандартной задачи gulp test.
Анализ кода
Линтинг помогает проверить синтаксис конкретного файла, но часто разработчикам нужны другие средства для проверки проекта на соответствие правилам в целом. Обычно анализаторы кода делают акцент на коде, но пропускают контекст, представленный файлом кода. В решениях SharePoint Framework у артефактов есть особые требования, например идентификатор веб-части должен быть уникальным в проекте. Кроме того, у организаций могут быть другие требования, например "не ссылаться на сценарии из сеть доставки содержимого" или "использовать только определенную версию определенной библиотеки". Обычно анализаторы кода не могут это проверить, поэтому разработчикам нужны другие средства.
SharePoint Code Analysis Framework (SPCAF) — это стороннее решение, которое разработчики SharePoint, администраторы и сотрудники, ответственные за контроль качества и безопасность, часто используют для проверки настроек SharePoint на соответствие правилам организации. SPCAF интегрируется со всем процессом управления жизненным циклом приложений и позволяет организациям снизить общую стоимость владения настройками SharePoint. SPCAF содержит набор правил, предназначенных специально для решений SharePoint Framework.
Изменение проектов SharePoint Framework
Развертывание настройки SharePoint в рабочей среде обычно не означает конец ее жизненного цикла. Часто изменение или добавление требований приводит к изменениям в решении. Чтобы правильно обновить настройку, развернутую в рабочей среде, необходимо учитывать несколько факторов.
Семантическое версионирование (SemVer)
За редким исключением, SharePoint Framework использует семантическое версионирование (SemVer) для отслеживания номеров версий. Семантическое версионирование — это модель версионирования, которая широко применяется разработчиками программного обеспечения по всему миру. Номер SemVer состоит из трех цифр ОСНОВНОЙ.ДОПОЛНИТЕЛЬНЫЙ.ИСПРАВЛЕНИЕ и необязательных меток, например 1.0.1.
Примечание.
В настоящее время в SharePoint Frameworks можно использовать только три цифры без меток.
Различные части номера SemVer увеличиваются в зависимости от того, как изменяется решение:
- ОСНОВНОЙ, если изменения не совместимы с предыдущими версиями.
- ДОПОЛНИТЕЛЬНЫЙ, если добавлены функции, совместимые с предыдущими версиями.
- ИСПРАВЛЕНИЕ, если исправлены ошибки (изменения совместимы с предыдущими версиями).
Важно помнить, что семантическое версионирование — это всего лишь соглашение. Ваша команда может следовать ему, сообщая об изменениях в последнем выпуске.
Узнать больше о семантическом версионировании можно на сайте http://semver.org.
Увеличение номера версии
При обновлении решения SharePoint Framework разработчики должны увеличить номера версий изменившихся элементов, чтобы четко указать, какие элементы изменились и каковы последствия.
Увеличение версии пакета в файле package.json
Пакет SharePoint Framework имеет такую же структуру, как пакет Node.js. Его зависимости и метаданные хранятся в файле package.json в папке проекта. Одно из свойств в файле package.json представляет собой свойство версии и определяет версию всего проекта. По умолчанию все компоненты в текущем решении наследуют этот номер версии в качестве своего номера версии. Разработчикам следует увеличивать номер версии в файле package.json при каждом планировании нового выпуска проекта в соответствии с соглашением SemVer.
Увеличение версии пакета решения в файле package-solution.json
SharePoint Framework решения развертываются с помощью файла *.sppkg, установленного в каталоге приложений в клиенте SharePoint. Файл *.sppkg похож на пакет надстройки SharePoint и соответствует тем же правилам управления версиями. Текущая версия пакета *.sppkg определяется с помощью четырехкомпонентного (MAJOR. НЕЗНАЧИТЕЛЬНЫЕ. REVISION. BUILD) номер, хранящийся в файле config/package-solution.json . Для простоты разработчикам следует синхронизировать этот номер с номером версии в файле package.json, так как оба номера относятся к версии проекта в целом.
Примечание.
Увеличение номера версии в файле package-solution.json между выпусками необходимо для правильного развертывания новой версии пакета в SharePoint.
Изменение зависимостей
Проект SharePoint Framework может обновляться из-за изменения одной из базовых зависимостей, например выпуска новой версии Angular, в которой исправлены ошибки и повышена производительность. Если ваша команда придерживается рекомендуемого подхода с помощью npm shrinkwrap для блокировки версий зависимостей, вы будете использовать команду npm install {package}@{version} --save , чтобы обновить зависимость до определенной версии и протестировать проект, чтобы убедиться, что она работает должным образом с последними обновлениями. В зависимости от того, как изменения базовых зависимостей влияют на проект, обновление проекта может быть как исправлением, так и основным выпуском.
Важно!
Не изменяйте номер версии зависимостей в файле package.json вручную. Если вы используете файл блокировки, например npm shrinkwrap, ваши изменения в файле package.json вручную будут игнорироваться, а вместо этого будут использоваться номера версий, записанные в файлах блокировки, что приведет к трудно отслеживать ошибки в проекте.
Отслеживание изменений структуры проекта
При обновлении вашего проекта до более новой версии SharePoint Framework может потребоваться внести изменения в структуру и файлы конфигурации проекта. Прежде чем обновлять версии SharePoint Framework в зависимостях вашего проекта, всегда создавайте другой проект, используя версию SharePoint Framework, до которой вы хотите выполнить обновление, и тщательно сравнивайте его структуру и содержимое со структурой и содержимым структуры существующего проекта. Это позволит определить последствия обновления для вашего проекта и поможет избежать применения критических изменений в проекте.
Не используйте устаревшие пакеты npm
Один из способов, которыми можно выяснить, какие зависимости в вашем проекте необходимо обновить, заключается в выполнении команды npm outdated. Эта команда проверит дерево зависимостей и покажет, какие пакеты можно обновить. Несмотря на то что использовать эту команду удобно, следует делать это с осторожностью.
Начиная с SPFx версии 1.3, генератор Yeoman для SharePoint Framework позволяет указать, в каком расположении следует выполнить формирование шаблонов для проекта, который должен работать только в SharePoint Online либо и в SharePoint 2016 с пакетом дополнительных компонентов 2 и более поздней версии, и в SharePoint Online. В SharePoint, размещенном в локальной среде, используется более старая версия SharePoint Framework, а не последняя версия, применяемая в SharePoint Online. Если вы выполните команду npm outdated для проекта, совместимого с локальным SharePoint, она предложит обновить все основные пакеты SharePoint Framework до последних версий, опубликованных в npm. К сожалению, при обновлении этих пакетов до последних версий проект больше не будет работать с локальным SharePoint. Прежде чем обновлять версии пакетов SharePoint, всегда проверяйте, предназначен ли ваш пакет для работы с локальным SharePoint. Если предназначен, то какую версию SharePoint Framework необходимо поддерживать.
Сборка и упаковка проекта в режиме выпуска
После проверки работы решения выполните сборку проекта в режиме выпуска с помощью команды gulp bundle --ship. Затем создайте новый пакет, используя команду gulp package-solution --ship. Если не выполнена команда gulp bundle --ship, пакет будет содержать предыдущую версию проекта.
Развертывание новой версии решения
После сборки и упаковки проекта нужно его развернуть. Сначала разверните обновленные пакеты веб-части, расположенные в проекте в папке ./temp/deploy. Опубликуйте файлы рядом с пакетами предыдущей версии решения.
Примечание.
Не удаляйте предыдущие версии решения, пока их используют активные экземпляры веб-частей. Каждая версия пакетов имеет уникальное имя, и удаление предыдущих версий до обновления веб-частей нарушит работу этих веб-частей.
После этого разверните новый пакет решения в каталоге приложений SharePoint. Это необходимо, чтобы сообщить SharePoint о новой версии решения, которую он должен применить.