Compartir a través de

Desarrollo basado en equipos en SharePoint Framework

  • Artículo

SharePoint Framework es un nuevo modelo de desarrollo para crear personalizaciones de SharePoint. A diferencia de otros modelos de desarrollo de SharePoint disponibles hasta la fecha, el SharePoint Framework se centra en el desarrollo del lado cliente y se basa en herramientas de código abierto populares como Gulp y webpack. Una gran ventaja de este cambio es que los desarrolladores de cualquier plataforma pueden crear personalizaciones de SharePoint.

SharePoint Framework es un modelo de desarrollo y, a pesar de las diferencias en la tecnología subyacente, los mismos conceptos son válidos al usarlo para compilar soluciones, al igual que lo usaron en el pasado los desarrolladores de SharePoint de otros modelos de desarrollo. Los desarrolladores usan la cadena de herramientas de SharePoint Framework para compilar y probar sus soluciones y, cuando están preparadas, entregan el paquete de solución para su implementación en el espacio empresarial de SharePoint con el fin de realizar más pruebas y publicarlo.

SharePoint Framework está formado por diferentes paquetes. Estos paquetes, cada uno en su propia versión específica, componen una versión de SharePoint Framework. Por ejemplo, la versión de disponibilidad general de SharePoint Framework en el 2017 de febrero consta de las siguientes versiones de paquete de v 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

Para que un proyecto sea válido para una versión específica de SharePoint Framework, tiene que hacer referencia a todos los diferentes paquetes en las versiones correctas. Al realizar scaffolding a nuevos proyectos, el generador de Yeoman de SharePoint Framework agrega automáticamente todas las referencias necesarias al paquete desde la versión correspondiente de SharePoint Framework. Pero, al actualizar el proyecto a una versión más reciente de SharePoint Framework, los desarrolladores necesitan prestar atención especial para actualizar correctamente los números de versión de los paquetes de SharePoint Framework.

Preparar el entorno de desarrollo

Para crear SharePoint Framework desarrolladores de soluciones, necesita herramientas específicas en las máquinas de desarrollo. Al compararlo con otros modelos de desarrollo de SharePoint, SharePoint Framework es menos restrictivo y permite a los desarrolladores usar las herramientas con las que son más productivos, e incluso elegir el sistema operativo.

Los desarrolladores pueden elegir diferentes formas de configurar su entorno de desarrollo. Cada una de estas tiene diferentes ventajas y es importante que los equipos desarrolladores comprendan correctamente las diferentes opciones.

Cadena de herramientas de SharePoint Framework

Para crear soluciones de SharePoint Framework, los desarrolladores necesitan usar un conjunto de herramientas específico. En la lista siguiente se indica el conjunto de herramientas básico necesario en todos los entornos de desarrollo de SharePoint Framework.

Node.js

Para usar SharePoint Framework es necesario que Node.js esté instalado en el equipo del desarrollador. Node.js se usa como el tiempo de ejecución para las herramientas de tiempo de diseño usadas para crear y empaquetar el proyecto. Node.js se instala globalmente en la máquina para desarrolladores y hay soluciones disponibles para admitir la ejecución de varias versiones de Node.js en paralelo si es necesario.

Para obtener más información, consulte configurar el entorno de desarrollo de SharePoint Framework.

NPM

npm es el equivalente de NuGet en proyectos de .NET: permite a los desarrolladores obtener e instalar paquetes para usarlos en proyectos de SharePoint Framework. npm también se usa para instalar la cadena de herramientas de SharePoint Framework. Normalmente, los desarrolladores usarán la versión más reciente de npm y la instalarán de forma global en su equipo. Npm en sí es un paquete de Node.js, por lo que, si ejecuta varias versiones de Node.js en paralelo, cada una tendrá su propia versión de npm instalada.

Gulp

Gulp es el equivalente de MSBuild en el proyecto de .NET y es responsable de ejecutar tareas como compilar o empaquetar un proyecto de SharePoint Framework. Gulp se distribuye como un paquete Node.js y normalmente se instala globalmente mediante npm.

Yeoman y el generador de Yeoman de SharePoint Framework

Con Yeoman y el generador de Yeoman de SharePoint Framework, los desarrolladores pueden crear proyectos de SharePoint Framework. Tanto Yeoman como sus generadores se distribuyen como paquetes de Node.js y suele instalarse con npm como paquetes globales. La ventaja de una instalación global es que los desarrolladores pueden instalar Yeoman y los generadores una vez y usarlos para crear proyectos fácilmente.

El generador de Yeoman de SharePoint Framework está vinculado a una versión específica de SharePoint Framework. Los proyectos donde se aplica scaffolding con el generador hacen referencia a las versiones específicas de los paquetes de SharePoint Framework y los elementos web generados hacen referencia a las partes específicas del marco. El generador de Yeoman de SharePoint Framework se usa para crear proyectos, pero también para agregar elementos web a proyectos existentes. Si lo instala globalmente y tendría que agregar un nuevo elemento web a un proyecto existente creado en el pasado, el elemento web recién creado podría ser incoherente con el resto del proyecto que incluso podría provocar errores de compilación. Hay varias maneras en las que puede solucionar esta limitación, que en este artículo se describe más adelante.

TypeScript

SharePoint Framework usa TypeScript para ayudar a los desarrolladores a ser más productivos al escribir mejor código e identificar errores durante el desarrollo. SharePoint Framework proyectos se incluyen con su propia versión de TypeScript, que se usa en el proceso de compilación y que no requiere que los desarrolladores la instalen por separado.

Crear un entorno de desarrollo de SharePoint Framework

En el pasado, los desarrolladores de SharePoint solían usar máquinas virtuales como sus entornos de desarrollo. Las máquinas virtuales les permitían garantizar que la solución creada funcionaría en el entorno usado por esa organización específica. En las máquinas virtuales, los desarrolladores instalaban SharePoint y las revisiones correspondientes del mismo nivel que en el entorno de producción usado por la organización específica. En algunos casos, instalarían software adicional para que coincida con el entorno de destino donde la solución se ejecutaría lo más estrechamente posible. Este enfoque permitía a los desarrolladores identificar antes los errores causados por las diferencias en los entornos, pero aumentaba la complejidad por administrar los diferentes entornos.

Cambiar al desarrollo de soluciones para la nube solucionó estos problemas solo parcialmente. Aunque los desarrolladores ya no tenían que ejecutar una granja de servidores de SharePoint en sus equipos de desarrollo, necesitaban tener en cuenta cómo se iba a hospedar la solución y como se comunicaría con SharePoint Online.

Como SharePoint Framework se centra en el desarrollo del lado cliente, ya no requiere que SharePoint se instale en las máquinas de desarrollo. Salvo contadas excepciones, todas las dependencias del marco y otros paquetes se especifican en el proyecto y se incluyen en la carpeta del proyecto. Dado que el SharePoint Framework tiene sus orígenes en la nube y evoluciona con frecuencia, los desarrolladores deben asegurarse de que usan la versión correcta de la cadena de herramientas correspondiente a su proyecto de SharePoint Framework.

Entorno de desarrollo compartido o personal

Las personalizaciones de SharePoint varían desde sencillos scripts que se agregan directamente a la página hasta sofisticadas soluciones que se implementan como paquetes de solución. SharePoint Framework es un modelo de desarrollo para el modelo de implementación estructurado y repetible de las personalizaciones de SharePoint. Al crear soluciones de SharePoint Framework, cada desarrollador del equipo usa su propio entorno de desarrollo y comparte el código fuente del proyecto con otros desarrolladores del equipo con un sistema de control de código fuente. De este modo, los desarrolladores pueden trabajar en el mismo proyecto simultáneamente y probar su solución sin afectar a la productividad del otro.

En el pasado, era un desafío para muchas organizaciones justificar proporcionar a los desarrolladores de SharePoint máquinas de desarrollo eficaces y, en algunos casos, varios desarrolladores tenían que compartir la misma máquina a costa de la productividad. Con la SharePoint Framework, los desarrolladores pueden usar máquinas para desarrolladores estándar del mercado para crear personalizaciones de SharePoint.

Desarrollo del host

Probablemente la opción más fácil de configurar un entorno de desarrollo para proyectos de SharePoint Framework es instalar todas las herramientas directamente en el equipo host. Si el equipo solo trabaja en proyectos de SharePoint Framework, podrán instalar Node.js en sus equipos. Si trabajan en otros proyectos de Node.js, podrían usar soluciones de terceros, como nvm , para ejecutar varias versiones de Node.js en paralelo.

Después de las herramientas que requiere la cadena de herramientas de SharePoint Framework, los desarrolladores instalarían Yeoman y el generador de Yeoman de SharePoint Framework. Normalmente, estas dos herramientas se instalan de forma global. Pero, si el generador de Yeoman de SharePoint Framework está vinculado a una versión específica de SharePoint Framework y los desarrolladores tuvieran que trabajar con proyectos creados con una versión distinta, tendrían que desinstalarla e instalar la versión del generador específica del proyecto concreto en el que trabajen en ese momento. Un enfoque más viable sería instalar Yeoman globalmente pero instalar localmente el generador de Yeoman de SharePoint Framework en el proyecto específico. Aunque introduce cierta sobrecarga, permite a los desarrolladores garantizar que, si tuvieran que agregar nuevos elementos al proyecto en el futuro, serían compatibles con el resto del proyecto.

Una ventaja de desarrollar en el host es que los desarrolladores pueden configurar su máquina en sus preferencias una vez y usarla en todos los proyectos. Además, a medida que el software se ejecuta en el host, tiene acceso directo a la CPU, la memoria y la E/S de disco sin una capa de virtualización en medio de la cual se obtiene un mejor rendimiento que cuando se ejecuta el mismo software virtualizado.

Desarrollar en una máquina virtual

En el pasado, el enfoque más común entre los desarrolladores de SharePoint era usar máquinas virtuales como su entorno de desarrollo principal para compilar soluciones de SharePoint. Al usar máquinas virtuales, los desarrolladores implementaban los distintos requisitos para los diferentes proyectos.

Al crear soluciones en SharePoint Framework, las organizaciones pueden usar las mismas ventajas que tenían al crear soluciones de SharePoint en el pasado. Con las máquinas virtuales pueden aislar el software de desarrollo del sistema operativo host, que es un requisito común, especialmente en organizaciones grandes. Al crear una máquina virtual independiente para cada proyecto, los desarrolladores pueden asegurarse de que la cadena de herramientas que usan es compatible con el proyecto, incluso si necesitan recoger el proyecto en particular en el futuro.

El uso de máquinas virtuales no está sin inconvenientes. Las máquinas virtuales son grandes y requieren que los desarrolladores usen equipos lo suficientemente eficaces como para ejecutarlos con un rendimiento aceptable para ser productivos. Además, especialmente durante períodos de tiempo más largos, los desarrolladores tienen que mantener actualizado el sistema operativo y asegurarse de que ejecutan todas las actualizaciones de seguridad necesarias. A medida que los desarrolladores trabajan en una máquina virtual, tienen que dedicar algún tiempo al principio de un nuevo proyecto para configurar la máquina virtual estándar según sus preferencias o tienen que ceder a la configuración estándar a costa de su productividad. Dado que las máquinas virtuales ejecutan un sistema operativo completo con todos sus componentes, es mucho más difícil asegurarse de que todas las máquinas virtuales usadas por todos los desarrolladores del equipo sean coherentes. En comparación con otros tipos de entornos de desarrollo, usar máquinas virtuales para crear soluciones de SharePoint Framework es costoso, tanto en términos monetarios como de tiempo.

Desarrollar con Docker

Un término medio interesante entre desarrollar en el host y en una máquina virtual es usar Docker. Docker es una tecnología de virtualización de software similar a las máquinas virtuales con algunas diferencias. Las ventajas más importantes del uso de imágenes de Docker a través de máquinas virtuales son que las imágenes de Docker son más fáciles de crear, mantener y distribuir, son más ligeras (unos cientos de MB en comparación con decenas de GB de espacio en disco necesarias para las máquinas virtuales) y permiten a los desarrolladores usar las herramientas y preferencias que ya tienen instaladas y configuradas en su máquina host.

De forma similar a las máquinas virtuales, los contenedores de Docker ejecutan la instancia virtualizada de un sistema operativo (normalmente, basado en Linux). Todo el software instalado en la imagen y usado para crear el contenedor se ejecuta de forma aislada dentro del contenedor y solo tiene acceso a la parte del sistema de archivos host que se comparte de forma explícita con el contenedor. Como todos los cambios realizados el sistema de archivos dentro de un contenedor de Docker se descartan al cerrar el contenedor, los desarrolladores comparten carpetas desde el host para almacenar el código fuente.

Para obtener más información, vea esta página sobre Cómo usar Docker para crear soluciones de SharePoint Framework.

Flujo de trabajo de desarrollo en proyectos de SharePoint Framework

SharePoint Framework se basa en la cadena de herramientas de código abierto y sigue el flujo de trabajo de desarrollo general presente en otros proyectos basados en la misma pila. Más adelante encontrará una descripción de ese flujo de trabajo en un proyecto de SharePoint Framework típico.

Crear un proyecto de SharePoint Framework

Al crear personalizaciones de SharePoint con SharePoint Framework, el primer paso es usar scaffolding para el nuevo proyecto de SharePoint Framework. Esto se realiza con el generador de Yeoman de SharePoint Framework. El generador le pedirá que responda a varias preguntas relacionadas con el nombre del proyecto o su ubicación. También le permitirá crear el primer elemento web o la primera extensión. Aunque puede elegir un marco de JavaScript diferente para cada uno de los componentes, la recomendación general es usar un único marco por proyecto de SharePoint Framework.

Bloquear la versión de dependencias

Un nuevo proyecto de SharePoint Framework con scaffolding del generador de Yeoman SharePoint Framework tiene dependencias en los paquetes de SharePoint Framework y otros paquetes necesarios para que se ejecute correctamente. A medida que compile los elementos web, es posible que desee incluir dependencias adicionales, como Angular o jQuery. En los proyectos de SharePoint Framework, las dependencias se instalan con npm. Cada dependencia es un paquete de Node.js con una versión específica. De forma predeterminada, se hace referencia a las dependencias mediante un intervalo de versiones, que está diseñado para ayudar a los desarrolladores a mantener actualizadas sus dependencias con mayor facilidad. Una consecuencia de este enfoque es que la restauración de dependencias para el mismo proyecto en dos puntos en el tiempo podría dar resultados diferentes, lo que incluso podría provocar la interrupción del proyecto.

Una solución común para evitar el riesgo del cambio de dependencias durante el proyecto (en proyectos creados con la cadena de herramientas de código abierto) es bloquear la versión de todas las dependencias. Cuando se agrega una dependencia a los desarrolladores de Project pueden elegir instalar la dependencia con una versión específica en lugar de un intervalo de versiones llamando al comando NPM install con el argumento --Save-Exact.

Pero esto no afecta a las dependencias secundarias del paquete específico. Para bloquear de forma eficaz la versión de todas las dependencias y sus elementos secundarios en el proyecto, los desarrolladores pueden usar la función de bloqueo de archivo nativo compatible con NPM. Para obtener más información, consulte NPM-Package-Locks: una explicación de los archivos de bloqueo de NPM.

Agregar el proyecto al control de código fuente

Para permitir que el resto del equipo trabaje en el mismo proyecto, agréguelo al sistema de control de código fuente que use el equipo. Los pasos exactos serán distintos según el sistema que use el equipo.

En los proyectos de SharePoint Framework se aplica scaffolding con el archivo .gitignore, donde se describen los archivos que es necesario excluir del control de código fuente. Si el equipo usa un sistema de control de código fuente distinto de Git (como Visual Studio Team System con repositorios de Team Foundation System), necesita asegurarse de incluir los archivos correctos del proyecto en el control de código fuente. Además, excluir las dependencias y los archivos generados automáticamente durante el proceso de compilación le permite garantizar que el equipo trabajará de forma eficiente.

Una ubicación a la que los desarrolladores necesitan prestar atención especial para no incluirla en el control de código fuente es la carpeta node_modules. Esta carpeta contiene paquetes de los que depende el proyecto, que se instalan automáticamente al restaurar las dependencias mediante el comando NPM install. Algunos paquetes se compilan en binarios, donde el proceso de compilación depende del sistema operativo. Si el equipo está trabajando en un sistema operativo diferente, es probable que la inclusión de la carpeta node_modules en el control de código fuente interrumpa la compilación de algunos miembros del equipo.

Obtener el proyecto desde el control de código fuente

La primera vez que obtenga el proyecto desde el control de código fuente, obtendrá el código fuente del proyecto, pero no las bibliotecas de SharePoint Framework necesarias para compilar el proyecto. De forma similar al trabajar con proyectos de .NET y usar paquetes de NuGet, primero necesita restaurar las dependencias. En los proyectos de SharePoint Framework, del mismo modo que todos los proyectos creados encima de node. js, al ejecutar NPM install en la línea de comandos. NPM usará la información del archivo package.json en combinación con la información del archivo npm-shrinkwrap.json e instalará todos los paquetes.

Nota:

Normalmente, se necesita conectividad a Internet para restaurar las dependencias con el comando ,npm install ya que los paquetes se descargan desde https://registry.npmjs.org.

Si tiene problemas de conectividad de red o el registro de npmjs no está disponible, la compilación producirá errores. Hay diferentes formas de mitigar esta limitación. Una de ellas es usar shrinkpack para descargar tarballs de todas las dependencias y almacenarlas en el control de código fuente. Shrinkpack actualiza automáticamente el archivo NPM-shrinkwrap.json para usar la tarballs local que permite la instalación sin conexión de las dependencias del proyecto.

Algunos de los paquetes se compilan en binarios durante el proceso de instalación. Este proceso de compilación es específico de la arquitectura y el sistema operativo. Si restaura las dependencias en un contenedor Docker que ejecuta Linux y luego intenta construir el proyecto en su host de Windows, recibirá un error que informa de la falta de coincidencia en el tipo de entorno utilizado para construir y ejecutar los archivos binarios.

A medida que el equipo desarrolla la solución, se pueden agregar al proyecto dependencias nuevas o actualizadas. Si el archivo package.json cambió desde que obtuvo por última vez el proyecto desde el control de código fuente, tendrá que ejecutar npm install en la línea de comandos para instalar las dependencias faltantes. Si no está seguro de si se cambió el archivo package.json, puede ejecutar npm install en la línea de comandos para comprobar que tiene las últimas dependencias sin que esto afecte al proyecto.

Agregar paquetes al proyecto

Usar paquetes existentes para realizar tareas específicas le permite ser más productivo. https://www.npmjs.comes un registro público de paquetes que puede usar en el proyecto.

Importante

Ya que no hay ningún proceso formal de comprobación antes de que se publique un paquete en https://www.npmjs.com, debe examinar atentamente si puede usar el paquete en particular desde el punto de vista de contenido y licencia.

Para agregar un paquete al proyecto de SharePoint Framework ejecute el comando npm install {package} --save o npm install {package} --save-dev en la línea de comandos, por ejemplo: npm install angular --save. Al usar los argumentos --save o --save-dev, se asegura de que el paquete se agregue al archivo package.json y, de esta forma, otros desarrolladores del equipo también lo obtendrán al restaurar dependencias. Si no usa estos argumentos, se producirán errores al compilar el proyecto en un equipo distinto al suyo. Al agregar paquetes que la solución necesita en tiempo de ejecución, como angular u jQuery, debe usar el argumento --save.. Los paquetes que se necesitan en el proceso de compilación, como tareas adicionales de Gulp, deben instalarse con el argumento de --save dev.

Al instalar un paquete, si no especifica una versión, NPM instalará la versión más reciente disponible en el registro del paquete (https://www.npmjs.com de forma predeterminada), que suele ser la versión que desea usar. Si tiene que especificar la versión del paquete, un caso específico es cuando usa npm-shrinkwrap.json y quiere actualizar un paquete existente a una versión más reciente. De forma predeterminada, npm instalará la versión que se muestra en el archivo npm-shrinkwrap.json. Especificar el número de versión en el NPM install comando, como NPM install angular@1.5.9 --save, instalará el paquete y actualizará el número de versión en el archivo npm-shrinkwrap.json

Trabajar con paquetes internos

A medida que su equipo desarrolle soluciones de cliente, es probable que cree bibliotecas de código comunes que le gustaría reutilizar en todo el proyecto. En muchos casos, dichas bibliotecas contienen código de propiedad que no se comparte públicamente fuera de la organización (más allá de los paquetes implementados en producción). Al trabajar con proyectos de SharePoint Framework, el equipo tiene diferentes formas de usar las bibliotecas internas en sus proyectos.

Hospedar un registro de paquetes privado

En el pasado, muchas organizaciones que creaban soluciones de .NET hospedaban repositorios privados de NuGet para aprovechar las ventajas del sistema de administración de paquetes de NuGet para sus paquetes internos. Como SharePoint Framework usa npm para la administración de paquetes, las organizaciones pueden, de forma similar, usar un registro privado para sus paquetes internos. Los paquetes desarrollados internamente se publicarán en el registro privado y se usarán en todos los proyectos de la organización.

Al usar registros de paquetes privados, las organizaciones pueden elegir entre diferentes ofertas hospedadas en la nube o pueden hospedar su propio registro en su infraestructura.

Usar un registro de paquetes privado permite a las organizaciones administrar de forma centralizada código común usado en diferentes proyectos. Al definir un plan de gobierno separado en relación con la contribución de cambios en la base de código compartido, las organizaciones pueden garantizar que la biblioteca de código sea de alta calidad y que ofrezca a todos los desarrolladores las ventajas esperadas, en lugar de ser una carga que afecte al progreso de los proyectos.

Las organizaciones que usan Visual Studio Team Services o Team Foundation Server pueden crear un registro de npm privado directamente en VSTS y TFS cómodamente. Las organizaciones que utilizan otros sistemas de control de código fuente pueden usar otras soluciones para hospedar sus paquetes. Un popular registro privado hospedado en la nube es npm Enterprise. Las organizaciones interesadas en hospedar su propio registro pueden elegir entre varias implementaciones de código abierto, tales como Sinopia (o su bifurcación Verdaccio) o Nexus.

Nota:

Los diferentes motores para hospedar registros de paquetes privados se encuentran en diferentes fases de desarrollo y necesita evaluar detenidamente que el motor específico cumple sus requisitos, tanto desde el punto de vista de funciones, como de licencias y soporte.

Para simplificar la instalación y administración de un registro de paquetes privado, la mayoría de los motores ofrecen imágenes de Docker listas para usar.

Una alternativa al uso de un registro privado es la vinculación de paquetes. Aunque no se configure un registro, es necesario coordinar detenidamente todos los equipos de los desarrolladores y el servidor de compilación.

Primero, todos los desarrolladores del equipo necesitan obtener una copia del paquete compartido en su equipo de desarrollo. En la línea de comandos, necesitan cambiar el directorio de trabajo al del paquete compartido y, después, ejecutar el comando npm link Este comando registra el paquete específico como un paquete global en ese equipo de desarrollo concreto. Después, los desarrolladores tienen que cambiar el directorio de trabajo al directorio del proyecto donde quieran usar el paquete compartido. A continuación, instalan el paquete de la misma manera que instalarían cualquier otro paquete ejecutando el comando npm install {shared_package} --save en la línea de comandos. Como el paquete compartido se instala de forma global, npm usará esa versión como el origen desde donde instalar el paquete. En este momento, desde el punto de vista del proyecto, el paquete está instalado igual que cualquier otro paquete público y los desarrolladores pueden elegir cómo quieren agrupar el paquete con el proyecto.

Es necesario ejecutar la vinculación del paquete en todos los equipos de desarrollo, así como en el servidor de compilación. Si el paquete compartido no se vincula con el comando npm link, no podrán restaurarse las dependencias del proyecto y se producirán errores de compilación.

Agregar referencias a los paquetes vinculados es especialmente útil al principio del proyecto si desarrolla el paquete compartido y el proyecto al mismo tiempo. Con la vinculación, no tendrá que publicar una nueva versión del paquete en el registro para usar el código más reciente del proyecto. Un riesgo que es importante tener en cuenta es que, si los desarrolladores agregan referencias a una versión de la biblioteca compartida que cambiaron de forma local y que no confirmaron en el control de código fuente, podían producirse errores de compilación para el resto del equipo.

Combinar el registro de paquetes privado y la vinculación de paquetes

La vinculación de paquetes se puede combinar con un registro privado. Por ejemplo, podría trabajar de forma que los desarrolladores hagan referencia a un paquete vinculado y el servidor de compilación extraiga la biblioteca compartida de un registro privado. Desde la perspectiva del proyecto no cambia nada: la referencia al paquete en el archivo package.json se puede resolver tanto desde un paquete vinculado como desde un registro privado. Lo único que tiene que tener en cuenta el equipo es publicar los cambios más recientes de la biblioteca compartida en el registro privado antes de ejecutar la compilación.

Como el código de la biblioteca compartida se estabiliza con el paso del tiempo y se necesitan menos cambios para adaptarse a las necesidades de los proyectos específicos, es más probable que los desarrolladores agreguen referencias solo al paquete publicado del registro privado, en lugar de cambiarlo.

Garantizar la calidad y la coherencia del código

Los equipos de desarrollo de software suelen tener dificultades para mantener la coherencia y alta calidad de los proyectos. Diferentes desarrolladores tienen distintos estilos y preferencias en relación con el código. En cada equipo, hay desarrolladores y usuarios más especializados que son menos experimentados en el dominio específico. Además, muchas organizaciones o sectores verticales tienen normativas específicas con las que tiene que cumplir software. Todos estos desafíos hacen que sea más difícil para los desarrolladores seguir. En particular, cuando la fecha límite es que los desarrolladores próximos suelen lograr el coste de la calidad, que a largo plazo es más peligroso que no cumple la fecha límite.

Elegir una biblioteca de JavaScript para el equipo y usar estándares de codificación

Si el equipo creó personalizaciones de SharePoint en el pasado, es muy probable que tenga estándares de codificación donde se describa cómo crear personalizaciones y qué herramientas y bibliotecas usar en los proyectos. Usar estándares de codificación le permite eliminar del código las preferencias personales de los desarrolladores individuales, lo que facilita en gran medida que otros miembros del equipo lo reutilicen. Además, los estándares de codificación reflejan la experiencia recopilada por el equipo a lo largo de los años, lo que permite crear personalizaciones con mayor eficiencia y calidad.

Al contrario que otros modelos de personalización de SharePoint disponibles hasta el momento, SharePoint Framework se centra en el desarrollo del lado cliente. Aunque no es estrictamente necesario, SharePoint Framework recomienda usar TypeScript para ayudar a los desarrolladores a escribir mejor código y para identificar las posibles incoherencias presentes en el proceso de compilación. Hay disponibles cientos de bibliotecas del lado cliente para completar la misma tarea. Si el equipo realizó desarrollo del lado cliente en el pasado, es posible que ya tenga una biblioteca específica preferida. En caso contrario, le recomendamos que investigue las bibliotecas más populares y que seleccione una para el equipo (o, preferiblemente, para toda la organización).

Al usar la misma biblioteca en todos los proyectos, podrá integrar fácilmente a nuevos miembros del equipo e intercambiar miembros del equipo entre diferentes proyectos. A medida que gane experiencia con el desarrollo del lado cliente, su organización podrá beneficiarse de esto en todos sus proyectos. Estandarizar los proyectos en toda la organización también acorta los tiempos de entrega y reduce los costos de mantenimiento de los proyectos. En Internet se publican todos los días nuevas bibliotecas y, si continúa cambiando entre las bibliotecas más recientes, se encontrará trabajando de forma poco eficiente al entregar soluciones de poca calidad.

Además, estandarizar las bibliotecas que se usan en toda la organización le permitirá optimizar el rendimiento de las soluciones. Como la misma biblioteca se usa en toda la organización, los usuarios solo tendrán que descargarla una vez, lo que reduce de forma significativa el tiempo de carga de las soluciones y, como resultado, mejora la experiencia del usuario.

Seleccionar una de las bibliotecas más populares le permite reutilizar el conocimiento y la experiencia de otros desarrolladores que usaron esa biblioteca durante más tiempo y que ya solucionaron muchos de los problemas con los que puede que se encuentre. Además, para las bibliotecas más populares hay estándares de codificación disponibles que su equipo puede adoptar. Al usar estándares existentes en el mercado para una biblioteca específica, su organización podrá hacer crecer fácilmente el equipo al contratar desarrolladores y ayudarlos a ser productivos con mayor rapidez.

Por ejemplo, para crear soluciones propias en SharePoint Framework, Microsoft eligió React. Además, muchos otros equipos en Microsoft (como OneDrive o MyAnalytics) usan React en sus proyectos. Esto no quiere decir que también necesite usar React en todos sus proyectos de SharePoint Framework, pero demuestra la importancia de elegir una biblioteca del lado cliente que funcione para su organización. Si, por ejemplo, su equipo tiene experiencia con Angular o Knockout, no hay ningún motivo por el que no pueda beneficiarse de esa experiencia y seguir siendo productivo al crear soluciones de SharePoint Framework.

Exigir estándares de codificación y directivas en todo el ciclo de vida de la solución

El uso de estándares de codificación ofrece ventajas claras, pero el simple hecho de tener estándares de código no quiere decir que se usen de forma activa durante todo el proceso de prueba y desarrollo de una personalización de SharePoint. Cuanto más esperen los desarrolladores y más difícil sea para el equipo comprobar que la solución cumple con los estándares de codificación del equipo y las directivas de la organización, más costoso será corregir los defectos detectados en el proyecto. Más adelante encontrará algunos métodos que el equipo tiene que usar como parte del proceso de desarrollo para exigir el plan de gobierno en la solución de SharePoint.

Linting

Linting es el proceso de comprobar que el código cumple unas reglas específicas. De forma predeterminada, los proyectos de SharePoint Framework se crean con TypeScript. En cada compilación, TSLint (el linter de TypeScript) analiza el proyecto con el conjunto de reglas predefinidas e informa de posibles incoherencias. Los desarrolladores pueden elegir qué reglas quieren habilitar y, si es necesario, pueden crear sus propias reglas para reflejar las directrices del equipo o la organización.

Los desarrolladores pueden usar el linting para comprobar el contenido de los archivos de TypeScript. Pero también hay linters disponibles para los lenguajes más populares (como CSS, JavaScript o Markdown) y, si el equipo tiene directrices específicas para estos lenguajes, sería una ventaja implementarlos en un linter para que se puedan validar automáticamente cada vez que un desarrollador cree el proyecto.

Pruebas automatizadas

Si los desarrolladores usan pruebas automatizadas, podrán comprobar fácilmente que, después de aplicar los cambios más recientes en el proyecto, todos los elementos siguen funcionando del modo previsto. A medida que crezca el proyecto, las pruebas automatizadas serán también más importantes: al expandirse la base de código, cada cambio tiene un mayor impacto y aumenta el riesgo de que afecte a otras partes del código. Las pruebas automatizadas permiten a los desarrolladores comprobar que la solución funciona correctamente e identificar posibles problemas con anterioridad.

SharePoint Framework ofrece soporte estándar para el ejecutor de pruebas Karma y para el marco Mocha que los desarrolladores pueden usar para escribir pruebas. Si es necesario, los desarrolladores pueden usar otros bloques de creación proporcionados con SharePoint Framework, como Jest y PhantomJS para ampliar aún más la cobertura de sus pruebas. Todas las pruebas que se realicen en los proyectos de SharePoint Framework se pueden ejecutar con la tarea estándar de prueba de Gulp.

Análisis de código

Mientras que el linting resulta útil para validar la sintaxis de un archivo específico, los desarrolladores suelen necesitar más soporte para comprobar que el proyecto en conjunto cumple con las directrices. Normalmente, los linters se centran en el código en sí, pero pierden el contexto de lo que representa un archivo de código específico. En las soluciones de SharePoint Framework, los artefactos tienen requisitos específicos (por ejemplo, un elemento web necesita tener un id. único en el proyecto). Además, es posible que las organizaciones tengan otros requisitos, como no hacer referencia a scripts de redes CDN o usar solo una versión específica de una biblioteca concreta. Aquí es donde los linters suelen estar limitados y los desarrolladores necesitan otras herramientas.

SharePoint Code Analysis Framework (SPCAF) es una solución de terceros que suelen usar los desarrolladores, administradores y empleados con roles de seguridad y de control de calidad de SharePoint, y se usa para comprobar que las personalizaciones de SharePoint cumplen con las directrices de calidad de la organización. SPCAF se integra con todo el proceso de ciclo de vida de la aplicación, lo que permite a las organizaciones reducir el costo total de propiedad de las personalizaciones de SharePoint. SPCAF ofrece un conjunto de reglas adaptadas específicamente a las soluciones de SharePoint Framework.

Actualizar proyectos de SharePoint Framework

Implementar una personalización de SharePoint en producción no suele significar el fin de su ciclo de vida. Con frecuencia, los requisitos cambian o se agregan nuevos requisitos en ambos casos, lo que produce cambios en la solución. Para actualizar correctamente una personalización implementada anteriormente en producción, los desarrolladores necesitan tener varios puntos en cuenta.

Versionamiento Semántico (SemVer)

Salvo contadas excepciones, SharePoint Framework usa Versionamiento Semántico (SemVer) para realizar un seguimiento de los números de versión. El Versionamiento Semántico es un modelo de control de versiones ampliamente adoptado por desarrolladores de software en todo el mundo. Un número de SemVer está formado por tres números PRINCIPAL.SECUNDARIO.REVISIÓN y etiquetas opcionales, por ejemplo, 1.0.1.

Nota:

Actualmente, SharePoint Framework solo admite el uso de los tres números, sin las etiquetas.

Las diferentes partes de un número de SemVer aumentan según el tipo de cambio aplicado a la solución:

  • PRINCIPAL, si los cambios no son compatibles con versiones anteriores.
  • SECUNDARIO, si los cambios introducen nuevas funciones que son compatibles con versiones anteriores.
  • REVISIÓN, si los cambios son correcciones de errores compatibles con versiones anteriores.

Es importante tener en cuenta que SemVer es simplemente un contrato. Es decisión del equipo seguirlo y especificar claramente los cambios en la versión más reciente.

Para obtener más información sobre Versionamiento Semántico, vea http://semver.org.

Aumentar el número de versión

Al actualizar un elemento de una solución de SharePoint Framework, los desarrolladores necesitan aumentar los números de versión de las partes afectadas para indicar claramente qué elementos han cambiado y cuál es el impacto de los cambios.

Aumentar la versión del paquete en package.json

Los paquetes de SharePoint Framework se estructuran como un paquete de Node.js. Sus dependencias y metadatos se almacenan en el archivo package.json de la carpeta de proyecto. Una de las propiedades del archivo package.json es la propiedad "version", que indica la versión de todo el proyecto. De forma predeterminada, todos los componentes de la solución actual heredan este número de versión como su versión. Los desarrolladores deben aumentar el número de versión en package.json cada vez que se planee una nueva versión del proyecto siguiendo la convención de SemVer.

Aumentar la versión del paquete de solución en package-solution.json

SharePoint Framework soluciones se implementan mediante un archivo *.sppkg instalado en el catálogo de aplicaciones en un inquilino de SharePoint. Un archivo *.sppkg es similar a un paquete de complementos de SharePoint y sigue las mismas convenciones de control de versiones. La versión actual del paquete *.sppkg se define mediante una versión de cuatro partes (MAJOR. MENOR. REVISIÓN. BUILD) almacenado en el archivo config/package-solution.json . Para mayor claridad, los desarrolladores deben mantener este número sincronizado con el número de versión del archivo package.json, ya que los dos números hacen referencia a la versión del proyecto en conjunto.

Nota:

Se requiere aumentar el número de versión en el archivo package-solution.json entre versiones para que la nueva versión del paquete se implemente correctamente en SharePoint.

Actualizar las dependencias

Uno de los motivos de una actualización de un proyecto de SharePoint Framework puede ser un cambio en una de las dependencias subyacentes (por ejemplo, una nueva versión de Angular con correcciones de errores y mejora el rendimiento). Si el equipo sigue el enfoque recomendado de usar npm shrinkwrap para bloquear las versiones de dependencia, usaría el comando npm install {package}@{version} --save para actualizar la dependencia a la versión específica y probar el proyecto para comprobar que funciona según lo esperado con las actualizaciones más recientes. Según la forma en que afecten al proyecto los cambios realizados en las dependencias subyacentes, la actualización del proyecto general puede variar desde una revisión hasta una versión principal completa.

Importante

No modifique manualmente los números de versión de dependencias en el archivo package.json. Si usa un archivo de bloqueo como npm shrinkwrap, los cambios manuales en el archivo package.json se omitirán y se usarán los números de versión registrados en los archivos de bloqueo, lo que provocará errores difíciles de realizar en el proyecto.

Cuidado con los cambios de estructura de proyecto

Si actualiza el proyecto a una versión más reciente de SharePoint Framework, puede que sea necesario realizar cambios en la estructura de proyecto y los archivos de configuración de proyecto. Antes de actualizar las versiones de SharePoint Framework en las dependencias del proyecto, debe crear siempre un proyecto con la versión de SharePoint Framework a la que desea actualizar y comparar atentamente su estructura y contenido con los del proyecto existente. Esto le permitirá determinar el impacto de la actualización en el proyecto y le ayudará a evitar aplicar cambios drásticos al proyecto.

Cuidado con el uso de npm outdated

Una de las formas de averiguar qué dependencias del proyecto deben actualizarse, es ejecutar el comando npm outdated. Este comando analizará el árbol de dependencias y le mostrará los paquetes que pueden actualizarse. Aunque es conveniente utilizar este comando, tiene que hacerse con cautela.

Desde la versión SPFx v1.3, el generador de Yeoman de SharePoint Framework le permite elegir si se aplica scaffolding a un proyecto que debe funcionar solo en SharePoint Online o tanto en SharePoint 2016 Feature Pack 2 y versiones posteriores como en SharePoint Online. SharePoint hospedado en local usa una versión de SharePoint Framework anterior a la versión disponible en SharePoint Online. Si ejecutara el comando npm outdated en un proyecto compatible con SharePoint local, sugeriría actualizar los paquetes principales de SharePoint Framework a las últimas versiones publicadas en npm. Por desgracia, al actualizar estos paquetes con sus versiones más recientes, el proyecto ya no funcionaría con SharePoint local. Antes de actualizar las versiones de los paquetes de SharePoint Framework, debe comprobar siempre si la finalidad del proyecto es trabajar con SharePoint hospedado en local y, si es así, ¿qué versión de SharePoint Framework tiene que admitir?

Crear y empaquetar un proyecto en el modo de publicación

Una vez que haya comprobado que la solución funciona como se esperaba, compile el proyecto en modo de lanzamiento con el comando gulp bundle -- ship. A continuación, cree un nuevo paquete con el comando gulp package-solution --ship. Sin ejecutar el comando gulp bundle --ship en primer lugar, el paquete incluirá una versión anterior del proyecto.

Implementar una nueva versión de la solución

Después de compilar y empaquetar el proyecto, el paso siguiente es implementarlo. Primero, implemente en el proyecto los paquetes de elementos web actualizados que se encuentran en la carpeta ./temp/deploy. Publique los archivos junto a los paquetes de elementos web de la versión anterior de la solución.

Nota:

No quite las versiones anteriores de la solución mientras haya instancias activas de elementos web que las usen. Cada versión de los archivos del paquete tiene un nombre único y, si se quitan las versiones anteriores antes de actualizar los elementos web, estos dejarán de funcionar.

Después, implemente el nuevo paquete de solución en el catálogo de aplicaciones de SharePoint. Esto es necesario para notificar a SharePoint de la nueva versión de la solución que necesita aplicar.