Administración del ciclo de vida de las aplicaciones de SharePoint
Aplica los conceptos y las prácticas comunes de administración del ciclo de vida de las aplicaciones (ALM) al desarrollo de aplicaciones usando las tecnologías de SharePoint.
Proporcionado por: Eric Charran, Microsoft Corporation
Colaboradores: Vesa Juvonen, Microsoft Corporation | Steve Peschka, Microsoft Corporation
Importante: este tema hace referencia a los Complementos de SharePoint autohospedados. El programa de vista previa para aplicaciones autohospedadas ha finalizado. Haga caso omiso de todas las referencias a Complementos de SharePoint autohospedados.
Información general sobre la administración del ciclo de vida de aplicaciones (ALM)
Microsoft SharePoint ofrece a los desarrolladores varias opciones para crear e implementar aplicaciones que se basan en tecnologías de SharePoint, tanto para plataformas locales como plataformas en la nube hospedadas o públicas. SharePoint ofrece una mayor flexibilidad en la forma que pueden adoptar las aplicaciones, así como nuevas opciones para usar tecnologías basadas en estándares junto con aplicaciones. Aunque estas capacidades de las aplicaciones y las opciones de implementación que incluye el nuevo modelo de aplicaciones de SharePoint representan un medio eficaz para que los desarrolladores creen aplicaciones nuevas y envolventes, estos deben tener en cuenta cuestiones de calidad, pruebas y ALM en el proceso de desarrollo. Este artículo aplica conceptos y prácticas de ALM al desarrollo de aplicaciones usando tecnologías de SharePoint.
Novedades
SharePoint establece un nuevo paradigma para implementar aplicaciones. Gracias a este cambio en el desarrollo de aplicaciones con las tecnologías de SharePoint, los desarrolladores y arquitectos pueden conocer muy bien los patrones, las prácticas y los modelos de implementación nuevos de las aplicaciones para SharePoint. Es importante destacar que, si bien el modelo de aplicaciones para desarrollar soluciones con SharePoint ha cambiado, muchos de los patrones usados en el desarrollo de soluciones, incluyendo la elección de tecnologías y las técnicas de implementación, están en armonía con las tecnologías actuales de desarrollo de aplicaciones web.
Los recursos siguientes describen los tipos de aplicaciones que se pueden construir con las tecnologías de SharePoint y recogen las consideraciones para las aplicaciones locales y en la nube. Para comprender las opciones de hospedaje para complementos de SharePoint, vea Elegir patrones para desarrollar y hospedar su complemento de SharePoint.
Además, Microsoft aconseja a los clientes evaluar las tecnologías usadas al desarrollar aplicaciones con SharePoint, ya que existe un conjunto más amplio de opciones para la implementación de soluciones. Al crear aplicaciones, los clientes se pueden centrar en sacar provecho de las tecnologías basadas en estándares, como HTML5 y JavaScript para las capas de presentación y experiencia del usuario, mientras que OData y OAuth se pueden usar para el acceso basado en servicios a los servicios back-end, incluido SharePoint. Los clientes deben pensar bien si se necesita código de confianza plena (es decir, ensamblados compilados implementados en SharePoint), aunque seguir usando ese paradigma de desarrollo, válido y necesario en algunas situaciones, impone una sobrecarga considerable en el proceso de ALM.
Para obtener más información sobre las nuevas tecnologías de desarrollo flexible para aplicaciones en SharePoint, vea Introducción al desarrollo de SharePoint.
Ventajas y cambios
Como ahora las tecnologías de desarrollo de aplicaciones compatibles con SharePoint ofrecen mayor variedad de idiomas y arquitecturas de programación, los desarrolladores tienen que adaptar las prácticas de ALM existentes a las técnicas de desarrollo estándares para admitir su presencia en SharePoint. Conceptos como los pruebas, establecimiento de compilaciones, implementación y control de calidad se pueden ampliar para incluir la implementación en SharePoint como una aplicación de SharePoint. Esto puede significar que, aunque muchos desarrolladores están acostumbrados a escribir e implementar soluciones de granja del lado servidor que amplían las capacidades principales de SharePoint, haya que aplicar en el proceso de implementación prácticas de ALM comunes para el nuevo modelo de desarrollo flexible facilitado por las aplicaciones de SharePoint.
Con la transición de los clientes a las implementaciones hospedadas en la nube de SharePoint, los desarrolladores tendrán que aprender a ampliar los conceptos de ALM para incluir entornos de destino para el desarrollo, las pruebas y la implementación que residan fuera de los límites físicos de la organización. Esto incluye la evaluación de la estrategia tecnológica para llevar a cabo el desarrollo, las pruebas y la implementación de aplicaciones.
Los desarrolladores y los arquitectos pueden llegar a dominar muy bien la sintetización de soluciones consistentes en varios componentes de aplicación que abarcan o combinan distintos tipos de opciones de hospedaje. Durante este proceso de adaptación, los procedimientos de ALM deben aplicarse unilateralmente a estas aplicaciones. Por ejemplo, los desarrolladores pueden tener que implementar una aplicación que abarque la implementación de servicios locales (es decir, IIS, ASP.NET, MVC, WebAPI y WCF), Microsoft Azure, SharePoint y SQL Azure, a la vez que prueban los componentes de la aplicación para comprobar la calidad y si se han introducido regresiones después de una compilación anterior. Estos requisitos pueden suponer un cambio significativo en la forma en que desarrolladores y equipos afrontan el proceso diario de creación e implementación, que es un procedimiento conocido para las soluciones locales o del lado servidor.
Consideraciones sobre el equipo de desarrollo
Para organizaciones que tienen más de un desarrollador o arquitecto de aplicaciones, el desarrollo en equipo para SharePoint debe planearse atentamente para ofrecer aplicaciones de la mejor calidad y fomentar la suficiente productividad de los desarrolladores. Como el método para desarrollar aplicaciones ha aumentado en flexibilidad, los equipos tendrán que conocer muy bien no solo las prácticas y los patrones de ALM, sino que también deberán saber cómo cada desarrollador escribirá el código y asegurar que en el proceso de creación de aplicaciones se incluya un código de calidad.
Estas consideraciones empiezan por seleccionar el entorno de desarrollo adecuado. Tradicionalmente, el desarrollo se relegaba, pues se llevaba a cabo de forma independiente en máquinas virtuales conectadas a un repositorio de código común que ofrecía capacidades de creación, implementación y prueba, como Visual Studio TFS 2012. TFS sigue siendo un componente instrumental fuerte de una estrategia de ALM, y es fundamental en el esfuerzo de desarrollo, pero los equipos deben pensar en cómo sacar provecho de TFS en los distintos tipos de opciones de entorno de desarrollo.
En función del entorno de destino, el tipo de solución (es decir, qué componentes serán locales y cuáles se hospedarán en infraestructura o servicios en la nube), los desarrolladores pueden ahora seleccionar de una combinación de nuevas opciones de entorno de desarrollo. Estas opciones consistirán en elecciones nuevas, como la plantilla de sitio para desarrolladores de SharePoint, un inquilino para desarrolladores de Office 365 y elecciones heredadas, como el desarrollo basado en máquinas virtuales con Hyper-V en Windows 8 o Windows Server 2012.
La siguiente sección describe las consideraciones del entorno de desarrollo para los desarrolladores de aplicaciones y los equipos de desarrollo.
Consideraciones sobre el entorno de desarrollo
La selección de un entorno de desarrollo debe basarse en varios factores. Estas consideraciones están influidas, en gran medida, por el tipo de aplicación que se desarrolla y por la plataforma de destino de la aplicación. Tradicionalmente, al crear aplicaciones para SharePoint Server 2010, los desarrolladores aprovisionaban máquinas virtuales y desarrollaban en condiciones de aislamiento. Esto se debía al hecho de que la implementación de soluciones de confianza plena podía obligar a reiniciar dependencias básica de SharePoint, como IIS, lo que impedía que varios desarrolladores usaran un único entorno de SharePoint. Como las tecnologías de desarrollo han cambiado y las opciones de creación de aplicaciones para desarrolladores han crecido, estos y los equipos deben conocer el abanico de entornos de desarrollo que tienen disponibles. La figura 1 muestra el entorno de desarrollo y una combinación de herramientas, e incluye los tipos de soluciones que se pueden implementar en los entornos de destino.
Figura 1. Componentes y herramientas del entorno de desarrollo
[
Filosofía del entorno de desarrollo
Por las inversiones hechas en cómo las aplicaciones se pueden diseñar e implementar usando SharePoint, los desarrolladores deben determinar si hay necesidad de desarrollar usando código del lado servidor. Cuando los desarrolladores crean aplicaciones que usan el modelo hospedado en la nube, el requisito de desarrollar basándose en entornos virtualizados, especialmente para SharePoint, disminuye. Los desarrolladores deben crear soluciones con el modelo de desarrollo remoto que usa infraestructura (pública y privada) basada en la nube. Si los entornos de desarrollo se pueden aprovisionar rápida y fácilmente sin tener que crear ni disponer la virtualización, los desarrolladores pueden invertir más tiempo en centrarse en la productividad y la calidad del desarrollo en lugar de en la administración de la infraestructura.
La decisión de requerir una instancia virtualizada de SharePoint frente a la nueva plantilla de sitio para desarrolladores de SharePoint dependerá de si la aplicación necesita que se implemente código de plena confianza en SharePoint y que se ejecute ahí. Si no se necesita código de plena confianza, recomendamos usar la plantilla de sitio para desarrolladores, que está en los inquilinos de desarrollo de Office 365 o dentro de una implementación de SharePoint local de una organización. Las plantillas de sitio para desarrolladores se diseñan para que estos implementen las aplicaciones directamente en SharePoint desde Visual Studio. Los sitios para desarrolladores de Office 365 se preconfiguran para el aislamiento de aplicaciones y OAuth para que los desarrolladores puedan empezar a escribir y probar las aplicaciones inmediatamente.
En las secciones siguientes se describe con detalle cuándo los desarrolladores pueden usar las diferentes opciones de entorno para crear aplicaciones.
Sitios de desarrollo de O365 (nube pública)
La figura 2 muestra cómo los desarrolladores pueden usar Office 365 como entorno de desarrollo e incluye los tipos de herramientas que producen las aplicaciones de SharePoint que pueden hospedarse en Office 365.
Figura 2. Desarrollo de aplicaciones de Office 365
[
Los desarrolladores con suscripciones de MSDN puede obtener un espacio empresarial de desarrollo que contenga un sitio de desarrollo de SharePoint. El Sitio para desarrolladores de SharePoint está preconfigurado para desarrollar aplicaciones. Los usuarios pueden usar no solo Visual Studio 2012 al desarrollar aplicaciones, sino que con los sitios para desarrolladores de Office 365, también se pueden usar las Napa dentro del sitio para construir aplicaciones. Para más información sobre cómo empezar a usar un sitio para desarrolladores de Office 365, vea Configurar un sitio para desarrolladores de Complementos de SharePoint en Office 365.
Los desarrolladores pueden empezar a crear aplicaciones que se hospedarán en Office 365, localmente o en otra infraestructura de un modelo hospedado por un proveedor. La ventaja de este entorno es que la infraestructura, la virtualización y otras consideraciones de hospedaje para un entorno de desarrollo de SharePoint las sintetiza Office 365, lo que permite a los desarrolladores crear aplicaciones al instante. Una consideración muy importante en este tipo de entorno de desarrollo es que las aplicaciones que requieren código de plena confianza para implementarse en SharePoint no se pueden incluir. Microsoft recomienda usar el modelo de objetos del lado cliente (CSOM) de SharePoint y tecnología del lado cliente, como JavaScript, siempre que se pueda. Si se necesita código de plena confianza (pero no es necesario implementar el código para que se ejecute en SharePoint), recomendamos implementar el código del lado servidor en un modelo autohospedado u hospedado por un proveedor. Estas soluciones de código de plena confianza que se implementan en infraestructuras hospedadas por un proveedor también usan CSOM, pero pueden usar idiomas como C#. También cabe destacar que estas aplicaciones implementadas en un modelo hospedado por un proveedor pueden usar otras pilas tecnológicas y seguir usando CSOM para interactuar con SharePoint.
Los equipos de desarrollo encargados de crear características o aplicaciones independientes que contienen una solución más amplia necesitan un destino de implementación centralizada para los componentes de prueba de la integración. Como cada desarrollador crea características o aplicaciones en su propio sitio de desarrollador de Office 365, se debe aprovisionar una colección de sitios centralizada de un inquilino de destino o un entorno local para que los componentes de la aplicación de cada desarrollador se puedan implementar ahí. Este método permitirá que se hagan pruebas de integración entre los componentes de las soluciones desde una ubicación centralizada. En la sección de pruebas de este documento explicamos este proceso en detalle.
Sitios de desarrollo (desarrollo remoto)
Para organizaciones y desarrolladores que elijan no usar sitios de desarrollador de Office 365 como medio principal para el desarrollo de aplicaciones de SharePoint, los sitios de desarrolladores locales se pueden usar para desarrollar aplicaciones de SharePoint. En este modelo, la capacidad de los sitios de desarrollador de Office 365 se reemplaza por sitios de desarrollador locales hospedados dentro de una granja de SharePoint. Los clientes pueden crear una nube privada de desarrollo implementando una granja de SharePoint para hospedar instancias de sitio de desarrollo. Los clientes pueden suministrar su propia automatización de gobierno para proporcionar la creación de plantillas de sitio de desarrollador o usar las capacidades de SharePoint integradas en los productos para aprovisionar instancias de sitio de desarrollador. La figura 3 muestra esta configuración.
Figura 3. Desarrollo de aplicación local con la plantilla de sitio de desarrollador
[
La figura 3 describe las herramientas de desarrollo y los tipos de aplicaciones que se pueden habilitar con sitios de desarrollador cuando se usa una granja de SharePoint local como host. Recuerde que las herramientas de desarrollo Napa de Office 365 no se pueden usar en este entorno, ya que son una capacidad que solo está presente en sitios de desarrollo de Office 365.
La granja de SharePoint que hospeda instancias de Sitio para desarrolladores se debe supervisar y debe cumplir objetivos de servicio, de punto de recuperación y de nivel de tiempo para que los desarrolladores que dependen de ellas para crear aplicaciones puedan ser productivos y no tengan interrupciones en el servicio. Los clientes pueden aplicar conceptos de nube privada, como la elasticidad y las unidades de escala, y un tejido de administración a este entorno. Las operaciones y la administración deben aplicarse a la granja de SharePoint donde también estén hospedados los sitios de desarrolladores. Esto ayudará a controlar el crecimiento desmedido y no supervisado de varios sitios de desarrolladores que están obsoletos o no se usan, así como a saber cuándo tiene que escalar el entorno.
Los clientes pueden decidir usar capacidades de infraestructura como servicio (IaaS), por ejemplo, Microsoft Azure, para hospedar las granjas de SharePoint que contienen y hospedan sitios de desarrollador, o bien usar sus propios entornos locales virtuales o físicos. Con este modelo no se necesita una instalación de SharePoint para cada desarrollador. El desarrollo remoto de aplicaciones solo requerirá herramientas de desarrollo de Visual Studio, Office y SharePoint en la estación de trabajo del desarrollador.
Los desarrolladores deben establecer una infraestructura hospedada por un proveedor para implementar las aplicaciones hospedadas por el proveedor. Aunque los componentes hospedados por un proveedor de una aplicación de SharePoint se pueden implementar en un amplio abanico de tecnologías, los desarrolladores deben ofrecer una infraestructura para hospedar estos componentes de la aplicación que se ejecutan fuera de SharePoint. Por ejemplo, si un equipo está desarrollando una aplicación de SharePoint cuya experiencia de usuario y otros componentes residen en una aplicación de ASP.NET, el equipo de desarrollo debe usar versiones locales de IIS, SQL Server, etc., y adoptar patrones de desarrollo tradicionales para equipos de ALM para ASP.NET.
Entornos de granjas independientes (desarrollo virtualizado de una granja)
Para las soluciones que requieren la implementación de un código de plena confianza para ejecutarse en una granja de SharePoint, se necesita una implementación total (a menudo, virtualizada) de SharePoint. Para obtener instrucciones sobre cómo crear un entorno de desarrollo local para SharePoint, consulte Configuración de un entorno de desarrollo local para complementos de SharePoint.
La figura 4 muestra los tipos de aplicaciones que se pueden crear usando un entorno virtualizado local.
Figura 4. Desarrollo local con un entorno virtual
[
Los desarrolladores pueden llevar a cabo un desarrollo remoto para las aplicaciones hospedadas en SharePoint y en la nube en sus propias granjas de SharePoint, así como el desarrollo de soluciones de granja de servidores de plena confianza. Estas granjas, a menudo, están hospedadas en un servidor de virtualización que se ejecuta en la estación de trabajo del desarrollador o en una nube privada de virtualización centralizada a la que pueden obtener acceso fácilmente los desarrolladores. El entorno de la granja de SharePoint suele estar separado de las granjas de otros desarrolladores y ofrece un nivel de aislamiento que es necesario al desarrollar código de plena confianza que puede obligar a reiniciar los servicios críticos (es decir, IIS).
El desarrollo remoto y el desarrollo de código de plena confianza pueden ocurrir dentro de la granja independiente, ya que cada granja de desarrollo está aislada y dedicada a un solo desarrollador.
Las organizaciones o los desarrolladores tendrán que administrar y actualizar las granjas de SharePoint que se ejecutan dentro de los equipos virtuales. Para los desarrolladores que contribuyen a una sola aplicación, debe mantenerse la paridad entre las granjas de desarrollo que se ejecutan dentro de los equipos virtuales. Esta práctica garantiza que todos los componentes del código desarrollado para la aplicación sean coherentes. Otras consideraciones comunes son una configuración estándar para las granjas, incluyendo el acceso al dominio y las credenciales, las credenciales de aplicaciones de servicio, identidades o cuentas de prueba y otros elementos de configuración del entorno (como los certificados).
Al igual que una granja centralizada para sitios de desarrollo, estas máquinas virtuales que ejecutan granjas de SharePoint de desarrollador pueden hospedarse en plataformas de IaaS, como Microsoft Azure, y en ofertas de nube privada local.
Aunque las máquinas virtuales ofrecen una gran cantidad de aislamiento e independencia respecto a otras máquinas virtuales de desarrollador, los equipos deben esforzarse por lograr la uniformidad entre las configuraciones de las máquinas virtuales. Esto incluye un dominio, una cuenta, una seguridad y unas configuraciones de SharePoint comunes, así como una conexión a un repositorio de control de origen, como Visual Studio Team Foundation Server (TFS).
Consideraciones sobre diseño de ALM
Al construir aplicaciones de SharePoint, hay que tener en cuenta varios aspectos para ofrecer las prácticas habituales de desarrollo y de control para conseguir coherencia y calidad. Al aplicar los principios de ALM al desarrollo de aplicaciones de SharePoint, los desarrolladores deben centrarse en consideraciones técnicas y en consideraciones controladas por procesos.
La compatibilidad de una plataforma de ALM, como Visual Studio Team Foundation Server 2012, suele ser un requisito al llevar a cabo el desarrollo de aplicaciones, especialmente cuando hay equipos de desarrolladores que trabajan en el mismo conjunto de proyectos. Las aplicaciones de SharePoint, al igual que otras soluciones técnicas, requieren la administración y el control de versiones de repositorios de código, servicios de compilación, servicios de pruebas y prácticas de administración de versiones. La siguiente sección describe las consideraciones para la ALM según los distintos modelos de aplicación para las aplicaciones de SharePoint.
Información general
Para cada tipo de aplicación de SharePoint, las consideraciones de ALM deben aplicarse sin variaciones de concepto. Sin embargo, las prácticas y los procesos relativos a la compilación, las pruebas y la administración de cambios deben ajustarse.
Algunas aplicaciones de SharePoint usan tecnologías del lado cliente. La mayoría de los desarrolladores con experiencia en el desarrollo de aplicaciones de SharePoint Server 2010 tendrán que adaptarse a desarrollar y aplicar los principios de ALM a código no compilado. Esta adaptación incluye la aplicación de conceptos como "compilación" a una solución que puede no tener código compilado. Las plataformas de ALM como Visual Studio 2012 tienen capacidades integradas para validar compilaciones compilando primero el código y, luego, ejecutando pruebas de comprobación de la compilación (BVT) en la compilación.
Para las aplicaciones de SharePoint, el proceso de compilación y pruebas debe estar en armonía con los procesos de desarrollo de aplicaciones tradicionales. Esto incluye la creación de un programa de compilación por parte de la plataforma de ALM, que compilará la solución y la implementará en el entorno de destino.
Procesos de compilación
Los procesos de compilación de aplicaciones de SharePoint los facilita la plataforma de ALM. Visual Studio Team Foundation Server 2012 ofrece servicios de compilación y de pruebas que se pueden desencadenar al registrar la solución Visual Studio 2012 (integración continua) o en intervalos programados especificados.
Componentes de compilación de SharePoint
Al planificar los procesos de compilación para el desarrollo de aplicaciones de SharePoint, los desarrolladores deben tener en cuenta las interacciones entre los componentes, como se muestra en la figura 5.
Figura 5. Componentes de compilación de las aplicaciones hospedadas en SharePoint
La figura 5 es una representación lógica de una aplicación de SharePoint. Esta figura muestra una Complementos hospedados en SharePoint y destaca objetos de aplicación clave como parte de un proyecto de Complementos hospedados en SharePoint de Visual Studio 2012. El proyecto de aplicación de SharePoint contiene las características, el paquete y el manifiesto que se registrarán con SharePoint. El proyecto también contiene páginas, bibliotecas de scripts y otros elementos de experiencia de usuario que constituyen la aplicación de SharePoint. Además, el proyecto de SharePoint tiene archivos auxiliares que incluyen los certificados necesarios para la implementación en un entorno de SharePoint de destino.
Figura 6. Componentes de compilación de aplicación hospedados por un proveedor y autohospedados
La figura 6 muestra una aplicación hospedada en la nube de SharePoint (es decir, autohospedada u hospedada por un proveedor). La principal diferencia en la estructura del proyecto es que la solución de Visual Studio 2012 contiene un proyecto de aplicación de SharePoint además de uno o varios proyectos que contienen los componentes de la aplicación hospedada en la nube. Estos pueden ser aplicaciones web, proyectos de bases de datos SQL o aplicaciones de servicio que se implementarán en Azure o en una infraestructura hospedada por un proveedor local (como ASP.NET) y otros componentes de la solución. Para obtener instrucciones sobre el empaquetado y la implementación con aplicaciones de elevada confianza, vea Empaquetar y publicar complementos de SharePoint de alta confianza.
Figura 7. ALM con Visual Studio Team Foundation Server
La figura 7 muestra TFS como la plataforma de ALM. Los equipos usarán TFS para almacenar código y llevar a cabo el desarrollo en equipo usando TFS implementado localmente o usando servicios TFS de Microsoft basados en la nube. TFS se puede configurar para llevar a cabo actividades de compilación e implementación con una aplicación de SharePoint a través de las definiciones de compilaciones. TFS también puede usarse para llevar a cabo pruebas de comprobación de compilación (BVT) que se pueden automatizar mediante la ejecución de pruebas de UI codificadas que forman parte de la definición de compilación.
Figura 8. Destinos de compilación de TFS
La figura 8 muestra entornos de destino donde scripts ejecutados por una definición de compilación de TFS ejecutarán los componentes de la aplicación de SharePoint. En las aplicaciones hospedadas en SharePoint, esto incluye la implementación en SharePoint Online o en catálogos de aplicaciones de SharePoint local.
En las aplicaciones de SharePoint hospedadas en la nube, los componentes de la solución que requieren infraestructura adicional fuera de SharePoint se implementan en entornos de destino. En las aplicaciones autohospedadas, se hace en Microsoft Azure. En las aplicaciones hospedadas por el proveedor, esta infraestructura puede ser Microsoft Azure u otros entornos locales u hospedados en IaaS.
Crear una compilación para aplicaciones de SharePoint
TFS ofrece servicios de compilación que pueden compilar soluciones protegidas por control de código fuente y colocar la salida en una ubicación de entrega centralizada para la implementación en entornos de destino de manera automática. El método principal para configurar TFS y llevar a cabo compilaciones, implementaciones y pruebas automáticas de las aplicaciones de SharePoint consiste en crear una definición de compilación en Visual Studio. La definición de compilación contiene información sobre qué proyectos de código se deben compilar, así como las actividades posteriores a la compilación, como la implementación de prueba y real en los entornos de destino. Para obtener más información sobre el servicio Team Foundation Build, consulte Configuración del servicio de compilación de Team Foundation.
Para lograr la integración continua, la definición de compilación se puede activar cuando los desarrolladores protejan el código. Además, la definición de compilación puede programarse para que se ejecute a intervalos establecidos.
En el caso de las aplicaciones de SharePoint, los desarrolladores deben usar el proyecto de definiciones de compilación de Integración continua de Office/SharePoint con TFS 2012 para lograr compilaciones programadas o integración continua. Este proyecto ofrece definiciones de compilación, scripts de Windows PowerShell e instrucciones de procesos sobre cómo configurar Visual Studio Team Services o una versión local de TFS para compilar e implementar aplicaciones de SharePoint en un modelo de integración continua. Los programadores deben descargar los componentes de este proyecto y configurar su instancia de TFS como corresponda. Si quiere instrucciones sobre cómo configurar TFS con la definición de compilación proporcionada para las aplicaciones de SharePoint y configurar la definición de compilación para que use los scripts de Windows PowerShell a la hora de implementar la aplicación de SharePoint en un entorno de destino, vea la documentación de la integración continua de Office/SharePoint con TFS 2012.
Configurar procedimientos de compilación e implementación
La figura 9 muestra un proceso estándar para las compilaciones e implementaciones de aplicación de SharePoint cuando la definición de compilación se ha creado, configurado e implementado en la instancia de TFS del equipo.
Figura 9. Proceso de compilación e implementación con TFS
[Los 
El desarrollador protege la solución Visual Studio 2012 de la aplicación de SharePoint. Dependiendo de la configuración deseada (es decir, integración continua o compilación programada), los servicios de compilación de TFS ejecutarán los pasos establecidos en la definición de compilación de la aplicación de SharePoint. Esta definición, configurada por los desarrolladores, contiene la plantilla del proceso de compilación de integración continua, así como las instrucciones posteriores a la compilación para ejecutar scripts de Windows PowerShell para la implementación de la aplicación. Las extensiones del Shell de administración de SharePoint Online serán necesarias para implementar la aplicación en SharePoint Online. Para obtener más información sobre las extensiones del Shell de administración de SharePoint Online, vea la página Shell de administración de SharePoint Online en el Centro de descarga.
Cuando la compilación se haya desencadenado, TFS compilará los proyectos asociados con la aplicación de SharePoint y ejecutará scripts de Windows PowerShell para implementar la solución en el entorno de SharePoint de destino.
Confiar en la aplicación de SharePoint
Tras implementar los componentes de la aplicación en los entornos de destino, es importante recordar que antes de que se pueda obtener acceso a la aplicación, incluidas las pruebas que puedan formar parte de la compilación, un administrador de inquilinos (o de colecciones de sitios) tendrá que confiar en la aplicación yendo a la página de información de la aplicación en SharePoint. Este requisito se aplica a las aplicaciones autohospedadas y a las hospedadas en SharePoint. Este proceso manual representa un cambio en el proceso de compilación, ya que las pruebas que normalmente se ejecutarían tras la implementación en el entorno de destino tendrán que suspenderse hasta que se confíe en la aplicación.
Para las aplicaciones hospedadas en la nube (por el proveedor y autohospedadas), los desarrolladores pueden implementar los componentes que no sean de SharePoint en la infraestructura basada en la nube independientemente del paquete de aplicación que se implemente en SharePoint.
Figura 10. Implementar componentes que no son de SharePoint
[
Como se ve en la figura 10, cuando los desarrolladores hacen cambios en la solución que representa la aplicación de SharePoint, puede haber circunstancias en las que se hagan cambios a los proyectos incluidos en la solución que no se apliquen al propio proyecto de la aplicación de SharePoint. En este caso, el proyecto de aplicación de SharePoint no tiene que volver a implementarse porque no ha cambiado. Los cambios asociados con los proyectos hospedados en la nube deberán volver a implementarse.
Los cambios en la aplicación que se implementará en infraestructura externa a SharePoint se pueden hacer independientemente de los componentes de la aplicación que se implementan en el inquilino o la colección de sitios de destino. Para los desarrolladores, esto significa que se puede crear un proceso de compilación automática para implementar los componentes hospedados en la nube de forma frecuente (desencadenada) e independientemente del proyecto de la aplicación de SharePoint. Por lo tanto, el paso manual para aprobar el permiso de la aplicación en la página de información de la aplicación en SharePoint no es necesario, lo que permite un proceso de implementación y pruebas para la definición de compilación más continuo. El componente de la aplicación de SharePoint de la solución solo tendría que implementarse en el caso de que los elementos incluidos en el proyecto cambiaran y requiriesen una nueva implementación.
Pruebas
Como se describe en la sección de procesos de compilación, probar las aplicaciones es un método de saber si la compilación y la implementación de la aplicación se han hecho correctamente. Al usar las pruebas como medio de comprobar la compilación y la implementación de la aplicación, el equipo puede conocer la calidad y saber cuándo un cambio reciente en el código de la aplicación ha puesto en peligro la aplicación de SharePoint.
La figura 11 muestra los tipos de métodos de pruebas más convenientes para usar con los modelos de aplicación de SharePoint.
Figura 11. Métodos de prueba
[
La figura 11 sugiere el uso de diferentes tipos de pruebas para probar las aplicaciones de SharePoint por tipo. Las pruebas de UI codificadas deben usarse en aplicaciones hospedadas en SharePoint donde la lógica de negocios y la experiencia de usuario residen en la misma capa. Mientras que la lógica de negocios puede extraerse de bibliotecas de JavaScript, el medio principal de probar esa lógica es a través de la experiencia de usuario.
Las aplicaciones hospedadas en la nube (es decir, autohospedadas y hospedadas por el proveedor) pueden usar pruebas de UI totalmente codificadas a la vez que pruebas unitarias para la verificación de los componentes de servicio de la solución. Esto proporciona al desarrollador seguridad en la calidad de la implementación de la infraestructura de hospedaje de la aplicación desde una perspectiva funcional.
En las siguientes secciones vemos las consideraciones de las pruebas de UI codificadas y otros tipos de pruebas en relación con las aplicaciones de SharePoint.
Código del lado del cliente y pruebas de la interfaz de usuario codificadas
Para las pruebas de comprobación de compilación (BVT), así como las pruebas de todo el sistema, se recomiendan las pruebas de UI codificadas. Estas pruebas se basan en acciones grabadas para probar no solo la lógica de negocio y el nivel intermedio de la aplicación, sino también la experiencia de usuario. Para las aplicaciones de SharePoint que usan código del lado cliente, gran parte de los puntos de entrada y la ejecución de la lógica de negocio puede existir en el nivel de experiencia de usuario. Por este motivo, las pruebas de UI codificadas no solo pueden probar la experiencia del usuario, sino además la lógica de negocio de la aplicación. Para obtener más información sobre la prueba automatizada de IU, consulte Comprobación del código mediante Automatización de la interfaz de usuario.
Las pruebas de UI codificadas se pueden usar en Complementos hospedados en SharePoint donde gran parte de la lógica de negocio y de la experiencia de usuario puede mezclarse. Estas pruebas, como otras, se pueden ejecutar desde una definición de compilación en TFS para que puedan comprobar las funciones de una aplicación tras la implementación (y después de que SharePoint haya confiado en la aplicación).
Pruebas de la interfaz de usuario no codificadas
Para los casos donde la lógica de la aplicación existe fuera de la capa de experiencia de usuario de la aplicación, como en las aplicaciones hospedadas en la nube, hay que recurrir a una combinación de pruebas de UI codificadas y pruebas de UI no codificadas. Algunas pruebas, como las unitarias tradicionales, pueden usarse para validar la calidad de compilación de la lógica del servicio que se implementa en una infraestructura hospedada por el proveedor. Esto le da al desarrollador una confianza integral en los componentes hospedados por el proveedor de la función de la solución y se tratan desde un punto de vista de prueba.
Pruebas de rendimiento y carga web
Las pruebas de carga y rendimiento web ofrecen a los desarrolladores la confianza de que la aplicación funciona bajo cargas de usuarios esperadas o anticipadas. Estas pruebas incluyen determinar la capacidad de la aplicación para controlar simultáneamente una base de usuarios predecible que escalará razonablemente con el tiempo. Tanto las pruebas de UI codificadas como las pruebas unitarias pueden ser el origen de las pruebas de carga y rendimiento web. Con una plataforma de ALM como TFS, estas pruebas pueden usarse para hacer pruebas de carga en la aplicación.
Recuerde que probar la infraestructura no es el objetivo principal de estas pruebas al usarlas para probar las aplicaciones de SharePoint. La infraestructura, ya esté hospedada en SharePoint o en el proveedor, debe tener establecida una línea de base de carga y rendimiento similar. Las pruebas de carga y rendimiento web para la aplicación resaltarán los desafíos de la infraestructura, pero deben considerarse, principalmente, como un medio para probar el rendimiento de la aplicación.
Para obtener más información sobre el rendimiento web y las pruebas de carga, consulte Ejecución de pruebas de rendimiento en una aplicación antes de una versión.
Entornos de prueba y calidad
Muchas organizaciones tienen varios entornos de prueba que pueden ser físicos o virtuales e independientes unos de otros. Estos entornos pueden variar en función del proceso de ALM de un equipo, los requisitos normativos o una combinación de ambos. Para averiguar el número y los tipos de entornos de prueba que los equipos deben usar, las siguientes instrucciones se basan en prácticas funcionales específicas de las aplicaciones de SharePoint, pero también usan prácticas de ALM para el desarrollo de software en general.
Pruebas de desarrolladores
Las pruebas de los desarrolladores pueden hacerse en el entorno donde los desarrolladores están creando su componente de la solución. Cuando haya varios desarrolladores trabajando en distintos aspectos o componentes de una aplicación mayor, cada uno de ellos tendrá las pruebas unitarias, pruebas de UI codificadas y el código de la aplicación implementados en su sitio de desarrollo.
Figura 12. Proceso de pruebas de desarrollador
[
Los desarrolladores ejecutarán en Visual Studio pruebas de los componentes de la solución implementados en su propio Office 365 o en el sitio local para desarrolladores. En las aplicaciones hospedadas en la nube, también se ejecutarán pruebas desde Visual Studio en los componentes de la solución que residan en infraestructura hospedada por el proveedor. Estos componentes residirán en la suscripción a Microsoft Azure del desarrollador.
En este método se presupone que los desarrolladores tienen sitios de desarrollador de Office 365 y suscripciones a Microsoft Azure individuales, que se suministran a través de las suscripciones de MSDN. Aunque los desarrolladores creen aplicaciones para la implementación local, estos servicios de desarrollador pueden usarse para desarrollo y pruebas.
Si lo desarrolladores no tienen estos servicios o tienen que hacer toda la implementación de forma local, ejecutarán pruebas para sus componentes en una colección de sitios de desarrollador y una infraestructura hospedada por el proveedor y específica del proveedor de una granja local. La infraestructura hospedada por el proveedor puede residir en máquinas virtuales dedicadas a los desarrolladores. Para el desarrollo de soluciones de confianza plena, los desarrolladores requerirían su propia granja virtual de SharePoint y su propia infraestructura hospedada por el proveedor.
Pruebas de integración y sistemas
Con el fin de probar la aplicación, todos los componentes de desarrollo deben montarse e implementarse en un entorno centralizado. Este entorno de integración proporciona un lugar donde los desarrolladores pueden implementar y observar los componentes de la solución que crearon interactuando con otros componentes de la solución escritos por otros desarrolladores.
Figura 13. Entorno de prueba de integración
[
Para este tipo de pruebas, la plataforma ALM compilará e implementará la aplicación de SharePoint y los componentes necesarios en los entornos de destino. Para las aplicaciones hospedadas en SharePoint, este será un sitio de Office 365 o una colección de sitios de SharePoint local o de IaaS específicamente establecida para las pruebas de integración y sistemas. Para aplicaciones de SharePoint hospedadas en la nube, TFS también implementará los componentes en una suscripción de Microsoft Azure centralizada donde los servicios se configurarán especialmente para las pruebas de integración y sistemas. Luego, TFS ejecutará pruebas de interfaz de usuario codificadas o unitarias en la aplicación de SharePoint, así como en los componentes que la solución requiera en la infraestructura hospedada.
UAT y pruebas de QA
Para las pruebas de aceptación del usuario (UAT, por sus siglas en inglés), las organizaciones suelen tener entornos independientes donde esta función se lleva a cabo al margen de las pruebas de integración y sistemas. Separar estos entornos de prueba impide que el ritmo de lanzamiento continuo automático y las pruebas interfieran con las actividades de UAT en las que los usuarios puedan estar ejecutando pruebas en una compilación determinada de la aplicación a lo largo de un período de tiempo prolongado.
Figura 14. Pruebas de UAT
[
Como se ve en la figura 14, los usuarios asignados a la realización de pruebas de aceptación o pruebas organizativas de recursos llevan a cabo scripts de prueba en un entorno estable que se centra en una compilación muy difundida de la aplicación. Mientras la implementación del código y las pruebas se siguen haciendo en el entorno de integración, los usuarios llevan a cabo pruebas manuales para validar que la aplicación cumpla el uso obligatorio o casos de prueba. La aplicación y las infraestructuras hospedadas por el proveedor serán implementadas, normalmente por un administrador de versiones, en este entorno de prueba. También es posible una implementación automatizada. Este tipo de implementación usa una definición de compilación UAT dedicada en TFS que refleja la que lleva a cabo la implementación para el entorno de pruebas de integración y sistemas.
En una infraestructura hospedada en la nube, es posible realizar la implementación en una suscripción a Microsoft Azure que se comparta con los entornos de prueba de sistemas e integración si los servicios se nombran y configuran para implementarlos en paralelo como servicios o bases de datos diferentes. Este método ofrece un conjunto de servicios y bases de datos en la suscripción a Microsoft Azure de prueba para las pruebas de integración y sistemas, así como pruebas de UAT y QA, como se muestra en la figura 15.
Ilustración 15. Pruebas de UAT e integración
[
Prácticas de promoción de código
El proceso de promoción de código entre los entornos de desarrollo y pruebas, así como el entorno de producción, debe hacerse siguiendo un proceso de administración de lanzamiento bien definido. En la figura 16, los desarrolladores llevan a cabo la implementación de los componentes de la solución en entornos de desarrollo para pruebas unitarias.
Ilustración 16. Proceso de administración de lanzamientos
[
Tras aplicar una protección a TFS, un proceso de compilación automático compilará e implementará la solución en el entorno de prueba de integración y sistemas de destino donde se ejecutarán pruebas de comprobación de compilación como parte de la definición de compilación en TFS. Este método incluye la implementación de los componentes de la solución hospedados por el proveedor en el entorno de destino (Microsoft Azure o entornos locales). Para la infraestructura de Microsoft Azure, la suscripción a Microsoft Azure puede ser la misma que se usa para las pruebas de integración y sistemas, así como para las pruebas UAT y QA suponiendo que se implementen en espacios de nombres distintos y en bases de datos SQL independientes.
Un administrador de versiones o una definición de compilación TFS independiente, invocada manualmente en la mayoría de los casos, puede implementar en el entorno de UA o TQA. Este método ayuda a controlar la versión de compilación que van a probar los usuarios. Los administradores de versiones pueden recoger las compilaciones desde un recurso compartido TFS y ejecutar el proceso de implementación ellos mismos. Desde la promoción hasta la producción, la administración de versiones se usará para implementar la aplicación en el entorno de producción y supervisar su instalación y comprobación de la compilación haciendo pruebas.
Aplicación de parches y actualizaciones
Microsoft tiene instrucciones específicas sobre cómo los desarrolladores de aplicaciones pueden actualizar las aplicaciones. La plataforma de SharePoint admite la notificación de nuevas versiones de aplicaciones a los usuarios.
Para obtener consideraciones sobre cómo establecer una estrategia en torno a las actualizaciones y revisiones de aplicaciones de SharePoint, vea Actualizar complementos de SharePoint.
Para cambios en las aplicaciones, el patrón recomendado que se debe seguir es acorde con los patrones existentes de desarrollo de código y de ingeniería sostenida. Esto incluye la bifurcación y la combinación sistemáticas de correcciones de errores y desarrollo de características, así como implementaciones incrementales en catálogos de aplicaciones de destino. La guía anterior puede usarse para completar cambios en las aplicaciones para SharePoint e implementarlas en los catálogos de aplicaciones de destino o en el almacén.
La información del proceso de actualización de complementos de SharePoint proporciona instrucciones tácticas adicionales sobre las técnicas para actualizar aplicaciones de SharePoint. Esto incluye acelerar las pruebas de implementación acortando el ciclo que hace que las actualizaciones de las aplicaciones se reflejan en la granja de servidores en entornos de prueba. Además, este artículo ofrece instrucciones sobre cómo hacer ajustes según el estado en diversos modelos de implementación de aplicaciones.