Integración Continua para Apps Office 365 con Visual Studio Online y Azure

Escrito por Adrian Diaz Cervera - 27/08/2015

Desde la primera versión de SharePoint, allá en 2003, los equipos de desarrollo tradicionalmente han tenido muchos problemas con el despliegue de la solución en otros entornos. Motivos hay muchos, en primer lugar la propia plataforma que fue creciendo exponencialmente el número de usuarios respecto a los desarrolladores que había, pero de la misma forma no hay que quitar responsabilidad a los equipos de desarrollo. Este hecho provoco que trabajar con SharePoint fuera un problema para muchos desarrolladores que venían de otros entornos más simples (Aplicaciones escritorio, Web,…). Ahora bien como todo buen producto, fue evolucionando y se fue adaptando a la misma forma que se hace en otras aplicaciones (con alguna peculiaridad propia de la plataforma).  En este artículo vamos a ver como configurar la Build de nuestro Visual Studio Online para realizar integración continua.

¿Qué es integración continua?

La integración continua es un modelo informático propuesto inicialmente por Martin Fowler que consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes. Entendemos por integración, la compilación y ejecución de pruebas de todo un proyecto. Las principales ventajas que tiene son:

  • Permite detectar y solucionar problemas de integración de forma continua, evitando el caos de última hora cuando se acercan las fechas de entrega.
  • Disponibilidad constante de una versión para pruebas, demos o lanzamientos anticipados.
  • Monitorización constante de las métricas del código.
  • Ejecución inmediata de pruebas (Unitarias, UI, Performance).

Sobre Visual Studio Online

Aunque por su nombre quizás pueda llevar a confusión Visual Studio Online (VSO) es la herramienta proporcionada por Microsoft para gestionar todo el ciclo de vida o Application Lifecycle Management (ALM) de una aplicación. Este proceso empieza mucho antes de que cualquier desarrollador escriba una línea de código y no termina cuando se pone la primera versión en producción.

Con VSO, se puede llevar la planificación del propio proyecto, aplicar una metodología ágil, separar/asignar  tareas,  llevar el control del código fuente (bien con repositorios centralizados como Team Foundation Server o con repositorios distribuidos como Git) e incluso realizar el despliegue de nuestro desarrollo en diferentes entornos (este último aspecto es el que vamos a tratar en este artículo).

Visual Studio Online es gratis para equipos de hasta 5 desarrolladores, lo que hace que para empresas pequeñas o que acaban de empezar les sea de gran utilidad. Por lo general cuando analizamos la utilización de un producto Online respecto a uno OnPremise se valora si tienen las mismas características. En este caso Visual Studio Online tiene más características que la solución en OnPremise debido a que ya tienen instaladas todas las utilidades necesarias para integración continua, por ejemplo, para SharePoint en un entorno local necesitaríamos instalar las librerías de del servidor.

Manos a la obra

En primer lugar, partimos de la base que disponemos de una App de SharePoint del tipo Provider-Hosted. Como proveedor de alojamiento vamos a utilizar Azure. Para ello:

  • Abrimos Visual Studio -> Templates -> Visual C# -> Office /SharePoint -> Apps-> App for SharePoint.
  • A continuación, seleccionamos el tipo de alojamiento Provider-Hosted para nuestra aplicación.
Imagen 1.- Asistente para crear una Aplicación Provider-Hosted en Visual Studio. 
  • Seleccionamos el tipo de autenticación que vamos a utilizar. En caso de Office 365 utilizaremos Windows Azure Access Control Service, si estamos en un entorno On Premise utilizaremos un Certificado de una entidad autorizada.
Imagen 2.- Configuración del modo de autenticación. 
  • Una vez tenemos la estructura del proyecto creada publicaremos la Aplicación MVC en un sitio de Azure. Para ello en primer lugar nos dirigimos al explorador de soluciones, se selecciona la aplicación MVC, botón derecho y pulsar sobre Publicar.
Imagen 3.- Publicación de la App 
  • Dentro de las opciones disponibles Seleccionaremos Microsoft Azure Web Apps.
Imagen 4.- Selección de publicación en Azure Web Apps. 
  • A continuación se crea o utiliza una Web Apps ya existente:
Imagen 5.- Datos de despliegue de la App en Azure. 
  • Haga clic en Siguiente y seleccione la forma en la que se va a desplegar bien en modo depuración (debug) bien en producción (release). A continuación, se pulsa sobre Publish.

Crear el servicio de Visual Studio Online en Azure

En la subscripción de Azure hay que crear el servicio de Visual Studio Online para permitirle acceder al repositorio de código fuente. Para ello:

  • Vaya al Portal de Azure, seleccione su servicio en la nube o sitio web, o bien cree uno nuevo. Para ello, seleccione el icono + en la parte inferior izquierda y elija Servicio en la nube o Sitio web y, a continuación, Creación rápida. Haga clic en el vínculo Configurar publicación con Visual Studio Online.
Imagen 6.- Creación del servicio de Visual Studio Online. 
  • En el asistente, escriba el nombre de la cuenta de Visual Studio Online en el cuadro de texto y haga clic en el vínculo Autorizar ahora. Puede que se le solicite que inicie sesión.
Imagen 7.- Autorización a VSO. 
  • En el cuadro de diálogo emergente de OAuth, elija Aceptar para autorizar a Azure a que configure el proyecto de equipo en VSO.
Imagen 8.- Solicitud de acceso al Repositorio 
  • Si la autorización se realiza correctamente, verá una lista desplegable que contiene los proyectos de equipo de Visual Studio Online. Seleccione el nombre del proyecto de equipo que ha creado en los pasos anteriores y presione el botón de la marca de verificación del asistente.
Imagen 9.- Selección de repositorio a desplegar 
  • Una vez que el proyecto se haya vinculado, verá instrucciones para registrar los cambios en el proyecto de equipo de Visual Studio Online. La próxima vez que se registre, Visual Studio Online compilará e implementará el proyecto en Azure. Para probarlo ahora, haga clic en el vínculo Proteger desde Visual Studio y, a continuación, en Iniciar Visual Studio (o el botón equivalente de Visual Studio situado en la parte inferior de la pantalla del portal).
Imagen 9.- Creación del Servicio 

Tareas Previas

El punto de partida para empezar con la integración continua de las Aplicaciones es el siguiente paquete de Codeplex: https://officesharepointci.codeplex.com/ 

Este paquete tiene dos carpetas:

  1. BuildProcessTemplates: Ficheros xml que tienen la serie de requisitos que va a realizar la build.
  2. DeployScript: Una serie de Script PowerShell para poder instalar la aplicación en los entornos necesarios. Estos Scripts no asumen que la aplicación ya existe.

El proyecto de CodePlex que estamos utilizando asume que la aplicación ya está registrada en tu entorno. Para las pruebas en primer lugar vamos a registrar la aplicación para ello iremos a https://sitiodeveloper/_layouts /appregnew.aspx y registrar la aplicación.

Imagen 10.- Registro de la App en el entorno de desarrollo. 

Con el ID Cliente y la Clave Secreta la introducimos en la aplicación. Por un lado dentro de los parámetros del Web.config y por otro lado en el manifiesto de la APP de SharePoint tal y como visualizamos en la siguiente imagen:

Imagen 11.- Actualización de los archivos Web.config y de manifiesto de la App 

Agregar el paquete de Codeplex dentro de nuestro Repositorio de Código

Para agregar el paquete en el repositorio de código:

  • Copiar las carpetas "DeployScripts"  y "BuildProcessTemplates"  descargadas del Proyecto de Codeplex dentro de la carpeta del Proyecto.
  • Ahora que la estructura de las carpetas esta de la manera en la que este dentro del repositorio de código fuente. Hacer clic con el botón derecho en el nodo del proyecto en el Explorador de control de código fuente y elegir "Add Items to Folder"
Imagen 12.- Inicio de mapeo en TFS 
  • Se advierte que hay dos elementos que han cambiado en el proyecto existente. Aceptamos y elegimos todos los elementos a añadir.
  • A continuación, llega la hora de indicar los valores en los que nosotros queremos realizar la modificación. Para ello vamos a la carpeta DeployScripts/SharePointApp/Parameters Aquí es donde añadimos los valores de nuestro Office 365, SharePoint OnPremise o Web Deployment (en caso de que no sea una Web APP de Azure).
Imagen 13.- Configuración de los parámetros de despliegue. 

Crear una definición de la Build

Una vez ya tenemos el servicio de Visual Studio Online funcionando en Azure, crearemos una definición de la Build en el que configuraremos la integración continua. En estas definiciones se puede configurar varios aspectos:

  • Evento que provoca que se ejecute: por ejemplo cada check-in
  • Periodicidad: todos los días a una determinada hora, etc…

Es posible (a la vez que recomendable) que en cada proyecto tengamos varias definiciones, es posible que nos interese diariamente desplegar nuestros desarrollo en un entorno de preproducción, pero también es necesario por ejemplo que cada vez que se suba un cambio se testeen si se han pasado las pruebas unitarias o se han cumplido los requisitos de calidad establecidos.

  • Abrimos Visual Studio, en el explorador de soluciones pulsar sobre la pestaña Team Explorer y seleccionar sobre el icono de Builds.
Imagen 14.- Acceso a la sección de Builds 
  • Pulsamos sorbe la Opción de New Build Definition:
Imagen 15.- Opción New Build Definition 
  • A la hora de la creación tendremos una serie de pestañas laterales en la que agregaremos la configuración de la Build.
    • Trigger; Esto parámetro establece cada cuento tiempo queremos ejecutar la BUILD. Dependiendo de lo que realice la definición optaremos una solución u otra. Quizás subir a un entorno de Integración solo lo queremos realizar una vez al día, pero por el contrario sí que queremos que cada Check In que se realice se analice el código subido al gestos del código fuentes. Todas estas opciones las configuramos en la siguiente pantalla:
Imagen 16.- Pestaña Trigger en la configuración de la build. 
    • Source Settings: Agregaremos los proyectos que se van a compilar en cada Build.
    • Build Defaults: Seleccionamos el Build Controller y la ubicación donde va a estar el resultado de la build.
Imagen 17.- Pestaña Build Defaults en la configuración de la build 
    • Process: En esta opción seleccionamos el Template que vamos a utilizar para esta Build, para realizar la integración continua con las APP seleccionaremos el template que nos hemos descargado de CodePlex (más adelante veremos cómo personalizar este template)
Imagen 18.- Selección del Template para la Build 

Dentro de los parámetros de este proceso de Build tendremos que añadir lo siguiente:

    1. Advanced-> MSBuild Arguments: /p:ActivePublishProfile="perfil de Azure"
    2. Misc-> Deployment Script Ruta donde hemos dejado el fichero SharePointAppDeloy.ps1 (descargado previamente de Codeplex)
Imagen 19.- Parámetros del proceso de Build a añadir 
  • A continuación, ejecutamos la build de forma manual y si todo ha ido bien se muestra una pantalla como la siguiente:
Imagen 20.- Ejecución de la Build 

Conclusión

El proceso de ALM es muy necesario en cualquier plataforma y Office 365/SharePoint no es una excepción, en este artículo hemos visto como configurar un proceso de integración continua para nuestras Apps.  Este proceso, conforme a las necesidades de cada equipo y a los requisitos, se va mejorando con otras definiciones de Build, definiciones que se pueden encargar de verificar la calidad del código descrito, de pasar los Test Unitarios, pruebas de carga y/o de la interfaz.

 
Adrián Diaz Cervera
SharePoint Architect at Encamina
MVP SharePoint Server
http://blogs.encamina.com/desarrollandosobresharepoint
http://geeks.ms/blogs/adiazcervera     
adiaz@encamina.com @AdrianDiaz81
***