Estrategia CI/CD con Azure DevOps y Power Platform para-Fusion Teams

¡Primera publicación de 2023 (estando en febrero. . .)!

Ha sido un mes de enero muy movido y ha sido complicado poder postear. Mucho trabajo, eventos, proyectos y demás. Pero ya vuelvo al redil con muchas novedades y con muchísimo contenido para este 2023. En este primer post del año me gustaría hablar de como implantar una estrategia básica de CI (continuous integration)/CD (continuous deployment) en el ámbito de proyectos de Power Platform.

Esta estrategia es modificable y adaptable a cada proyecto, pero supone unas reglas mínimas básicas para cualquier proyecto en el que Power Platform sea la plataforma de desarrollo. Dada la introducción, nos metemos en materia.

¿Por qué deberíamos implantar una estrategia de CI/CD en nuestros proyectos?

La implementación de una estrategia de CI/CD (Integración y Entrega Continua/Despliegue Continuo) en proyectos de Power Platform puede tener varios beneficios, incluyendo:

1. Mejora de la calidad del software: La automatización de pruebas y el proceso de validación continua ayudan a detectar y corregir errores y problemas de manera eficiente.
2. Aceleración del tiempo de entrega: La integración y el despliegue continuo permite liberar nuevas funciones y mejoras con mayor frecuencia y rapidez.
3. Mayor eficiencia y eficacia: La automatización de procesos reduce la necesidad de intervención manual, lo que a su vez disminuye los errores humanos y mejora la consistencia.
4. Mayor visibilidad y control: La implementación de una estrategia de CI/CD proporciona una visibilidad completa en todas las etapas del proceso de desarrollo y despliegue, lo que permite un mayor control y toma de decisiones.

En resumen, la implementación de una estrategia de CI/CD puede mejorar la calidad, agilidad y eficiencia del proceso de desarrollo y despliegue en proyectos de Power Platform.

CI/CD para Power Platform (visión global)

En base a la experiencia en proyectos con perfiles pro code y low code (Fusion Teams) he diseñado el que considero el proceso básico de CI/CD en un proyecto de Power Platform. La estrategia de CI/CD incluye los siguientes bloques:

• Integración Continua: Integrar el código en un repositorio central de manera continua.
• Despliegue Automatizado: Automatizar el proceso de despliegue a diferentes entornos incluyendo pruebas, desarrollo y producción.
• Monitorización y Reportes: Monitorizar el estado de la integración y el despliegue continuo.
• Control de Versiones: Controlar y gestionar versiones del código y los artefactos de desarrollo de manera eficiente.
• Seguridad y Acceso Controlado: Implementar medidas de seguridad y acceso controlado para proteger los datos sensibles y garantizar la confidencialidad de los mismos.
• Documentación: Documentar el proceso de CI/CD para mejorar la comprensión y el mantenimiento del mismo.

Estos son solo algunos ejemplos de las acciones que pueden formar parte de una estrategia de CI/CD para Power Platform. La implementación exacta dependerá de las necesidades específicas de cada proyecto.

CI (integración contínua) para low code developers

Después de mucha reflexión creo que para explotar las capacidades del low code se debe abstraer al Maker de la integración continua. Hay otras aproximaciones que hacen que el Maker o el citizen developer deban ser los encargados de garantizar su parte en la subida del código. Mi visión es que el low code debe significar velocidad y agilidad, siguiendo la estrategia de integración continúa marcada anteriormente, pero ayudado por los pipelines de Azure DevOps. El diagrama de integración continua para los low code developers sería el siguiente:

Dado que el desarrollador trabajará dentro de soluciones, de manera recurrente (1 vez al día, cuando termina la jornada laboral) una canalización de Azure DevOps (Pipeline en inglés) se encargará de integrar el código en el repositorio central. De esta manera nos aseguramos de que todo el trabajo de los desarrolladores low code quede en el repositorio. Deberemos conectar Azure DevOps con la organización de Power Platform para que las soluciones se puedan importar y exportar desde y hacia Azure DevOps.

Si alguna de las subidas representa una entrega parcial o total o un MVP (mínimo producto viable) deberemos categorizar la subida para tener detectado la versión del código que acabamos de subir.

CI (integración continua) para pro code developers

Para los desarrolladores profesionales, seguiremos una estrategia más tradicional para la integración continua de código. A diferencia de los low code developers, los desarrolladores profesionales deberán realizar confirmaciones manuales en el repositorio GIT de Azure DevOps cada vez que hayan terminado una característica o un desarrollo en concreto. De manera esquemática el desarrollador profesional deberá trabajar de la siguiente manera:

La estrategia de ramas en Git será la siguiente:

1. Rama Master: La rama principal y estable, donde solo se incorporan cambios validados y aprobados después de haber sido probados en otras ramas.
2. Rama Develop: La rama principal de desarrollo, donde los desarrolladores realizan sus cambios y pruebas. Desde esta rama, se pueden crear ramas para nuevas características o correcciones.
3. Rama Hotfix: La rama para correcciones críticas de producción. Esta rama se crea a partir de la rama master y se une nuevamente a ella una vez que se han corregido los problemas.
4. Rama Release: La rama para la liberación de una versión específica del software. Se crea a partir de la rama develop y se une a la rama master y a la rama develop una vez que se ha lanzado la versión.

Esta estrategia de ramas permite mantener una rama estable y segura en la rama master, mientras que los desarrollos y cambios se realizan en la rama develop. Además, permite la creación de ramas para correcciones críticas y para la liberación de nuevas versiones de manera ordenada y controlada.

CD (despliegue contínuo) para Fusion teams

Siguiendo los dos apartados anteriores hemos conseguido que el código (sea procedente de un low o un pro code de manera indistinta) resida en el repositorio de GIT de Azure DevOps. Esto lo que nos va a permitir es que el despliegue continuo se pueda realizar de manera unificada a través de los pipelines de build y de release de Azure DevOps.

Los pipelines de compilación (build) y de liberación (release) en Azure DevOps son herramientas que se utilizan para automatizar el ciclo de vida de desarrollo de software. En un proyecto de Power Platform, estas canalizaciones pueden ayudar a mejorar la eficiencia y la calidad del desarrollo.

El pipeline de build es un proceso que se ejecuta cada vez que se realiza una confirmación en el repositorio de Git. Esta canalización compila y ensambla el código y genera artefactos, como paquetes o imágenes de contenedor, que serán utilizados en el proceso de release.

El pipeline de release es un proceso que se ejecuta para implementar los cambios en ambientes de producción o de prueba. Esta canalización puede incluir la automatización de tareas como la implementación en servidores, la ejecución de pruebas adicionales y la confirmación de la implementación antes de hacerla pública.

Apuntes importantes

Esta estrategia está basada en la experiencia y se trata de una recopilación de los conocimientos y la práctica personal en los años que llevo trabajando con Power Platform. Creo que puede ser muy útil para aquellos que buscan soluciones a problemas similares. Sin embargo, es importante tener en cuenta que cada proyecto y cada equipo son únicos y puede haber múltiples formas de abordar este problema. Por lo tanto, esta estrategia basada en la experiencia no representa una verdad absoluta y debe ser evaluada y ajustada de acuerdo a las necesidades específicas de cada proyecto. En otras palabras, se puede tomar como una guía o punto de partida, pero es importante considerar otros factores y adaptarla según sea necesario.