Desarrollo e implementación de un sistema basado en arquitectura de soluciones en Microsoft Azure y Dynamics CRM 365 Online, integrando DEVOPS

Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática Mención en Tecnologías de la Información Desarrollo e implementación de un sistema basado en arquitectura de soluciones en Microsoft Azure y Dynamics CRM 365 Online, integrando DEVOPS Alumno: Marcos Muñoz Núñez Tutor: Benjamín Sahelices Fernández Desarrollo e implementación de un sistema basado en arquitectura de soluciones en Microsoft Azure y Dynamics CRM 365 Online, integrando DEVOPS Marcos Muñoz Núñez Dedicado a mi madre por todo su apoyo durante estos años Agradecimientos A mi familia por haber hecho posible mis estudios como Ingeniero Informático. A su apoyo, ánimos e insistencia en mi les debo muchísimo. A mis compañeros quienes después de tantas practicas, horas de estudio y charlas de informáticos han llegado a ser una de las mejores cosas que me llevo de la carrera. A mis amigos de la Asociación AreaUrbana, quienes han alimentado mi curiosidad y ganas de aprender mas y con los que he compartido grandes logros. A Alberto Casero y Álvaro Estebanez que me han guiado y apoyado hasta aquí, y a el resto de compañeros de Everis que en los últimos meses han hecho este camino mucho mas interesante. A mi tutor Benjamín Sahelices por ayudarme a completar esta etapa de mi vida. Y a todos los que me habéis acompañado y apoyado a lo largo esta etapa. Gracias Resumen Dynamics 365 es un sistema CRM Online altamente personalizable y ampliable en cuyos desarrollos buscamos implementar metodologías y herramientas DevOps, apoyándonos en los recursos en la nube que provee Microsoft Azure. El objetivo de esta implementación es crear las bases de un sistema de Integración Continua que ayude a facilitar y acelerar los desarrollos sobre Dynamics 365. Para ello se ha realizado un estudio del contexto tecnológico y las herramientas que las que se dispone. Con esta información y conocimiento adquirido se ha realizado un análisis, diseño y pruebas de concepto que ha concluido en la implementación de los casos de uso analizados utilizando las herramientas que Azure DevOps pone a nuestra disposición. Este trabajo se enfoca desde el interior de uno de los equipos de desarrollo de Dynamics 365 CRM de Everis Palabras clave: DevOps, Cloud, Integración Continua, Dynamics 365, CRM, Pipelines, Azure. vii Índice general xiv Marcos Muñoz Núñez Índice de figuras 2.1. Comparación Modalidades Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Arquitectura Dynamics 365 on Premise . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Arquitectura Dynamics 365 Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Componentes de las Soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Arquitectura de Soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6. Interfaz Azure Boards: Tablero Kanban . . . . . . . . . . . . . . . . . . . . . . . . 16 2.7. Interfaz Azure Pipelines: Ejecución Pipeline . . . . . . . . . . . . . . . . . . . . . 18 2.8. Interfaz Azure Pipelines: Release Pipeline . . . . . . . . . . . . . . . . . . . . . . . 18 2.9. Conectividad Agentes Locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.10. Interfaz Azure Repos: Archivos Repositorio GIT . . . . . . . . . . . . . . . . . . . 22 2.11.PaneldeTareasPlanner ................................ 24 3.1. DiagramadeCasosdeUso............................... 33 3.2. Evolución de los Sprints del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3. DiagramadeSecuencia01 ............................... 48 3.4. DiagramadeSecuencia02 ............................... 49 3.5. DiagramadeSecuencia03 ............................... 50 4.1. Árbol Contenido Zip Extraído . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2. Árbol Directorios Solución Extraída . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.3. Creación Pipeline: Añadir Tareas al Agente . . . . . . . . . . . . . . . . . . . . . . 56 4.4. Ejemplo Grupo Variables Credenciales . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5. TaskGroup TG-01: Tareas a ejecutar . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.6. TaskGroup TG-01 : Entrada de Parámetros . . . . . . . . . . . . . . . . . . . . . 60 4.7. TaskGroup TG-02: Tareas a ejecutar . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.1.IconoAzureRepos ................................... 78 A.2. Datos solicitados para creación nuevo repositorio . . . . . . . . . . . . . . . . . . . 78 A.3. Azure Pipelines: Seccion Task Groups . . . . . . . . . . . . . . . . . . . . . . . . 79 A.4.PipelineenBlanco ................................... 80 A.5. Añadir TG-01 Recuperar Cambios en CRM . . . . . . . . . . . . . . . . . . . . . 82 B.1. Añadir TG-01 Recuperar Cambios en CRM . . . . . . . . . . . . . . . . . . . . . 86 xv Índice de figuras F.1. Árbol de Directorios del CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 xvi Marcos Muñoz Núñez Índice de tablas 2.1. Comparacion Dynamics 365 Cloud vs On Premise . . . . . . . . . . . . . . . . . . 8 2.2. Comparación Precios Licencias Dynamics 365 . . . . . . . . . . . . . . . . . . . . 9 2.3. Requisitos Dynamics 365 Customer Engament . . . . . . . . . . . . . . . . . . . . 10 2.4. RequisitosSQLServer ................................. 10 2.5. Presupuesto Servicio Platform as a Service (PaaS) . . . . . . . . . . . . . . . . . . 11 2.6. Comparación Costes Cloud y On Premise . . . . . . . . . . . . . . . . . . . . . . . 12 2.7. Características de los Agentes Hospedados por Microsoft . . . . . . . . . . . . . . 19 3.1. RequisitoFuncional01................................. 26 3.2. RequisitoFuncional02................................. 26 3.3. RequisitoFuncional03................................. 27 3.4. RequisitoFuncional04................................. 27 3.5. RequisitoNoFuncional01............................... 27 3.6. RequisitoNoFuncional02............................... 27 3.7. RequisitoNoFuncional03............................... 28 3.8. RequisitoNoFuncional04............................... 28 3.9. CU-01. Recuperar Cambios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.10. CU-02. Restaurar Cambios a CRM . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.11. CU-03. Desplegar Cambios a otro entorno CRM . . . . . . . . . . . . . . . . . . . 32 3.12.TareasdelSprint1 ................................... 36 3.13.TareasdelSprint2 ................................... 36 3.14.TareasdelSprint3 ................................... 37 3.15.TareasdelSprint4 ................................... 38 3.16.TareasdelSprint5 ................................... 39 3.17.TareasdelSprint6 ................................... 40 3.18.TareasdelSprint7 ................................... 41 3.19.TareasdelSprint8 ................................... 42 3.20.TareasdelSprint9 ................................... 43 3.21.Riesgosdelproyecto .................................. 44 3.22. Tabla de Precios Azure DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.23. Presupuesto Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 xvii Capítulo 1 Introducción 1 Capítulo 1. Introducción Dynamics 365 es un sistema de gestión de relaciones con clientes y planificación de recursos empresariales creado por Microsoft y que funciona sobre la plataforma cloud Azure. Pese a ser un producto comercial es altamente personalizable y ampliable a través de soluciones de código. Esto lo convierte a su vez en una plataforma muy versátil pudiéndose adoptar a múltiples tipos de clientes y a casos de uso muy distintos de los que se suponen para un sistema Customer Relationship Management (CRM). La personalización de Dynamics 365 se orienta cada vez mas a la configuración nativa, dejando la programación poco a poco mas apartada[23]. Esto hace que sea necesario poder llevar un seguimiento de los cambios en las configuraciones y estructuras nativas de Dynamics 365. Sobre esta base se trabajara para implementar DevOps apoyándome en las soluciones en la nube de Azure. En este contexto de investigación, novedad y tecnologías emergentes aparece mi motivación para buscar soluciones que mejoren el día a día de los equipos de desarrollo Dynamics 365 con toda la potencia y comodidad que pueden ofrecer las soluciones en la nube. La idea inicial de este proyecto es conseguir un sistema que permita aplicar técnicas de Integración Continua o Continuous Integration (CI) y Entrega Continua o Continuous Delivery (CD) en los desarrollos sobre Dynamics 365. Este trabajo ha de servir para facilitar un set de herramientas que faciliten el desarrollo, la gestión del proyecto y la realización de pruebas de calidad. Acortando los ciclos de desarrollo, facilitando los despliegues y la mantenibilidad del proyecto y reduciendo los tiempos de entrega del mismo. Este trabajo busca integrarse en los diferentes proyectos que se llevan acabo dentro de la linea Enterprise and Cloud Solutions de Everis. Empresa donde se esta realizando este trabajo y de donde proviene el feedback principal, además de la supervisión de la parte técnica del proyecto. Este trabajo sera guiado y supervisado por los tutores de la empresa: Alberto Casero de la Calle y Álvaro Estebanez Barrena. Y por el tutor académico, el profesor Benjamín Sahelices Fernández, que desde la universidad supervisara la memoria y el desarrollo del trabajo como un proyecto académico. En esta introducción se plantea la motivación y objetivos del proyecto. Tras ello el contexto tecnológico en el que se desarrollara el proyecto y los estudios previos realizados. La documentación técnica de la memoria aporta todo el trabajo realizado incluyendo el Análisis y Diseño e Implementación y Pruebas. Finalmente las Conclusiones del trabajo cierran este acompañadas de aspectos a mejorar y trabajo futuro a realizar sobre el mismo. Esta memoria incluye en su parte final un glosario donde listan todas la abreviaturas, acrónimos y definiciones de uso extendido en la memoria. Este puede consultarse en la página 71. Así como un detalle de las referencias bibliográficas utilizadas. Al final de este documento se incluyen los manuales de instalación y uso así como los anexos que complementan la documentación técnica aportada. Este documento en su versión digital contiene múltiples enlaces que permiten navegarlo, entre las diferentes secciones, referencias bibliográficas y las referencias al glosario, por lo que se recomienda su visualización en formato digital. 2Marcos Muñoz Núñez 1.1. Objetivos del trabajo 1.1. Objetivos del trabajo El objetivo del trabajo es integrar las herramientas DevOps de Azure en un entorno de desarrollo de Dynamics 365. La funcionalidad básica que se quiere alcanzar es proveer de un historial de los cambios en las soluciones y entidades de Dynamics 365, con un mecanismo de rollback que permita deshacer los cambios realizados. Así como proporcionar una trazabilidad del trabajo y tareas acometidas, que se pueda relacionar con los cambios realizados. Esta seria la base sobre la que construir un camino hacia la Integración Continua en los desarrollos Dynamics 365. Para la consecución de este proyecto se deben alcanzar los siguientes objetivos: Comprender el funcionamiento de Dynamics 365 y como se realizan sus desarrollos y personalizaciones. Estudiar las metodologías DevOps. Conocer las diferentes herramientas que proporciona Azure DevOps. Analizar y diseñar un mecanismo que permita almacenar un histórico de los cambios realizados en el CRM Analizar y diseñar un mecanismo que permita devolver los cambios almacenados al CRM Implementar el sistema propuesto con las herramientas de Azure DevOps. Este trabajo se integrara en nuevos desarrollos y ya existentes de Dynamics 365, siendo de gran utilidad para las empresas que se dedican a personalizar y extender este Software. Marcos Muñoz Núñez 3 Capítulo 1. Introducción 4Marcos Muñoz Núñez Capítulo 2 Contexto Tecnológico 5 Capítulo 2. Contexto Tecnológico modelo PaaS que permite olvidar la compra de hardware y las licencias de SQL Server y Windows Server, así como su instalación y administración. Lo cual nos acerca a las ventajas de la versión Cloud, aunque los costes del Hardware pueden variar en función de la carga del sistema. Hardware Software Total en 1 Año Total en 3 años Cloud - 23.280,00 e/año 23.280,00 e69.840,00 e On Premise 6.026,51 e/año 18.360,00e24.386,51 e36.439,53 e Nota: El coste hardware se basa en los costes anuales del servicio PaaS en Azure[10]. Se ha supuesto un grupo de 20 usuarios para los calculos. Tabla 2.6: Comparación Costes Cloud y On Premise 2.3.2. Arquitectura de Dynamics 365 Dynamics se estructura como una aplicación modular con una frontera bien definida entre los clientes y el servidor. Figura 2.2: Arquitectura Dynamics 365 on Premise 12 Marcos Muñoz Núñez 2.3. Microsoft Dynamics El sistema sigue una arquitectura de 4 capas: Capa de presentación: Agrupa los diferentes clientes (Web,Móvil...), así como las herramientas de generación de informes. Las aplicaciones cliente admiten son extensibles y admiten personalización principalmente mediante recursos web (HTML,JavaScript....). Capa de Servicios: Se ejecuta sobre Windows Server y en ella se enmarcan los Servicios Web. La funcionalidad de esta capa puede ser extendida mediante DLLs programadas en .NET. Capa de aplicación: Al igual que la de servicios se ejecuta en el servidor, se encarga de la lógica de negocio, los componentes de la entidades de negocio y los componentes de acceso a los datos. Las capas transversales de procesos y seguridad abarcan toda esta y también forman parte de la capa de datos. Capa de Datos: La plataforma de acceso a datos se encuentra en el servidor y provee el acceso a los datos y metadatos alojados en SQL Server. Esta capa puede ser accedida por las herramientas de creación de reportes. En el entorno cloud la arquitectura es ligeramente diferente ya que no se utiliza una base de datos como tal. La capa de datos queda sustituida por el Common Data Service como se muestra en la imagen 2.3. Los datos de Common Data Service se almacenan en un conjunto de entidades. Una entidad es un conjunto de registros que se usa para almacenar datos, similar a cómo una tabla almacena los datos en una base de datos.[40] El CDS no permite el acceso directo a los datos pero provee de herramientas como PowerBI para poder realizar informes y disponer de los datos en otras aplicaciones del ecosistema Azure. Figura 2.3: Arquitectura Dynamics 365 Cloud Marcos Muñoz Núñez 13 Capítulo 2. Contexto Tecnológico 2.3.3. Arquitectura de Soluciones de Dynamics365 La arquitectura de soluciones de Dynamics 365 define la forma en la que las personalizaciones y configuraciones del sistema se aplican. Dentro de una solución encontramos diferentes componentes que se crean mediante herramientas de personalización o las API incluidas en las aplicaciones Dynamics 365 for Customer Engagement y están totalmente hospedadas en la aplicación. En el diagrama 2.4 se muestran los diferentes tipos de componentes de la solución.[13] Este proyecto buscar realizar un control de cambios y mantener un historial de estos componentes. Figura 2.4: Componentes de las Soluciones Estos incluyen prácticamente todos los cambios y personalizaciones que se realizan al sistema. Existen dos tipos de soluciones de aplicaciones Dynamics 365 for Customer Engagement: administradas y no administradas. Una solución administrada es una solución completada que está diseñada para distribuir e instalar. Una solución no administrada es la que aún está en desarrollo o no está diseñada para distribuirse. Cuando se completa la solución no administrada y se desea distribuir, se puede exportar y empaquetar como una solución administrada.[13]. El diagrama 2.5 muestra cómo las soluciones administradas y no administradas interactúan con la solución del sistema para controlar el comportamiento de la aplicación. En el diagrama 2.5 se muestran diferentes tipos de soluciones[13]: Solución del sistema: La solución del sistema representa los componentes de la solución definidos en aplicaciones Dynamics 365 for Customer Engagement. Sin ningún tipo de solución administrada o personalizaciones, la solución del sistema define el comportamiento predeterminado de aplicación. Muchos de los componentes de la solución del sistema son personalizables y se pueden usar en soluciones administradas y no administradas. Soluciones administradas: Las soluciones administradas se instalan por encima de la solución del sistema y pueden modificar los componentes de la solución personalizables o agregar más componentes de la solución. Las soluciones administradas también se puede superponer sobre otras soluciones administradas. Mientras una solución administrada permite la personalización de sus componentes de la solución, otras soluciones administradas se pueden instalar por encima de la misma y modificar los componentes de la solución personalizables que proporciona. 14 Marcos Muñoz Núñez 2.4. Azure DevOps Figura 2.5: Arquitectura de Soluciones Soluciones no administradas: Las soluciones no administradas son grupos de personalizaciones no administradas. Cualquier componente de la solución no administrada personalizado puede asociarse con cualquier número de soluciones no administradas. Una de las principales diferencias con las administradas es que quitar una no administrada del sistema no revierte los cambios que se hayan realizado en la configuración del sistema. Comportamiento de aplicación: El comportamiento final de una instancia de aplicaciones Dynamics 365 for Customer Engagement para una organización específica es la culminación de la solución del sistema, las soluciones administradas y las no administradas. 2.4. Azure DevOps Azure DevOps es una colección de servicios en al nube de Microsoft para colaborar en el desarrollo de software estos servicios pueden ser accedidos a través de la web o de un cliente para Entorno de desarrollo integrado (IDE). Azure DevOps ofrece repositorios para realizar control del código, servicios de compilación y despliegue como soporte para la integración y entrega continua (CI y CD), herramientas para planificar y realizar seguimiento del trabajo, los problemas en el código y las incidencias, herramientas para realizar pruebas de las aplicaciones, tableros de mandos altamente personalizables, entre otras... Prácticamente la totalidad de la interacción con este servicio se realiza vía web, aunque existen conectores externos que permiten automatizar tareas, o configurar las pipelines a través de archivos Marcos Muñoz Núñez 15 Capítulo 2. Contexto Tecnológico concretos en el repositorio, la interfaz web es el principal medio para interactuar con el servicio como se ve en las imágenes 2.6, 2.7 y 2.10. A continuación se detallaran las herramientas principales que se utilizaran en este proyecto. 2.4.1. Azure Boards Azure Boards es un conjunto de herramientas de planificación centradas en metodologías ágiles. Estas permiten realizar un seguimiento del trabajo con paneles de tarjetas Kanban, listar los trabajos pendientes, mostrar paneles con información del trabajo del equipo y obtener informes personalizados para mantener un seguimiento del trabajo Figura 2.6: Interfaz Azure Boards: Tablero Kanban 2.4.2. Azure Pipelines Una de las herramientas centrales para este proyecto son las pipelines, estas permiten configurar un flujo de tareas que se ejecutaran a petición, ya sea de forma manual, programada, o por algún evento que se programe. Los trabajos que se configuran Azure Pipelines son enviados a los agentes. Los agentes son un programa software instalable que ejecuta una pipeline cada vez, estos pueden ser de dos tipos: Agentes Hospedados por Microsoft en Azure Agentes Auto-hospedados Localmente 16 Marcos Muñoz Núñez 2.4. Azure DevOps Los agentes hospedados son pequeñas maquinas virtuales en la nube de Azure que se crean y configuran al inicio de la pipeline y son destruidas cuando esta acaban. Los agentes de Azure permiten olvidarse de configurar maquinas virtuales, entornos de desarrollo y pruebas etc. Los agentes auto-hospedados pueden ser instalados en hardware propio de forma local y son controlados desde Azure Pipelines al igual que los agentes hospedados en Azure. Esto proporciona mucha versatilidad ya que se puede elegir que Sistema Operativo (Linux, Mac o Windows) y herramientas son provisionadas en estas maquinas obteniendo siempre un entorno limpio. Los agentes instalan las herramientas, realizan las tareas asignadas (compilación, ejecución de scripts de consola, copia de datos...), y tras ello informan del resultado. También permiten automatizar los test realizándose tras cada compilación y permitiendo implementar CI y CD con facilidad ya que permiten la la liberación o despliegue de versiones de forma automática si los test son correctos. Las pipelines de Azure DevOps proporcionan un sistema de variables que se pasan al agente a la hora de crearlo, permitiendo trasladar información entre ejecuciones de la build. Estas son especialmente utiles en los agentes hospedados en Azure. Ya que por ejemplo las variables de entorno no se mantienen entre ejecuciones ya que cada ejecucion es una maquina nueva. Estas variables pueden ser definidas tanto el la interfaz web de Azure Pipelines, como programaticamente a través de los archivos YAML que permiten describir las acciones de un pipeline.[6] En algunos casos las variable pueden contener información sensible que no debe almacenarse en texto plano y estar disponible para cualquiera; para atajar este problema Azure Pipelines utiliza las llamadas variables secretas. Las variables secretas esta encriptadas con una clave RSA de 2048 bits. Las variables secretas se ponen a disposición de los agentes y scripts para su uso, por lo que se debe de ser cuidadoso a la hora de dar acceso a que la pipeline sea editada, ya que estos pueden imprimirse dentro de un script. Las variables secretas no pueden definirse en los archivos YAML (ya que estos son visibles a cualquiera que tenga acceso al repositorio) por lo que solo pueden configurarse desde la interfaz web. Si se desean utilizar variables en varias pipelines diferentes se pueden utilizar los grupos de variables.[5] Aunque en general hablemos de Pipelines para referirnos a los flujos de tareas configurables en Azure DevOps existen dos tipos concretos de pipeline: Build Pipelines, o Pipelines de Compilacion Release Pipelines o Pipelines de Lanzamiento La principal diferencia entre ellas es que las Pipelines de Lanzamiento o Release, son fundamentalmente grupos de pipelines con distintas fases o stages con mecanismos de control entre ellos. Lo que permite automatizar las distintas fases de un despliegue. Por ejemplo, una o varias Build pipelines generan los artefactos a compilar desde el código fuente, tras esto se pasa a una etapa que prepara el entorno en el que se va a desplegar, sobre este se realizan unos test automáticos. Si estos test son correctos se pasa a la siguiente fase y se despliega en un entorno de preproducción donde también se ejecutan pruebas automáticas. La siguiente fase, el despliegue en producción puede tener por ejemplo la necesidad de una aprobación manual, Marcos Muñoz Núñez 17 Capítulo 2. Contexto Tecnológico Figura 2.7: Interfaz Azure Pipelines: Ejecución Pipeline por lo que llegado a este punto se avisara a la persona encargada informándole de los resultados de las pruebas anteriores. Si esta persona aprueba el despliegue se ejecuta la ultima pipeline que realiza el despliegue en producción. Un ejemplo de esto puede verse en la imagen 2.8 Figura 2.8: Interfaz Azure Pipelines: Release Pipeline Para este proyecto vamos a centrarnos en las Build Pipelines, aunque las Release Pipelines son muy interesantes de cara a desarrollar futuros sistemas de CD. Otras de las características de Azure Pipelines son los grupos de tareas y los grupos de despliegue. Los grupos de tareas se detallan mas adelante en este apartado. Los grupos de despliegue [14] permiten configurar conjuntos de maquinas relacionadas como pueden ser los entornos de despliegue de un mismo proyecto (Desarrollo, Calidad, Preproducción, Producción...), para luego poder configurar pipelines de lanzamiento de forma mas sencilla, no se plantea la utilización de grupos de despliegue para este 18 Marcos Muñoz Núñez 2.4. Azure DevOps proyecto. Azure Pipelines sigue un modelo de SaaS, sobre el que Microsoft va implementando mejoras que se liberan a los usuarios de forma periódica. Esto hace que incluso durante el desarrollo de este proyecto hayan aparecido nuevas funciones y cambios en la documentación. [2] Agentes Hospedados en Azure Como se indicaba previamente en el punto 2.4.2, la ejecución de los trabajos en Azure Pipelines puede ser llevada acabo por agentes hospedados por Microsoft, quien los mantiene, actualiza y gestiona. Cada vez que se ejecuta una pipeline se realiza sobre una maquina virtual limpia, los trabajos que se le encargan pueden ejecutarse directamente sobre la maquina virtual o en un contener cargado en ella. En caso de requerir condiciones especiales, por ejemplo que el agente este detrás del firewall o VPN, se puede optar por hospedarlo localmente. Este no es el caso que se tratara en este trabajo ya que buscamos explotar las ventajas de la computación en la nube, pero es una opción a tener en cuenta en entornos de desarrollo que no pueden ser accedidos de forma externa. Microsoft dispone de varias imágenes para cargar las maquinas virtuales, cubriendo varios sistemas operativos y diferentes versiones de los mismos. Cada imagen lleva diferente software instalado, Microsoft proporciona la relación de este así como las versiones concretas de cada software. [3] También permite al usuario la instalación de nuevo software en al maquina virtual utilizando las tareas de instalación de herramientas. Las características y limitaciones de los agentes se indican en la tabla 2.7. vCPU 2 Memoria RAM 7GB Almacenamiento 10GB Tiempo de ejecución 360 minutos (6 horas) Permisos Ejecución como administrador Tabla 2.7: Características de los Agentes Hospedados por Microsoft Para el uso de estos agentes se ha de tener en cuenta no utilizar rutas absolutas ya que los nombres de las unidades y discos así como la estructura concreta de los agentes pueden cambiar sin previo aviso. Agentes Auto-hospedados Ya hemos hablado de los agentes hospedados por Microsoft y sus ventajas, pero también existe la opción de hospedar nuestros propios agentes en maquinas locales. Los agentes auto-hospedados permiten tener el control completo del sistema donde se ejecutan los agentes, así como del software Marcos Muñoz Núñez 19 Capítulo 2. Contexto Tecnológico que estos pueden utilizar en las pipelines. Estos agentes se pueden instalar sobre sistemas operativos Linux, MacOs o Windows. También están disponibles contenedores Docker para facilitar la instalación. Una vez se ha instalado el agente en la maquina se puede instalar cualquier otro software que se necesite para la ejecución de las pipelines. Los agentes instalados en maquinas locales han de comunicarse con Azure Pipelines a través de internet. Ya que este se encarga de gestionar sus trabajos y el estado de estos. Toda la comunicación es iniciada por el agente vía HTTP o HTTPS. Esto permite la configuración de reglas en los firewalls locales que permitan a los agentes comunicarse con Azure Pipelines de forma segura y sin exponer mas puertos al exterior. Esto supone también una ventaja para la creación de Pipelines que han de trabajar con servidores que están tras el cortafuegos de una empresa, o necesitan de una conexión VPN para acceder a ellos como se ilustra en la imagen 2.9. Figura 2.9: Conectividad Agentes Locales La posibilidad de instalar los agentes en maquinas locales, dentro del firewall, o de configurar estas maquinas para conectarse de forma segura a los diferentes servicios necesarios, permite facilitar su despliegue dentro de entornos empresariales seguros en los que ciertos servicios no están expuestos a internet. Otra ventajas de los agentes auto-hospedados localmente son: Los agentes locales siempre están disponibles, por lo que inician antes los trabajos. Los agentes en la nube normalmente requieren entre pocos segundos y varios minutos para ser asignados y este tiempo varia dependiendo de la carga en los sistemas de Microsoft. Los agentes locales no tienen que borrar todo su contenido cada vez que finalizan una pipeline, por lo que son mas rápidos al no tener que configurar y redescargar el repositorio en cada ocasión. Pueden instalarse varios agentes en la misma maquina, facilitando la tarea de paralelizar varias pipelines sin que el coste se dispare. 20 Marcos Muñoz Núñez 2.4. Azure DevOps Los recursos hardware se pueden adecuar en funcion de las necesidades. Triggers Los triggers o disparadores permiten que una Pipeline se ejecute de forma automática en respuesta a un evento.[9] Existen triggers de Compilación y de Despliegue, en función del tipo de pipeline que se quiera ejecutar y dentro de estos encontramos tres grandes tipos: Integración Continua: Los triggers de CI ejecutan una pipeline cada vez que se sube un cambio al repositorio, ya sea a una rama especifica o con una tag concreta. Presentan varias opciones como por ejemplo agrupar varios cambios para reducir el numero de pipelines lanzadas en caso de que se hagan cambios muy frecuentes en el repositorio. Programados: Estos triggers permiten seleccionar los días y horas a los que se desea que se inicie la pipeline. Se pueden configurar diferentes días de la semana y horas para diferentes ramas del repositorio, así como en diferentes zonas horarias para equipo internacionales. Compilación Terminada: En grandes desarrollos pueden aparecer muchas dependencias entre varios componentes. En estos casos los triggers de compilación permiten configurar un pipeline para que se ejecute al finalizar una anterior, lo que permite que la cadena de dependencias se vaya compilando paso a paso. Grupos de tareas Los grupos de tareas o “Task Group” permiten encapsular una serie de tareas que ya estén definidas en una pipeline en una sola tarea reusable que puede añadirse a cualquier pipeline, como cualquier otra tarea. [35] Permite elegir los parámetros que se mostraran al exterior y abstraer el resto de opciones y configuraciones. Al crear un grupo de tareas este pasa a estar disponible en el catalogo de tareas para todas las pipelines del proyecto. Esto ayuda a estandarizar y centralizar ciertas acciones comunes a varias pipelines, además de simplificar su mantenimiento, puesto que cuando se realiza un cambio en un grupo de tareas este cambio se replica en todas las pipelines que tengan esa tarea en su flujo, manteniendo así la misma versión en todas la pipelines. 2.4.3. Azure Repos Azure Repos provee de diferentes SCVs hospedados en Azure, los mas utilizados y que se usaran también en este proyecto son los repositorios GIT, pero también ofrece compatibilidad con TFVC, SVN y otros servicios de repositorios de terceros como GitHub y Bitbucket. Para facilitar la colaboración entre desarrolladores ofrece un sistema de hilos de discusión, la configuración de directivas de rama para controlar las solicitudes de incorporación de cambios y una potente búsqueda de código semántica que reconoce las clases y variables y permite buscar en todo el repositorio con rapidez. Estos tienen una gran integración con el resto de servicios de Azure Marcos Muñoz Núñez 21 Capítulo 3. Análisis y Diseño RNF-03 Las credenciales deben almacenarse de forma segura Descripción Las credenciales (ej login de Dynamics) no han de almacenarse en texto plano o ser accesibles para el usuario. Caso Uso Relacionado CU-01, CU-02 Tabla 3.7: Requisito No Funcional 03 RNF-04 La implementación se realizara sobre la nube de Azure Descripción La solución adoptada en este proyecto deberá ser implementada con las herramientas de Azure DevOps Caso Uso Relacionado CU-01, CU-02 Tabla 3.8: Requisito No Funcional 04 3.2. Casos de Uso Tras la obtención de requisitos y los análisis iniciales se obtienen dos casos de uso muy claros y de un alcance bastante bien definido, que se comentan y refinan con los tutores de Everis, estos son los casos de uso: CU-01 y CU-02. Tras la realizacion de estos dos primeros casos de uso se detecta una utilidad que no se habia planteado inicialmente pero que puede ser util en el dia a dia de los equipos de desarrollo de Dynamics 365, estando alineado con los objetivos planteados al inicio del proyecto, por lo que se añade y analiza el caso CU-03. Además tras haber analizado CU-01 y CU-02, CU-03 parece una evolución natural sobre ellos,ya que se trata de una implementación de los dos previos por lo que se beneficiara del trabajo ya realizado en los anteriores casos de uso. Nombre e ID del CU CU-01. Recuperar Cambios en CRM Versión 1.0 Actor Usuario Descripción El usuario desea que los cambios se guarden en el sistema de control de versiones, creando una imagen de las entidades del sistema en ese momento. Precondiciones PRE-1 El usuario debe tener acceso al sistema PRE-2 El usuario solicita la recuperación de cambios o esta esta programada para su inicio automático. PRE-3 La instancia de Dynamics 365 debe de estar activa y responder a peticiones 28 Marcos Muñoz Núñez 3.2. Casos de Uso Postcondiciones PST-1 Los cambios realizados en el CRM se añaden al Sistema de control de versiones Flujo normal FN1 El usuario solicita manualmente la recuperación de los cambios FN2 El sistema añade la tarea a la cola. FN3 Cuando la tarea entra en ejecución el sistema se conecta al CRM, obtiene los cambios realizados en las soluciones, los extrae y prepara para su introducción en el Sistema de control de versiones FN4 El sistema hace commit de los cambios al Sistema de control de versiones quien añade únicamente las modificaciones realizadas. Si la operación ha sido correcta se notifica al usuario. Flujo alternativo 1 FA1 Si la tarea ha sido programada con antelación (por ejemplo para que se ejecute a una hora predeterminada) no es necesaria la intervención del usuario en la tarea y se procede a añadirla en cola. Flujo alternativo 2 FA2 Si ocurre algún error durante la recuperación de los cambios se notifica al usuario y la tarea se cancela sin escribir nada en el Sistema de control de versiones Prioridad Alta Otra info Se recuperaran los cambios de la solución predeterminada de Dynamics 365. Tabla 3.9: CU-01. Recuperar Cambios Marcos Muñoz Núñez 29 Capítulo 3. Análisis y Diseño Nombre e ID del CU CU-02. Restaurar Cambios a CRM Versión 1.0 Actor Usuario Descripción El usuario desea devolver CRM a un punto concreto, indicado por un commit en el Sistema de control de versiones Precondiciones PRE-1 El usuario debe tener acceso al sistema. PRE-2 El usuario debe indicar la instantánea concreta a la que desea restaurar el CRM. PRE-3 El usuario solicita la restauración de cambios. PRE-4 La instancia de Dynamics 365 debe de estar activa y responder a peticiones Postcondiciones PST-1 El CRM se restaura al punto indicado por el usuario. Flujo normal FN1 El usuario solicita manualmente la restauración de una imagen concreta FN2 El sistema añade la tarea a la cola. FN3 Cuando la tarea entra en ejecución el sistema obtiene la imagen indicada, realiza su empaquetado, actualiza el numero de versión de la solución a subir, y realiza su importación a CRM FN4 Si la operación ha sido correcta se notifica al usuario y se publican los cambios en el CRM. Flujo alternativo 1 FA1 Si ocurre algún error durante la recuperación de los cambios se notifica al usuario y la tarea se cancela sin realizar cambios en el CRM. Flujo alternativo 2 FA2 Prioridad Alta Otra info Se importara la solución predeterminada a CRM . Tabla 3.10: CU-02. Restaurar Cambios a CRM 30 Marcos Muñoz Núñez 3.2. Casos de Uso Nombre e ID del CU CU-03. Desplegar Cambios a Otro Entorno Versión 1.2 Actor Usuario Descripción El usuario desea llevar los cambios de CRM a otro entorno o instancia, dejando registro de los cambios en el Sistema de control de versiones Precondiciones PRE-1 El usuario debe tener acceso al sistema. PRE-2 El usuario debe indicar la solución concreta a la que desea desplegar en el CRM. PRE-3 Las credenciales de los diferentes entornos han de estar preconfiguradas. PRE-4 El usuario solicita el despliegue de una solución en otro entorno. PRE-5 La instancia de Dynamics 365 debe de estar activa y responder a peticiones Postcondiciones PST-1 Los cambios realizados en el CRM se añaden al Sistema de control de versiones y son importados y publicados en otra instancia CRM diferente a la de partida. Marcos Muñoz Núñez 31 Capítulo 3. Análisis y Diseño Flujo normal FN1 El usuario solicita manualmente el despliegue de una solución concreta desde un entorno a otro. FN2 El sistema añade la tarea a la cola. FN3 El usuario solicita manualmente la restauración de una imagen concreta FN4 El sistema añade la tarea a la cola. FN5 Cuando la tarea entra en ejecución el sistema se conecta al CRM de origen, obtiene los cambios realizados en las soluciones, los extrae y prepara para su introducción en el Sistema de control de versiones FN6 El sistema hace commit de los cambios al Sistema de control de versiones quien añade únicamente las modificaciones realizadas. Si la operacion ha sido correcta se notifica al usuario. FN7 El sistema realiza la importación a CRM de los cambios descargados hacia el entorno de destino. FN8 El sistema realiza la publicación de los cambios la instancia CRM de destino. FN9 Si la operación ha sido correcta se publican los cambios en el CRM y se notifica al usuario. Flujo alternativo 1 FA1 Si ocurre algún error durante la recuperación de los cambios se notifica al usuario y la tarea se cancela sin realizar cambios en el CRM. Flujo alternativo 2 FA2 Prioridad Media Otra info Se importara la solución indicada a CRM . Tabla 3.11: CU-03. Desplegar Cambios a otro entorno CRM Estos casos de uso están recogidos en el diagrama de casos de uso 3.1. 32 Marcos Muñoz Núñez 3.3. Planificación Figura 3.1: Diagrama de Casos de Uso 3.3. Planificación Las principales tareas de este proyecto serán: Estudio de las tecnologías, metodologías y herramientas a utilizar. Elección de metodología y programación a gran escala en función de esta. Análisis y estimación de la tareas necesarias para cumplir con los objetivos. Realización de pruebas de concepto Implementación Documentación A grandes rasgos se estima que las tareas de investigación, estudio y familiarización ocuparan las primeras 5 semanas. Una vez se tenga la información básica sobre el contesto del proyecto se elaborara una planificación básica inicial que permita tener una referencia para medir el avance del proyecto y planificar la carga de trabajo de los Sprints en consecuencia. Una vez se tengan datos suficientes para comenzar el análisis este se estima en unas 3 semanas y mientras se ejecuta se continua con el estudio ampliando el conocimiento disponible para dicho análisis, en ciertos puntos el análisis se se intercalara con la realización de algunas pruebas de concepto que demuestren la viabilidad del análisis realizado y aporten mas información a este. Se estima que las pruebas de concepto puedan abarcar unas 3 semanas, aunque se realizaran de forma intermitente, intercaladas con el estudio y análisis necesario para llevarlas a cabo. La implementación del proyecto se Marcos Muñoz Núñez 33 Capítulo 3. Análisis y Diseño estima que abarcara unas 5 semanas. En cuanto a la documentación la idea inicial es que sea constante a lo largo del proyecto intensificándose cuando los trabajos en otras áreas del mismo vayan finalizando, por lo que se prevé que las 2 ultimas semanas del proyecto se dediquen a finalizar esta. En los últimos años las metodologías ágiles, en concreto SCRUM, han conseguido una gran presencia en la informática y el desarrollo de software. El modelo de sprints define una unos bloques de una duración de tiempo predeterminada, generalmente de entre dos o tres semanas. Al inicio de cada Sprint se deciden las tareas a realizar en el, esta es una gran ventaja en proyectos en los que a priori no se conocen con precisión las tareas a realizar. También esta planificación permite la realización de cambios según se va avanzando en el proyecto, por lo que no es necesario fijar el alcance del proyecto a su inicio ya que este puede alargarse o acortarse hasta que este finalizado, reduciendo la carga de la estimación inicial, muy importante en metodologías clásicas como el Proceso Unificado. La metodología de trabajo que se utilizará en el proyecto se basara en metodología SCRUM y se organizara en sprints de una duración de 2 semanas. Se fijan reuniones con el tutor de Everis cada 2 Viernes, coincidiendo con el final de los sprints para poder evaluar el resultado de estos y planificar el próximo. La fecha de inicio del proyecto es el 15 de Febrero de 2019, cuando se celebra la primera reunión con los tutores de Everis, en el momento del inicio la fecha de finalización es desconocida, pero se espera una duración de unos 8 sprints, pudiendo alargarse o acortarse en función del avance del proyecto y las fechas concretas de entrega. A continuación se detalla la evolución de esta planificación a lo largo del los sprints realizados y como se han ido distribuyendo las tareas. Así como gráficos y datos sobre las desviaciones que hayan podido ocurrir en la planificación. El gráfico 3.2 resume la evolución de la carga de los sprints a lo largo del proyecto así como la cantidad de tareas completadas y no completadas en cada uno de ellos. 34 Marcos Muñoz Núñez 3.3. Planificación Figura 3.2: Evolución de los Sprints del proyecto 3.3.1. Sprint 1 La tabla 3.12 muestra las tareas acometidas en el Sprint inicial realizado entre el 15 de febrero y el 1 de marzo de 2019. Marcos Muñoz Núñez 35 Capítulo 3. Análisis y Diseño Sprint 1 - 15 de Febrero de 2019 - 1 de Marzo de 2019 Tarea Tipo Estado Reunión inicial tutores Everis Gestión Completada Elección de Metodología y Planificación inicial Planificación Completada Reunión tutor Uva Gestión Completada Formación Inicial en Dynamics 365 Estudio Completada Formación GIT Estudio Completada Solicitud trial Dynamics 365 Estudio Completada Familiarizarse con C-Sharp Estudio Completada Tabla 3.12: Tareas del Sprint 1 3.3.2. Sprint 2 La tabla 3.13 muestra las tareas acometidas en el Sprint realizado entre el 1 de marzo y el 15 de marzo de 2019. Sprint 2 - 1 de Marzo de 2019 - 15 de Marzo de 2019 Tarea Tipo Estado Estudiar interfaces externas Dynamics Estudio Completada Crear cuenta en Azure DevOps Gestión Completada Familiarizarse con Componentes Azure DevOps Estudio Completada Familiarizarse con las soluciones Dynamics Estudio Completada Exportar/ Importar soluciones manualmente Estudio Completada Conocer contenido de las soluciones Estudio Completada Crear Estructura Memoria Documentación Completada Tabla 3.13: Tareas del Sprint 2 36 Marcos Muñoz Núñez 3.3. Planificación 3.3.3. Sprint 3 La tabla 3.14 muestra las tareas acometidas en el Sprint realizado entre el 15 de marzo y el 29 de marzo de 2019. Sprint 3 - 15 de Marzo de 2019 - 29 de Marzo de 2019 Tarea Tipo Estado Solicitar nueva Trial Gestión Completada Exportar e Importar datos en nueva trial Gestión Completada Diseño pruebas concepto Estudio Completada Familiarizarse con lenguaje scripting PowerShell Estudio Completada Prueba concepto conexión CRM vía PowerShell Implementación Completada Estudiar funcionamiento Azure Pipelines Estudio Completada Crear Pipeline conceptual Implementación Completada Crear repositorios Azure Repos Implementación Completada Familiarizarse con Azure Boards Estudio Completada Primer esbozo Introducción Documentación Completada Primer esbozo Objetivos Documentación Completada Primer esbozo Contexto tecnológico y herramientas utilizadas Documentación Completada Tabla 3.14: Tareas del Sprint 3 Marcos Muñoz Núñez 37 Capítulo 3. Análisis y Diseño Identificador Descripción Probabilidad Impacto R-01 Perdida de datos debido a fallo hardware Baja Alto R-02 Fallo en la conectividad de la web Baja Medio R-03 Problemas Integración de las soluciones con Dynamics 365 Alta Media R-04 Cambios en el funcionamiento de los servicios utilizados Media Media R-05 Tecnología descontinuada o sustituida Baja Alta R-06 Planificación demasiado optimista Medio Medio Tabla 3.21: Riesgos del proyecto de un equipo local. Se podría reanudar el trabajo y recuperar todos los datos desde la nube. Estos servicios suelen tener sus propias políticas de copias de seguridad, pero en el caso de que existieran perdidas de datos en el servicio en la nube, las copias locales en distintos equipos y servicios cloud permitirían su rápida restauración. El riesgo R-02: Fallo en la conectividad de la web, se mitiga disponiendo de varias tecnologías de acceso al a red por parte del desarrollador en este caso se dispone de conexión fija tanto en el hogar como en las dependencias de la universidad y empresa. A mayores se dispone de una linea de datos móviles que puede usarse como backup. El caso de que el problema de red afecte a los servicios en la nube, tiene una probabilidad menor, en este caso la capacidad de realizar trabajo en offline existe aunque se vería impactada la productividad. El riesgo R-05: Tecnología descontinuada o sustituida presenta una baja probabilidad ya que se esta utilizando tecnología novedosa que ha sido puesta en servicio durante los últimos años, con una gran apuesta por las empresas que la desarrollan. Por lo que tras el análisis las probabilidades de verse afectado por su discontinuidad son casi nulas. Sin embargo la modificación de su funcionalidad contemplada en el riesgo R-04 es mucho mas probable, ya que estas tecnologías en la nube suelen ir asociadas a un modelo de “Roling Release” en el que se entregan actualizaciones con cambios y nuevas funcionalidades en cortos periodos de tiempo.[2] Generalmente se concede un acceso para probar las siguientes actualizaciones antes de que aparezcan por lo que el impacto en el proyecto podrá ser mitigado con antelación. El riesgo R-06: Planificación demasiado optimista es un riesgo que puede aparecer al planificar un sprint con demasiada carga de trabajo y que esta no pueda ser acometida. Sin embargo la metodología utilizada permite afrontar estas desviaciones al inicio del siguiente sprint adaptando la planificación a la realidad del proyecto con el mínimo coste posible. El riesgo R-03:Problemas Integración de las soluciones con Dynamics 365 puede aparecer al intentar integrar el desarrollo de este proyecto en instancias de Dynamics 365 que tengan un gran numero de personalizaciones, por lo que este riesgo podría llevar a retrasos importantes. 44 Marcos Muñoz Núñez 3.5. Presupuesto económico Para mitigarlo se realizaran pruebas en distintos tipos de instancias de Dynamics y se probara la integración con una instancia muy similar a un entorno típico de producción. 3.5. Presupuesto económico En cuanto a los costes para el desarrollo de este proyecto, se ha de tener en cuenta que debido al carácter de trabajo de fin de grado del proyecto se utilizaran versiones educativas y de prueba de la mayoría de los software con licencia, así como de los servicios en la nube y las herramientas de desarrollo. Por lo que el concepto de coste no tiene demasiado sentido. Aun así este apartado se incluye solamente con carácter especulativo, y no supone un coste real. Para el presupuesto total del proyecto se han de tener en cuenta los costes de recursos humanos y los costes de Azure DevOps, así como de las herramientas necesarias para su ejecución, ya que el sistema CRM sobre el que se trabajaría generalmente corre a cuenta del cliente final y no de la empresa de desarrollo. 3.5.1. Costes Azure DevOps Azure DevOps proporciona un conjunto de servicios (Boards, Pipelines,Repos,Test y Artifacts) de forma gratuita para proyectos de código abierto y para pequeños equipos de hasta 5 usuarios. Para equipos de mayor tamaño ofrece licencias mensuales en función del numero de miembros del equipo. El coste de las licencias[30] esta recogido en la tabla 3.22. Así mismo se pueden ampliar las características como el numero de trabajos paralelos que se pueden ejecutar de forma simultanea con un coste incremental. Azure DevOps también ofrece una versión en entorno local “On Premise”. Las características básicas de Azure DevOps incluidas en la licencia son: Azure Pipelines: 1 trabajo hospedado con 1.800 minutos al mes para CI/CD y 1 trabajo autohospedado. Azure Boards: seguimiento de elementos de trabajo y paneles kanban. Azure Repos: repositorios GIT privados ilimitados. Azure Artifacts: Administración de paquetes (5 usuarios gratis). Pruebas de carga: 20.000 VUM/mes. Cada trabajo paralelo adicional en Azure pipelines tiene un coste de 12,65e. [30] Para este proyecto se ha utilizado el acceso gratuito para equipos pequeños, cuyas limitaciones son: Equipos de hasta 5 personas, 1 trabajo hospedado con 1.800 minutos al mes para CI/CD y 1 trabajo autohospedado. Es decir solo se puede tener un agente hospedado en Azure simultáneamente. Marcos Muñoz Núñez 45 Capítulo 3. Análisis y Diseño Usuarios Coste Mensual <5 Gratis 10 25,299 e 20 92,763 e 50 295,155 e 100 632,475 e 200 1138,455 e 1000 5.186,30 e Tabla 3.22: Tabla de Precios Azure DevOps 3.5.2. Recursos humanos En el proyecto participaran diferentes roles, el trabajo principal sera el de un Analista con experiencia encargado del análisis, diseño y la dirección de la implementación. Sobre el recaerá un 60 % del trabajo del proyecto. Sera necesario un perfil de desarrollador para realizar pequeñas pruebas de concepto y ayudar con la codificación general su aportación se estima en un 10 %. Como apoyo al analista se utilizará un arquitecto cuya estimación de trabajo sera de un 5 %. También sera necesario una persona de calidad que se encargue del diseño y ejecución de pruebas al cual se asigna un 20 % del tiempo total del proyecto. Finalmente se estima que un 5 % del tiempo del proyecto se dedicara a la Gestión del mismo, por lo que la figura del gestor se tiene en cuenta en los cálculos de personal. Los costes de recursos humanos se toman para el desarrollo del proyecto, sin tener en cuenta el ciclo de vida del CRM. El proyecto se estima en unas 300 horas de trabajo, realizándose el calculo de costes en base a estas. El desglose de horas y estimación de costes esta representado en la tabla 3.23. Horas Coste Hora Total Desarrollador Junior 30 25,00 e750,00 e Analista Senior 180 35,00 e6.300,00 e Arquitecto 15 50,00 e750,00 e Testing 60 20,00 e1200,00 e Gestión 15 45,00 e675,00 e Total 9.675,00 e Tabla 3.23: Presupuesto Recursos Humanos 46 Marcos Muñoz Núñez 3.6. Pruebas de Concepto 3.6. Pruebas de Concepto Para probar la viabilidad del proyecto y de los conocimientos obtenidos se decide realizar una serie de pruebas de concepto que permitan descartar rápidamente vías que no llevaran a la solución buscada. Una de los primeros campos a probar es probar la conexión desde un programa externo y la automatización de ciertas acciones de Dynamics 365. Para ello se definen varias pruebas que tratan aspectos clave para la continuidad del proyecto: Conexión al CRM y Exportar soluciones. Extraer contenido de las soluciones Empaquetar soluciones Importar Soluciones al CRM Trasladar pruebas de concepto a una Pipeline La implementación de estas pruebas de concepto se detallara en el capítulo 4. 3.7. Diagramas de Secuencia La interacción entre los diferentes sistemas se ha modelado utilizando diagramas de secuencia, cada caso de uso se ha modelado en un diagrama. El caso de uso CU-01 se corresponde con el diagrama de secuencia 01 que se muestra en la imagen 3.3. El caso de uso CU-02 se corresponde con el diagrama de secuencia 02 que se muestra en la imagen 3.4. El caso de uso CU-03 se corresponde con el diagrama de secuencia 03 que se muestra en la imagen 3.5. La plataforma web de Azure DevOps sera el principal medio de interacción con el usuario. Esta se encarga de recibir las ordenes de inicio, activar los Agentes y gestionar los comandos que se envían a estos. También provee de un interfaz visual del resultado de la ejecución. Asi mismo al final de la misma se encarga de notificar al usuario mediante diferentes vías. Una vez inicializada la maquina virtual esta se encarga de las diferentes tareas y la comunicación con Dynamics 365 y el repositorio de Azure Repos. Estas funcionalidades se modelaran como si fueran clases atómicas que son "llamadas"por las pipelines. Marcos Muñoz Núñez 47 Capítulo 3. Análisis y Diseño Figura 3.3: Diagrama de Secuencia 01 48 Marcos Muñoz Núñez 3.7. Diagramas de Secuencia Figura 3.4: Diagrama de Secuencia 02 Marcos Muñoz Núñez 49 Capítulo 3. Análisis y Diseño Figura 3.5: Diagrama de Secuencia 03 50 Marcos Muñoz Núñez Capítulo 4 Implementación y Pruebas 51 Capítulo 4. Implementación y Pruebas En este capítulo se trataran los detalles mas relevantes en cuanto a la implementación del sistema. Esta implementación se ha realizado de forma iterativa, empezando con unas sencillas pruebas de concepto ejecutadas en la consola local para poder probar la viabilidad de las soluciones adoptadas y realizando la migración de estas pruebas de concepto a la nube. Una vez demostrada la efectividad de la solución se van incorporando nuevos componentes de Azure Pipelines y profundizando en la implementación como por ejemplo encapsulando la funcionalidad con grupos de tareas o “Task Groups”, añadiendo seguridad sobre las credenciales guardadas haciendo uso de variables secretas, implementando el uso de triggers. 4.1. Primeras pruebas de Concepto Para probar los conceptos estudiados y demostrar su viabilidad se realizaron unas pruebas de concepto iniciales: 4.1.1. Exportar Soluciones desde Dynamics 365 La primera prueba de concepto realizada fue la de utilizar scripts consola probar la conexión con el sistema Dynamics 365. Las soluciones se pueden exportar de forma manual, pero el objetivo es encontrar una forma de automatizar este proceso. Para la realización de esta prueba se investigo sobre las diferentes formas de conectarse y realizar operaciones en crm de forma automatizada. Para comenzar se elige el uso de un script de consola Powershell por su facilidad para ser trasladado e integrarse con las distintas herramientas de Azure. En esta investigación se encuentra un conjunto de herramientas que permiten realizar distintas acciones en Dynamics 365 a través de la consola. [37] Para realizar esta prueba se preparo el script que se puede encontrar en el Anexo C, en el que se comprueba si las herramientas de consola de Dynamics 365 [37] están instaladas y si no es así se procede a su instalación. Tras lo cual se configura la conexión a CRM con los datos proporcionados, y trata de recuperar la solución indicada. En las primeras ejecuciones de esta prueba de concepto la consola devolvía un error de timeout el cual fue solucionado configurándolo con: Set-CrmConnectionTimeout -conn $CrmConn -TimeoutInSeconds 1000 Se ha de tener en cuenta que este parámetro modifica el timeout de la conexión, pero no los que pueda tener configurados internamente Dynamics 365. Las pruebas posteriores arrojaban resultados dispares en cuanto a los tiempos de fallo, finalmente se descubrió que se debía a como funcionan las instancias de trial, ya que utilizan los recursos que están libres en cada momento, no siendo consistentes en el tiempo que tardan en realizar las mismas acciones en diferentes momentos del día. Para asegurar que estos problemas se debían a las trials, y no a la configuración del CRM o los scripts se realizaron las mismas pruebas sobre instancias Dynamics365 de Everis. En las instancias comerciales se conseguía un rendimiento estable en el tiempo y los resultados eran 52 Marcos Muñoz Núñez 4.1. Primeras pruebas de Concepto mucho mas coherentes. Aun así puede ocurrir que con soluciones de gran tamaño se necesario aumentar el tiempo que la conexión permanece esperando la respuesta del CRM. Tras esta primer prueba de concepto, el siguiente paso era estudiar el contenido de las soluciones exportados y ver como identificar los cambios en estas. 4.1.2. Extraer contenido de la solución Como ya hemos visto es posible extraer soluciones de Dynamics 365 de forma automatizada, este nos proporciona un archivo zip que contiene varios archivos y carpetas. Como se muestra en la imagen 4.1, este contiene varias carpetas con los recursos web, ensamblados dll, y workflows. En la raíz encontramos tres grandes archivos XML, que contienen la información sobre las personalizaciones realizadas, el contenido de esta solución, y los tipos de ficheros que la componen. Las nuevas entidades, así como las modificaciones sobre las existentes se desgranan dentro de el fichero customizations.xml, siendo un XML muy denso y de difícil lectura o modificación. Figura 4.1: Árbol Contenido Zip Extraído Esto dificulta el seguimiento de los cambios sobre las diferentes entidades y configuraciones del sistema. Microsoft en su documentación proporciona una herramienta llamada SolutionPackager, que identifica cada componente individual y lo extrae a archivos individuales, esto permite añadir los archivos resultantes a un SCV de forma que se puede tener un control del los cambios realizados sobre cada componente individual. Esta es una herramienta que se ejecuta desde consola de comandos y actúa contra el fichero Zip indicado como entrada. Los diferentes comandos y opciones están detallados en la documentación que proporciona Microsoft[36]. Tras aplicar la herramienta SolutionPackager sobre el archivo Zip exportado, obtenemos el directorio de directorios que se muestra en la imagen 4.2. Donde se puede ver que los cambios en las entidades se agrupan en la carpeta Entities, dentro de la cual hay un carpeta por cada entidad. Así mismo dentro de estas carpetas vemos las de cada tipo de cambio, Marcos Muñoz Núñez 53 Capítulo 4. Implementación y Pruebas Figura 4.6: TaskGroup TG-01 : Entrada de Parámetros 4.4.2. Implementación Pipeline CU-01 Una vez publicado el “Task Group” este puede ser importado desde una Pipeline. En esta deberemos configurar el repositorio desde el que se leerán y escribirán los datos, el agente o agentes que realizaran las tareas y añadir el “Task Group”, al añadirlo se mostrara la configuración relativa a sus parámetros de entrada, como se muestra en la imagen 4.6 En la pipeline configuramos la variable de mensajeCommit y Solucion para que el usuario pueda modificarlas al lanzar la pipeline. Vinculamos el grupo de variables que contiene las credenciales del CRM y se asignaran a los parámetros de entrada del “Task Group”. También se programan los triggers para que se ejecute automáticamente. Con esto esta pipeline esta lista para ser ejecutada. A la hora de ser ejecutada el usuario podrá indicar el mensaje de commit y la solución de la que se recuperaran los cambios. A diferencia de los “Task Group” las pipelines aun no se pueden exportar como una única entidad, por lo que deben configurarse a mano. El equipo de desarrollo de Azure Pipelines ha confirmado estar trabajando en que se pueda realizar la exportación de Pipelines junto a los “Task Group” que los conforman en un futuro próximo, lo cual simplificaría la posterior instalación por parte de los usuarios finales. 4.5. Implementación CU-02: Restaurar Cambios a CRM El caso de uso 02 describe como se han de recoger las cambios del repositorio GIT e insertarlos en de vuelta al CRM.Al igual que en el caso de uso anterior se hará uso de las Pipelines y los 60 Marcos Muñoz Núñez 4.5. Implementación CU-02: Restaurar Cambios a CRM “Task Group” o grupos de tareas que una vez mas encapsularan la funcionalidad principal del caso de uso. Es decir, se creara un grupo de tareas o “Task Group” al que nos referiremos como TG-02 y este sera ejecutado desde una Pipeline. 4.5.1. Implementación del grupo de tareas TG-02 El “Task Group” TG-02 implementara la funcionalidad principal del caso de usoCU-02: Restaurar Cambios a CRM. En este “Task Group” se realizan las siguientes tareas: Instalar las Herramientas Aumentar el numero de versión de la solución a empaquetar Empaquetar la Solución Importar solucion al CRM Al igual que en los casos anteriores la instalación de las herramientas en el agente se ha de realizar cada vez que se ejecuta la pipeline ya que los Agentes Hosteados ofrecen una maquina virtual limpia en cada ejecución. Se aumenta el numero de versión del CRM para poder identificar con que ejecución de la Pipeline se corresponde la versión que esta subida al CRM para ello se utiliza la estructura 1.0.0.X donde la X se sustituirá por el numero de Build, este se obtiene de una de las variables de sistema que ofrece Azure Pipelines $(Build.BuildNumber).Como se explico anteriormente este numero es auto-incremental y aumenta cada vez que se ejecuta una Pipeline. En el GIT se almacenan los datos de la solución descomprimidos y estructurados en carpetas, para volver a subir estos datos al CRM se ha de recomponer el fichero zip de la solución. Una vez se obtiene el fichero ZIP, este es Importado de vuelta al CRM, una vez este se ha subido correctamente finaliza el grupo de tareas. La imagen 4.7 muestra las tareas que ejecutara este “Task Group” Figura 4.7: TaskGroup TG-02: Tareas a ejecutar Los parámetros de entrada del TG-02 serán los datos de la conexión al CRM (Usuario,Password,Url...) y el nombre de la solución que se desea subir al CRM. Al ser los mismos que en el TG-01 en la imagen 4.6 pueden consultarse los parámetros de entrada que se han expuesto. Estos son: Marcos Muñoz Núñez 61 Capítulo 4. Implementación y Pruebas Solución a Importar Datos de Conexión De estas variables solo la solución a importar puede ser modificada por el usuario a la hora de ejecutar la pipeline. Como se comento anteriormente los “Task Group” pueden exportarse de forma que sean importados en otros proyectos de Azure DevOps,la exportación genera un codigo JSON que se utilizará para instalar el “Task Group” en otros proyectos. El codigo JSON perteneciente al “Task Group” 01 puede consultarse en el anexo E. 4.5.2. Implementación Pipeline CU-02 En este caso de uso la Pipeline se encargara de recuperar los datos del repositorio GIT y ejecutar el grupo de tareas TG-02. Lo primero es indicar el repositorio del cual se obtendrán los datos, así la pipeline recuperara los cambios una vez inicializado el agente. El “Task Group” TG-02 sera añadido a continuación, al igual que en el caso anterior se configuraran sus parámetros de entrada utilizando el grupo de variables que contiene los datos de conexión del CRM. En este caso no se configuraran triggers de ningún tipo ya que esta se ejecutara únicamente de forma manual. Al igual que en el caso anterior las Pipelines aun no se pueden exportar a un archivo. El equipo de desarrollo de Azure Pipelines ha confirmado estar trabajando en esta se pueda realizar en un futuro próximo, lo cual simplificaría la instalación por parte de los usuarios finales. 4.6. Implementación CU-03: Desplegar Cambios a Otro Entorno Este tercer caso de uso nace como un ejemplo practico de la combinación de los casos de uso anteriores. Parte de la idea de facilitar el trabajo de despliegue y mantener un historial fácil de consultar de las soluciones desplegadas. Para la implementación de este caso de uso no sera necesario la creación de nuevos grupos de tareas, ya que se hará uso de los TG-01 y TG-02 implementados en los dos casos de uso anteriores. En este caso de uso participaran dos instancias de Dynamics CRM distintas,a una la llamaremos instancia de Origen y la otra sera la instancia de Destino. 4.6.1. Implementación Pipeline CU-03 Para este caso de uso se implementara una pipeline en la que se configurara el repositorio GIT en el cual se desea que se recupere la información de los cambios realizados en el entorno de Origen. Tras esto se añade el “Task Group” TG-01 y se configuran sus parámetros de entrada. Para este utilizaremos el grupo de variables que contiene los datos de conexión del servidor de Origen. Tras esto se añade el “Task Group” TG-02, se vincula otro grupo de variables que contenga los datos 62 Marcos Muñoz Núñez 4.6. Implementación CU-03: Desplegar Cambios a Otro Entorno del entorno de Destino y se configuran estas en los parámetros de entrada del TG-02. En este caso las variables que se configuran en la pipeline son: Mensaje de Commit Solución a Desplegar Datos de Conexión Cuando se realiza el commit en el repositorio GIT con los archivos a desplegar, este va acompañado de un mensaje descriptivo, formado por la etiqueta [AUTO], el numero de Build en el que se ha realizado el commit, el nombre de la solución desplegada, la etiqueta [DEPLOY] y un mensaje opcional que el usuario puede Añadir. El numero de build es un numero auto-incremental que se toma de las variables del sistema que ofrece Azure Pipelines y se utiliza como $(Build.BuildNumber). En este caso el usuario puede configurar el mensaje del commit y el nombre de la solución a desplegar a la hora de ejecutar la pipeline. De nuevo recalcar que a diferencia de los “Task Group” las pipelines aun no pueden ser exportadas a archivos externos por lo que deben configurarse a mano desde la interfaz web. El equipo de desarrollo de Azure Pipelines ha confirmado estar trabajando en que se pueda realizar la exportación de Pipelines junto a los “Task Group” en un futuro próximo, lo cual simplificaría la posterior instalación por parte de los usuarios finales. Marcos Muñoz Núñez 63 Capítulo 4. Implementación y Pruebas 64 Marcos Muñoz Núñez Capítulo 5 Conclusiones 65 Capítulo 5. Conclusiones A lo largo de los últimos años las técnicas de Integración Continua, Despliegue Continuo y un seguimiento mas cercano de los desarrollos combinado con las metodologías ágiles han propiciado la expansión del termino que de alguna forma aúna todas estas, DevOps. Todo esto busca un objetivo común: mejorar la calidad del software y reducir el tiempo de desarrollo reduciendo las complicaciones derivadas del mismo. Con este trabajo se ha podido ver que estas practicas pueden aplicarse a a todo tipo de desarrollos, incluidos aquellos en los que el código no es el eje central del mismo. Las ventajas son claras: ciclos de desarrollo mas cortos, detección temprana de errores, seguimiento preciso del código y vinculación entre este, las tareas y los errores. Su principal desventaja es que necesitan de conocimientos adicionales para poder utilizar estas herramientas, así como tiempo para interiorizar las metodologías y flujos asociados. Pero queda patente que el tiempo que se emplea en la formación del equipo y la integración de estas herramientas aporta muchas ventajas temporales, económicas e incluso personales y que además pueden aplicarse a cualquier tipo de proyecto. Con su popularización también han surgido nuevas herramientas y mejorado las existentes. En este punto la adicción de los servicios cloud a la ecuación facilita su uso y aplicación de nuevas y diferentes formas. Facilitando el acceso y la integración de estas con servicios como Azure DevOps, que proporciona un set de herramientas muy completo, fácil de integrar con casi todo tipo de desarrollo y que proporciona una interfaz web que permite su configuración de forma intuitiva y fácil de usar. Además las ventajas de poder usar agentes en la nube hacen que se puedan probar estos sistemas sin realizar una inversión en hardware o tiempo en configurar servidores. Los programas CRM son muy demandados por las empresas y Dynamics 365 es uno de los mas populares, capaz de adaptarse múltiples escenarios gracias a sus capacidades de personalización, sus desarrollos pueden implicar a grandes equipos, con los problemas de comunicación y coordinación que esto puede conllevar. Implementar DevOps en estos desarrollos no es una tarea trivial, ni frecuente si lo comparamos con otros tipos de desarrollos software, pero puede suponer un gran ahorro en resolución de conflictos, seguimiento de los cambios, facilidades en el despliegue a entornos productivos, automatización de pruebas, compilación e integración automática de los diferentes activos de código que permitan detectar problemas de forma temprana . En este proyecto se han puesto las bases para un sistema de integración continua en Dynamics 365 con el que comenzar aplicando las metodologías DevOps y como trataremos mas adelante puede seguir creciendo y mejorando añadiendo mas características que faciliten y aceleren los desarrollos sobre Dynamics365. En la realización del proyecto se han completado los siguientes objetivos: Aprendí el funcionamiento de Dynamics 365 y las múltiples formas de personalizarlo y extenderlo. Adquirí mayor conocimiento de como se estructuran muchos de los servicios en la nube así como varias aplicaciones de estos. He obtenido un gran conocimiento las metodologías DevOps y los conceptos de Integración y Entrega Continua y como implementar estas en diferentes contextos. 66 Marcos Muñoz Núñez 5.1. Trabajo Futuro Adquirí competencias con los servicios de Azure DevOps aplicables a muchas otras herramientas de CI y CD. Aplique los conocimientos adquiridos para analizar y diseñar un sistema que permitiera la recuperación y almacenamiento de las personalizaciones realizadas en el CRM, así como su restauración. He realizado la implementación de este sistema sobre Azure DevOps aplicando las competencias adquiridas durante el proyecto. Personalmente durante este proyecto he ampliado mi conocimiento de las arquitecturas, servicios y aplicaciones Cloud, profundizando en el valor añadido que estas pueden aportar en múltiples campos, y sobretodo en las facilidades que ofrecen a los desarrolladores. La oportunidad de realizar el trabajo en una empresa como Everis me ha permitido ver como los conocimientos adquiridos durante los estudios de grado encajan y aportan un enfoque diferenciador en el mundo laboral. Ya que la solida base de conocimiento y el enfoque adquirido en estos años me ha permito enfrentarme a problemas y tecnologías que no había abordado con anterioridad. Además he descubierto en las DevOps una forma de aunar mi pasión por la resolución de problemas y la administración e integración de sistemas con la posibilidad de mejorar los desarrollos de software, proporcionar herramientas a los equipos que involucren a los desarrolladores y la búsqueda constante de mejora en la calidad y productividad. 5.1. Trabajo Futuro Desde el principio del proyecto este se enfoca a proporcionar una base sobre la que seguir trabajando y mejorando, durante el proyecto se han detectado puntos de mejora y evoluciones concretas con las que ampliar el proyecto. Una de las primeras a acometer es seguir ampliando el concepto de integración continua, utilizando las Pipelines para Compilar los ensamblados DLL cuyo código se almacena en un repositorio diferente al de las configuraciones CRM, y utilizar estos ensamblados contraídos a partir de la ultima versión de código disponible en el repositorio para construir junto a las configuraciones de CRM una solución que integre todas las piezas que acaban formando la personalización del CRM. Otra de las mejoras propuestas es la profundización en el uso de Agentes Locales que permitan trabajar en contextos empresariales donde la conexión al CRM se realiza a través de una VPN, o que permitan realizar despliegues detrás de los firewall. La combinación de estos agentes locales con los Hospedados en la nube es otra de las ramas a trabajar para poder conseguir compilaciones rápidas y frecuentes combinadas con una integración y despliegue sencillo dentro de los servidores locales. Implementación de Pipelines de despliegue implicando en ella a los equipos de testing, y los encargados de aprobar los despliegues de forma que los procesos de integración, pruebas, y aprobación sean mas rápidos y con un mayor automatismo. Marcos Muñoz Núñez 67 Capítulo 5. Conclusiones Este trabajo solo araña la superficie de lo que se puede lograr aplicando DevOps en Dynamics365 y deja abiertas muchas lineas en las que profundizar e investigar como: integración con los sistemas de comunicación y notificaciones del equipo, integración con los equipos de testing, añadir incidencias a los sistemas de gestión cuando un test falla o una compilación no se ejecuta correctamente, realizar un seguimiento mas detallado del tiempo empleado para un trabajo así como estadísticas de los ratios de errores, bugs y fallos presentes en el sistema. 68 Marcos Muñoz Núñez Glosario API Un Interfaz de programación de aplicaciones (Application Programming Interface) es un conjunto de características y reglas que existen dentro de un programa software o aplicación, que habilitan la interacción con el a través de software. Las APIs pueden ser vistas como un simple contrato entre la aplicación que lo ofrece y otros, por ejemplo otro software o hardware. 8, 14, 71 Azure Microsoft Azure es un conjunto de servicios en la nube, ofrecido como servicio y alojado en los Data Centers de Microsoft. Azure ofrece desde servicios que alojan aplicaciones en alguno de los centros de procesamiento de datos de Microsoft para que se ejecute sobre su infraestructura hasta servicios del internet de las cosas, comunicación segura o machine learning. 2, 3, 6, 8, 11, 13, 17, 21, 45 C]Es un lenguaje de programación orientado a objetos, elegante, con seguridad de tipos y orientado a objetos, que permite a los desarrolladores crear una gran variedad de aplicaciones seguras y sólidas que se ejecutan en .NET Framework [18]. 7, 23 CD La entrega continua es una práctica de desarrollo de software mediante la cual se preparan automáticamente los cambios en el código y se entregan a la fase de producción. Fundamental para el desarrollo de aplicaciones modernas, la entrega continua amplia la integración continua al implementar todos los cambios en el código en un entorno de pruebas o de producción después de la fase de compilación. Cuando la entrega continua se implementa de manera adecuada, los desarrolladores dispondrán siempre de un artefacto listo para su implementación que se ha sometido a un proceso de pruebas estandarizado[41]. 2, 6, 15, 17, 18, 67 CI La integración continua es una practica de desarrollo software que consiste en hacer integraciones y pruebas automáticas de un proyecto lo mas frecuentemente posible y así poder detectar fallos cuanto antes. Entendemos por integración la compilación y ejecución de pruebas de todo un proyecto[16]. 2, 3, 6, 15, 17, 21, 67 CRM Customer Relationship Management. Es un sistema software que se utiliza para la gestión de contactos, la gestión de ventas, la productividad y en general la gestión de las relaciones con los clientes de una empresa[38]. 2, 6, 7, 29, 31, 61, 66 69 Bibliografía 76 Marcos Muñoz Núñez Apéndice A Manual de Instalación El siguiente manual describe los procedimientos necesarios para la instalación del sistema de Control de cambios en soluciones, restauración de las mismas y la herramienta de despliegue asociada. Este manual es una guía practica para la configuración del proyecto, creación de repositorios, importación de los “Task Group” y la configuración de las diferentes Pipelines dentro de un proyecto de Azure DevOps. Las pautas e indicaciones de este manual están referidas a la versión de Azure DevOps liberada el 10 de Junio de 2019, también conocida como Sprint 153, sucesivas actualizaciones podrían hacer que algunos de estos procedimientos difiera. Para mas información recomendamos consultar la Documentación de Azure DevOps donde vienen indicados los cambios realizados en cada actualización. « https://docs.microsoft.com/es-es/azure/devops/release-notes » A.1. Requisitos Previos Para la creación de un proyecto en Azure DevOps es necesario una cuenta de Microsoft o GitHub, en este manual no se indican los pasos para la creación de la misma. Para el inicio de sesión en Azure DevOps, la creación de la cuenta o obtener mas información visite: « https://azure.microsoft.com/es-es/services/devops/ ». Para la configuración de la conexión al entorno Dynamics CRM es necesario disponer de datos de acceso con los permisos necesarios para realizar la exportación e importación de soluciones. Este manual no trata la instalación o aprovisionamiento de Dynamics CRM ni su configuración de usuario, para mas información puede dirigirse a la documentación sobre Dynamics CRM de Microsoft o contactar con su proveedor del servicio. Una vez se dispone de la cuenta en Azure DevOps, y los datos de conexión al CRM se puede continuar con la antelación y configuración. 77 Apéndice A. Manual de Instalación A.2. Configuración Azure DevOps y Repositorios Si es la primera vez que utiliza una cuenta de Azure DevOps se le solicitara que cree un nuevo proyecto, de no ser así podrá elegir entre crear un nuevo proyecto o utilizar uno existente. A.3. Repositorios Azure Repos Si desea alojar los cambios que se descargan del CRM en los repositorios que ofrece Azure DevOps, y no dispone de ninguno creado anteriormente seleccione en el menú lateral la opción Repos con el icono indicado en la imagen A.1. Y un asistente le guiara en su creación, basta indicar el nombre del repositorio e indicar que se desea un repositorio de tipo GIT. Esta ultima indicación es importante ya que las “Task Group” que se instalaran a continuación están desarrolladas para funcionar con repositorios GIT, pese a ser posible que trabajen con repositorios TFVC seria necesaria una adaptación del código. Figura A.1: Icono Azure Repos Figura A.2: Datos solicitados para creación nuevo repositorio La importación de los “Task Groups” puede realizarse sin necesidad de un repositorio pero son necesarios para el funcionamiento y creación de las Pipelines. 78 Marcos Muñoz Núñez A.4. Importar “Task Groups” A.4. Importar “Task Groups” Para realizar la importación de los “Task Groups” ha de disponer del los archivos JSON de estas: TG01.JSON Este archivo contiene el “Task Group” relativo a la funcionalidad que permite obtener los cambios de las soluciones en el CRM y registrarlos en el repositorio TG01.JSON Este archivo contiene el “Task Group” relativo a la funcionalidad que permite recuperar los cambios insertados en el repositorio y devolverlos al CRM Para su importación haga clic en la sección Pipelines en el menú lateral, tras lo cual seleccione Task groups. Una vez en la pantalla de Task Groups haga clic en el botón Import. Aparecerá una ventana sobre la cual podrá arrastrar o buscar en el equipo los archivos JSON a importar. Tras seleccionarlos aparecerá la lista de tareas a ejecutar y su configuración por si fuera necesario realizar algún cambio en el código. No se recomienda que se modifiquen estas secciones sin tener un claro conocimiento de lo que esta modificando. Para finalizar pulse sobre el botón Save, para guardar el Task Group importado. Realice de nuevo la misma operación con el resto de archivos JSON. Figura A.3: Azure Pipelines: Seccion Task Groups Marcos Muñoz Núñez 79 Apéndice A. Manual de Instalación A.5. Configuración Pipelines Para configurar las Pipelines seleccione Pipelines en el menú lateral, allí haga clic en Builds. A continuación se mostrara la lista de las Pipelines ejecutadas recientemente. Haga clic en New. A.5.1. Pipeline para Recuperar Cambios del CRM Un asistente le guiara por la configuración de la pipeline, en esta primera etapa ha de seleccionar el repositorio en el que se insertaran o recuperaran los cambios. Seleccione el repositorio que desea usar en esta pipeline, este sera en el cual se inserten los cambios recogidos del CRM. Tras seleccionar el repositorio se mostraran diferentes plantillas para diferentes tipos de proyecto, se ha de seleccionar Empty job para crear una pipeline vacía sobre la que añadir el Task Group previamente importado. Figura A.4: Pipeline en Blanco En la primera pantalla se puede definir el nombre de la Pipeline y el tipo de agente a utilizar, en este caso se seleccionara Hosted. Tras esto se hará clic en el símbolo +que Aparece junto Agent Job 1 esto permitirá añadir una nueva tarea. Al hacer clic se muestra una lista de tareas junto un cuadro de búsqueda. En este se introducirá TG-01 y se presionara el botón Add para añadir el Task Group a la pipline. Una vez añadido a la Pipeline pasamos a configurar la variables de conexión al CRM, estos datos pueden insertarse directamente sobre los campos de el Task Group, pero lo recomendable es que se usen grupos de variables. Para ello se hará clic en la pestaña variables, donde se podrán definir las variables que utiliza la pipeline así como vincular o crear nuevos grupos de variables. Para esta pipeline crearemos 2 variables, una para contener el nombre de la solución a exportar, 80 Marcos Muñoz Núñez A.5. Configuración Pipelines que puede ser siempre la misma o definirse en el lanzamiento de la pipeline. Y otra para el mensaje del commit, en esta también podremos predefinir un mensaje pero se recomienda marcar la casilla Settable at queue time para que pueda ser modificada en el momento de ejecutar la pipeline. Las variables para los datos de conexión del CRM también se pueden definir aquí, pero si estos se van a reutilizar en varias Pipelines es mas conveniente crear un Variable Group. Al hacer clic en Variable Group se muestra la opción Manage variable groups, al seleccionarla se nos permitirá crear un nuevo grupo de variables. Se recomienda definir en este las variables de la conexión que necesita el Task Group, que son: AuthType Url Username Password Para la variable Password que almacenara la contraseña se debe activar el candado que aparece junto a ella, para que sea almacenada y tratada de forma segura y no visible para los usuarios. Al volver a la Pipeline se deberá introducir estas variables recién creadas en los parámetros del Task Group, para ello se utilizara la sintaxis $(Nombre) , donde se sustituirá Nombre por el nombre de la variable en cuestión, como por ejemplo $(Url). Una vez indicados todos los parámetros de conexión del CRM se hará clic en el botón Save que permite guardar los cambios realizados en la pipeline. Si se desea programar la ejecución automática de la Pipeline deberá acceder a la pestaña Triggers donde podrá añadir diferentes horas y días de ejecución. En este punto la pipeline ya esta lista para su uso por parte de los usuarios que solo deberán añadirla a la cola de trabajos. A.5.2. Pipeline para restaurar los Cambios al CRM Esta Pipelines se configurara siguiendo los mismos pasos que la pipeline anterior. Solo que se debera buscar y añadir el Task group: TG-02 Restaurar Cambios a CRM. Al igual que en la pipeline anterior se definirán los parámetros de conexión al CRM, y la variable que permite indicar el nombre de la solución a volcar al CRM. En este caso no hay un mensaje de commit ya que no se realizan inserciones en el repositorio. A.5.3. Pipeline para restaurar los Cambios al CRM Al igual que en los casos anteriores se deberá crear una pipeline vacía en la que se deberá añadir tanto el TG-01 como el TG-02, en ese orden. A la hora de configurar los parámetros ha de tenerse en cuenta que el TG-01 y el TG-02 utilizaran datos de conexión diferentes ya que uno recogerá la solución a desplegar de un entorno CRM y el siguiente la desplegara en un entorno diferente. Teniendo en cuenta esta diferencia en los parámetros a introducir la configuración se realiza de forma idéntica a las anteriores. Marcos Muñoz Núñez 81 Apéndice A. Manual de Instalación Figura A.5: Añadir TG-01 Recuperar Cambios en CRM A.6. Acceso y permisos Tras configurar las Pipelines ya pueden ser lanzadas por los usuarios, o siguiendo su programación horaria. Tras esto puede añadir los usuarios que desee al proyecto usando el botón Invite que aparece en la parte superior de la pagina del proyecto en Azure DevOps. Tras añadir usuarios se recomienda que revise los permisos que se concede a cada uno, limitando el acceso de edición a las Pipelines. La configuración de usuarios y permisos no es un tema que trate en este manual por lo que se insta a la consulta de la documentación de Azure DevOps referente a la administración de usuarios. « https://docs.microsoft.com/es-es/azure/devops/user-guide/project-admin-tutorial » 82 Marcos Muñoz Núñez Apéndice B Manual de Usuario Este manual pretender ser una introducción básica al uso de Pipelines, en este documento no se trata la creación o modificación de estas, por lo que debe verse como una guía rápida para el uso de Pipelines que han sido previamente configuradas pro el administrador del proyecto. B.1. Requisitos Previos Para el uso del sistema de Control de cambios en soluciones, restauración de las mismas y la herramientas de despliegue asociadas este debe haber sido configurado con anterioridad por un administrador. Además el usuario debe tener acceso al proyecto. En caso de no ser asi contacte con el administrador del mismo. B.2. Recuperar cambios de CRM Para recuperar los cambios del CRM e insertarlos en el repositorio primero se deberá acceder al proyecto de Azure DevOps indicado a través de la URL del mismo, o iniciando sesión en https://dev.azure.com/ y seleccionándolo de la lista de proyectos disponibles. Una vez se tiene acceso al proyecto se han de seguir los siguientes pasos: 1. Seleccionar Pipelines del menú lateral izquierdo 2. Se mostraran las Pipelines a las que se tiene acceso 3. Seleccionar la Pipeline que se desea ejecutar, en este caso “Recuperar Cambios en CRM” 4. Seleccionar el botón “Queue” 5. Se mostrara la pantalla de encolado de la Pipeline donde se indicara el mensaje que se desea en el commit y la solución que se extraerá del CRM. En caso de no indicarse tomaran los valores por defecto que se muestran en sus cuadros de texto. 83 Apéndice B. Manual de Usuario 6. Al pulsar sobre el botón Queue la Pipeline se encolara y se ejecutara cuando se le pueda asignar un agente. La Pipeline aparece en el listado de la derecha donde se puede ver su estado. 7. Haciendo clic sobre el listado de la derecha se pueden ver los detalles de la ejecución así como la salida por consola del Agente. 8. Tras ejecutarse la pipeline enviara un mensaje al usuario. En caso de cancelarse o finalizar de forma errónea el usuario sera notificado. B.3. Restaurar Cambios a CRM Para restaurar los cambios del GIT al CRM se han de seguir los siguientes pasos: 1. Seleccionar Pipelines del menú lateral izquierdo 2. Se mostraran las Pipelines a las que se tiene acceso 3. Seleccionar la Pipeline que se desea ejecutar, en este caso “Restaurar Cambios a CRM” 4. Seleccionar el botón “Queue” 5. Se mostrara la pantalla de encolado de la Pipeline donde se indicara la solución que se desea importar al CRM. En caso de no indicarse tomaran los valores por defecto que se muestran en sus cuadros de texto. 6. También puede indicarse el commit concreto que se desea importar al CRM, para ello se ha de indicar el Commit ID en el campo commit, de no indicarse ninguno se utilizara el ultimo realizado. El commit id puede ser obtenido desde el repositorio al visualizar un commit concreto. 7. Al pulsar sobre el botón Queue la Pipeline se encolara y se ejecutara cuando se le pueda asignar un agente. La Pipeline aparece en el listado de la derecha donde se puede ver su estado. 8. Haciendo clic sobre el listado de la derecha se pueden ver los detalles de la ejecución así como la salida por consola del Agente. 9. Tras ejecutarse la pipeline enviara un mensaje al usuario. En caso de cancelarse o finalizar de forma errónea el usuario sera notificado. 84 Marcos Muñoz Núñez B.4. Desplegar Cambios a Otro Entorno B.4. Desplegar Cambios a Otro Entorno En este caso la pipeline se ejecuta prácticamente igual que la de “Recuperar Cambios en CRM”, hay que tener en cuenta que los entornos han sido definidos por el administrador en la configuración de la pipeline y estos no se pueden variar. Siempre va de un entorno de Origen a uno de Destino, si desea modificarlo contacte con el administrador del proyecto. Para Desplegar Cambios a Otro Entorno se han de seguir los siguientes pasos: 1. Seleccionar Pipelines del menú lateral izquierdo 2. Se mostraran las Pipelines a las que se tiene acceso 3. Seleccionar la Pipeline que se desea ejecutar, en este caso “Desplegar Cambios a Otro Entorno” 4. Seleccionar el botón “Queue” 5. Se mostrara la pantalla de encolado de la Pipeline donde se indicara el mensaje que se desea en el commit y la solución que se desplegara al CRM. En caso de no indicarse tomaran los valores por defecto que se muestran en sus cuadros de texto. 6. Al pulsar sobre el botón Queue la Pipeline se encolara y se ejecutara cuando se le pueda asignar un agente. La Pipeline aparece en el listado de la derecha donde se puede ver su estado. 7. Haciendo clic sobre el listado de la derecha se pueden ver los detalles de la ejecución así como la salida por consola del Agente. 8. Tras ejecutarse la pipeline enviara un mensaje al usuario. En caso de cancelarse o finalizar de forma errónea el usuario sera notificado. Marcos Muñoz Núñez 85 Apéndice D. Código: JSON Task Group TG-01 105 "inputs":{ 106 "crmSdkVersion":"9.0.0", 107 "unpackedFilesFolder":"$(Solucion)", 108 "mappingFile":"", 109 "packageType":"Unmanaged", 110 "solutionFile":"$(build.binariesdirectory)\\$(Solucion).zip", 111 "treatUnpackWarningsAsErrors":"false" 112 }, 113 "task":{ 114 "id":"48834e5a-a932-49af-a7fd-a805b5e1cfb5", 115 "versionSpec":"10.*", 116 "definitionType":"task" 117 } 118 }, 119 { 120 "environment":{}, 121 "displayName":"Git Commit, Git Push", 122 "alwaysRun":false, 123 "continueOnError":false, 124 "condition":"succeeded()", 125 "enabled":true, 126 "timeoutInMinutes":0, 127 "inputs":{ 128 "targetType":"inline", 129 "filePath":"", 130 "arguments":"", 131 "script":"\ngit add *\ngit commit -a -m\"[AUTO] Build $(Build.BuildNumber) ($(Solucion)) $(CoomitMsg)\"\ngit status\ngit push origin", ,→ ,→ 132 "errorActionPreference":"stop", 133 "failOnStderr":"false", 134 "ignoreLASTEXITCODE":"false", 135 "pwsh":"false", 136 "workingDirectory":"" 137 }, 138 "task":{ 139 "id":"e213ff0f-5d5c-4791-802d-52ea3e7be1f1", 140 "versionSpec":"2.*", 141 "definitionType":"task" 142 } 92 Marcos Muñoz Núñez 143 } 144 ], 145 "runsOn":[ 146 "Agent", 147 "DeploymentGroup" 148 ], 149 "revision":6, 150 "createdBy":{ 151 "displayName":"Marcos Muñoz Nuñez", 152 "id":"f15db556-4bfd-646c-8dcf-486e3329bdd1", 153 "uniqueName":"[email protected]" 154 }, 155 "createdOn":"2019-06-11T20:08:30.010Z", 156 "modifiedBy":{ 157 "displayName":"Marcos Muñoz Nuñez", 158 "id":"f15db556-4bfd-646c-8dcf-486e3329bdd1", 159 "uniqueName":"[email protected]" 160 }, 161 "modifiedOn":"2019-06-13T23:47:26.333Z", 162 "comment":"Push!", 163 "id":"fe094f81-1e3d-4eac-bfdf-d75a9eca6ff1", 164 "name":"GetSoluciones - Carpetas", 165 "version":{ 166 "major":1, 167 "minor":0, 168 "patch":0, 169 "isTest":false 170 }, 171 "iconUrl":"https://cdn.vsassets.io/v/M152_20190610.2/_content/icon-meta-task.png",,→ 172 "friendlyName":"GetSoluciones - Carpetas", 173 "description":"", 174 "category":"Build", 175 "definitionType":"metaTask", 176 "author":"Marcos Muñoz Nuñez", 177 "demands":[], 178 "groups":[], 179 "inputs":[ 180 { 181 "aliases":[], Marcos Muñoz Núñez 93 Apéndice D. Código: JSON Task Group TG-01 182 "options":{}, 183 "properties":{}, 184 "name":"Authtype", 185 "label":"Authtype", 186 "defaultValue":"", 187 "required":true, 188 "type":"string", 189 "helpMarkDown":"", 190 "groupName":"" 191 }, 192 { 193 "aliases":[], 194 "options":{}, 195 "properties":{}, 196 "name":"CoomitMsg", 197 "label":"CoomitMsg", 198 "defaultValue":"TG-GSC", 199 "required":true, 200 "type":"string", 201 "helpMarkDown":"Commit a introducir en el Repositorio (para anotaciones manuales)",,→ 202 "groupName":"" 203 }, 204 { 205 "aliases":[], 206 "options":{}, 207 "properties":{}, 208 "name":"Password", 209 "label":"Password", 210 "defaultValue":"", 211 "required":true, 212 "type":"string", 213 "helpMarkDown":"", 214 "groupName":"" 215 }, 216 { 217 "aliases":[], 218 "options":{}, 219 "properties":{}, 220 "name":"Solucion", 94 Marcos Muñoz Núñez 221 "label":"Solucion", 222 "defaultValue":"Default", 223 "required":true, 224 "type":"string", 225 "helpMarkDown":"Solucion a Extraer", 226 "groupName":"" 227 }, 228 { 229 "aliases":[], 230 "options":{}, 231 "properties":{}, 232 "name":"Url", 233 "label":"Url", 234 "defaultValue":"", 235 "required":true, 236 "type":"string", 237 "helpMarkDown":"", 238 "groupName":"" 239 }, 240 { 241 "aliases":[], 242 "options":{}, 243 "properties":{}, 244 "name":"Username", 245 "label":"Username", 246 "defaultValue":"", 247 "required":true, 248 "type":"string", 249 "helpMarkDown":"", 250 "groupName":"" 251 } 252 ], 253 "satisfies":[], 254 "sourceDefinitions":[], 255 "dataSourceBindings":[], 256 "instanceNameFormat":"Task group: GetSoluciones - Carpetas $(Authtype)", 257 "preJobExecution":{}, 258 "execution":{}, 259 "postJobExecution":{} 260 } Marcos Muñoz Núñez 95 Apéndice D. Código: JSON Task Group TG-01 96 Marcos Muñoz Núñez Apéndice E Código: JSON Task Group TG-02 1{ 2"tasks":[ 3{ 4"environment":{}, 5"displayName":"Instalar Herramientas CRM", 6"alwaysRun":false, 7"continueOnError":false, 8"condition":"succeeded()", 9"enabled":true, 10 "timeoutInMinutes":0, 11 "inputs":{}, 12 "task":{ 13 "id":"04ad1c72-5e49-4686-8a3a-dda6948b0fcd", 14 "versionSpec":"9.*", 15 "definitionType":"task" 16 } 17 }, 18 { 19 "environment":{}, 20 "displayName":"Configurar Numero Versión ", 21 "alwaysRun":false, 22 "continueOnError":false, 23 "condition":"succeeded()", 24 "enabled":true, 25 "timeoutInMinutes":0, 26 "inputs":{ 27 "target":"xml", 28 "crmConnectionString":"", 97 Apéndice E. Código: JSON Task Group TG-02 29 "solutionName":"", 30 "unpackedFilesFolder":"$(Solucion)", 31 "versionNumber":"1.0.0.$(Build.BuildNumber)" 32 }, 33 "task":{ 34 "id":"1cacdeec-c8dd-4091-a522-5a8fbf49c851", 35 "versionSpec":"10.*", 36 "definitionType":"task" 37 } 38 }, 39 { 40 "environment":{}, 41 "displayName":"Empaquetar Solucion $(Solucion) ", 42 "alwaysRun":false, 43 "continueOnError":false, 44 "condition":"succeeded()", 45 "enabled":true, 46 "timeoutInMinutes":0, 47 "inputs":{ 48 "crmSdkVersion":"9.0.0", 49 "unpackedFilesFolder":"$(Solucion)", 50 "mappingFile":"", 51 "packageType":"Unmanaged", 52 "updateVersion":"false", 53 "includeVersionInSolutionFile":"false", 54 "outputPath":"$(build.binariesdirectory)", 55 "treatPackWarningsAsErrors":"false" 56 }, 57 "task":{ 58 "id":"ebec2a90-ce1f-11e6-ae21-c1fb031659ee", 59 "versionSpec":"10.*", 60 "definitionType":"task" 61 } 62 }, 63 { 64 "environment":{}, 65 "displayName":"Importar Solucion $(Solucion) al CRM", 66 "alwaysRun":false, 67 "continueOnError":false, 68 "condition":"succeeded()", 98 Marcos Muñoz Núñez 69 "enabled":true, 70 "timeoutInMinutes":0, 71 "inputs":{ 72 "crmConnectionString":"AuthType=$(AuthType);Username=$(Username); Password=$(Password);Url=$(Url)",,→ 73 "solutionFile":"$(build.binariesdirectory)/$(Solucion).zip", 74 "publishWorkflows":"true", 75 "overwriteUnmanagedCustomizations":"false", 76 "skipProductUpdateDependencies":"false", 77 "convertToManaged":"false", 78 "holdingSolution":"false", 79 "override":"true", 80 "useAsyncMode":"true", 81 "asyncWaitTimeout":"900", 82 "logsDirectory":"", 83 "logFileName":"", 84 "crmConnectionTimeout":"120" 85 }, 86 "task":{ 87 "id":"4455576d-d40a-4234-ad75-3d7ff40ec76e", 88 "versionSpec":"11.*", 89 "definitionType":"task" 90 } 91 } 92 ], 93 "runsOn":[ 94 "Agent", 95 "DeploymentGroup" 96 ], 97 "revision":2, 98 "createdBy":{ 99 "displayName":"Marcos Muñoz Nuñez", 100 "id":"f15db556-4bfd-646c-8dcf-486e3329bdd1", 101 "uniqueName":"[email protected]" 102 }, 103 "createdOn":"2019-06-16T23:16:41.423Z", 104 "modifiedBy":{ 105 "displayName":"Marcos Muñoz Nuñez", 106 "id":"f15db556-4bfd-646c-8dcf-486e3329bdd1", 107 "uniqueName":"[email protected]" Marcos Muñoz Núñez 99 Apéndice E. Código: JSON Task Group TG-02 108 }, 109 "modifiedOn":"2019-06-16T23:42:25.480Z", 110 "comment":"Init Save", 111 "id":"68b1580a-8187-4041-8db2-a5c6f01ca117", 112 "name":"TG-02: Restaurar Cambios a CRM", 113 "version":{ 114 "major":1, 115 "minor":0, 116 "patch":0, 117 "isTest":false 118 }, 119 "iconUrl":"https://cdn.vsassets.io/v/M153_20190612.59/_content/icon-meta-task.png",,→ 120 "friendlyName":"TG-02: Restaurar Cambios a CRM", 121 "description":"Este Task Group encapsula las diferentes tareas necesarias para Impotar una solucion desde el control de versiones al sistema Dynamics CRM", ,→ ,→ 122 "category":"Build", 123 "definitionType":"metaTask", 124 "author":"Marcos Muñoz Nuñez", 125 "demands":[], 126 "groups":[], 127 "inputs":[ 128 { 129 "aliases":[], 130 "options":{}, 131 "properties":{}, 132 "name":"AuthType", 133 "label":"AuthType", 134 "defaultValue":"", 135 "required":true, 136 "type":"string", 137 "helpMarkDown":"Tipo de Autenticacion: Office365,AD,...", 138 "groupName":"" 139 }, 140 { 141 "aliases":[], 142 "options":{}, 143 "properties":{}, 144 "name":"Password", 100 Marcos Muñoz Núñez 145 "label":"Password", 146 "defaultValue":"", 147 "required":true, 148 "type":"string", 149 "helpMarkDown":"", 150 "groupName":"" 151 }, 152 { 153 "aliases":[], 154 "options":{}, 155 "properties":{}, 156 "name":"Solucion", 157 "label":"Solucion", 158 "defaultValue":"Predeterminada", 159 "required":true, 160 "type":"string", 161 "helpMarkDown":"Nombre de la solucion que se importara desde el control de versiones",,→ 162 "groupName":"" 163 }, 164 { 165 "aliases":[], 166 "options":{}, 167 "properties":{}, 168 "name":"Url", 169 "label":"Url", 170 "defaultValue":"", 171 "required":true, 172 "type":"string", 173 "helpMarkDown":"URL del CRM", 174 "groupName":"" 175 }, 176 { 177 "aliases":[], 178 "options":{}, 179 "properties":{}, 180 "name":"Username", 181 "label":"Username", 182 "defaultValue":"", 183 "required":true, Marcos Muñoz Núñez 101