En este artículo vamos a hablar sobre la planificación de nuestro ALM en una solución de Dynamics CRM. Cuando hablamos de un desarrollo de este tipo, es normal hablar de muchos entornos: Desarrollo, Pre-Producción, Integración, Producción…
El ciclo de vida de este tipo de soluciones, incluye:
- Planificación
- Desarrollo y Testeo
- Despliegue
- Monitorización y aprendizaje
El objetivo del ciclo de vida es intentar llevar a cabo una entrega continua de nuestras soluciones entre los diferentes entornos de una forma desatendida y segura, además de garantizar queesta solución llegue a producción (tras pasar por los diferentes entornos), sin ser modificada por el camino.
Ciclo de Vida de una solución de Dynamics
Para que todo esto cobre sentido, es necesario tener una solución de Dynamics 365 en nuestro Visual Studio, conectada con GIT en VSTS. De esta forma tendremos un control de versiones de todo lo que vayamos modificando en la solución.
El desarrollador tendrá su solución de Dynamics CRM en Visual Studio con el fin de integrar todos nuestros desarrollos en la solución del resto de desarrolladores mediante un pull request:
Para que este pull request se realice con éxito, deberá pasar una compilación en Visual Studio mediante una integración continua:
La finalidad de la integración continua es desplegar la solución en un entorno de desarrollo. Para que esta integración continua concluya con éxito, deberemos completar correctamente las siguientes tareas de compilación:
- Restauración de los Nuggets de la solución
- Compilación de la solución
- Ejecución de los tests
- Análisis del código
- Compresión de JS mediante Gulp
- Ping a nuestra instancia de Dynamics
- Copia de seguridad de nuestra instancia de Dynamics
- Empaquetado de nuestra solución de Dynamics que se encuentra en nuestro proyecto
- Importación de esta solución en nuestra instancia
- Publicación de las personalizaciones
Si alguna de estas tareas falla, se cancela el pull request, informando al autor para que la revise y solucione el error.
Una vez finalizado con éxito, el resto de los desarrolladores podrá descargarse esta solución en su Visual Studio de manera que tendrá todos los cambios realizados por el resto del equipo en su propia solución.
Todos los pasos de compilación que interactúan con Dynamics 365 se hacen mediante xrm-ci-framework.
Básicamente es un conjunto de herramientas OpenSource que nos ayudan en el proceso de automatización de nuestra integración continua, con tareas relacionadas con la compilación y el despliegue de una solución de Dynamics 365 (en la segunda parte de este artículo hablaremos más en detalle de este Framework y de cómo implementarlo en las diferentes fases de nuestra Integración continua).
Tras completar con éxito todas las tareas que conforman la integración continua, se realizará la entrega al cliente:
Para esta entrega se lanzará una release de esta solución del entorno de desarrollo. Esta release cambiará el numero de la versión de la solución de CRM y realizará un despliegue automatizado dentro del entorno de integración.
En este momento es cuando el equipo de Q&A entrará en acción para garantizar el correcto funcionamiento de la solución y a aprobar el pase a Pre-Producción.
Una vez nuestra solución esté en el entono de Pre-Producción, habrá otro Release Management con un flujo de aprobación donde los Key Users de la solución tendrán que entrar a validar nuestro desarrollo y a aprobar el pase a producción y formación.
Cuando se produzca un bug se realizará el mismo procedimiento que cuando es un nuevo desarrollo (con la diferencia que la solución que tendremos que coger, es la última versión de la rama de Producción).
Esta rama contiene la versión de la solución que se está ejecutando en nuestro Dynamics de Producción y por tanto es la que contiene este bug, el proceso de Bug Fixing es el siguiente.
El entorno de Fixing será una copia exacta del entorno de producción. En este entorno es donde se realizarán los Fix de los distintos bugs que nos encontremos.
Después, mediante una integración continua, se volcarán estos cambios en la rama de desarrollo para que vuelva a pasar por los distintos entornos (de desarrollo, integración, Pre etc), garantizando así la calidad de este Fix y solucionado el mismo error en los nuevos desarrollos.
Y finalmente este sería el escenario de un ciclo de vida de una solución CRM entre los diferentes entornos:
Antes de definir nuestro ALM es necesario tener claro con qué entornos vamos a trabajar.
Nosotros apostamos porque cada desarrollador tenga su propio entorno de CRM, de esta manera solo estará probando su parte del desarrollo (pues no tiene por qué tener la solución completa instalada en su entorno).
Y hasta aquí la primera parte de un ciclo de vida de nuestra solución de Dynamics 365. Esperamos que os resulte de utilidad y que esperéis con ganas la 2ª entrega 😉
¡Suscríbete a nuestras RRSS!
