Hace tiempo que la comunidad busca por todos lados alternativas para que los proyectos de Power Bi tengan un buen control de versiones de sus cambios históricos y sea posible una estrategia de despliegue que soporte ambientes. La realidad es que la comunidad fue muy creativa y logró buenas alternativas con lo que había en su momento.

Sin embargo, hoy es el mejor tiempo para realizar estas prácticas. El lanzamiento de guardar Power Bi como proyecto y las posibilidades que nacieron con Fabric nos dieron las mejores puertas.

En este artículo, mostraremos como configurar una Github Action para despliegues automáticos de Power Bi sin necesidad de capacidad Fabric.

Nos alegra muchísimo poder escribir este artículo compartiendo una nueva herramienta de LaDataWeb que ya pueden encontrar en nuestro sitio: https://www.ladataweb.com.ar/tools.html

Comencemos alineando conceptos, tal como nos gusta hacer en La Data Web.

¿Qué es un Repositorio?

Un repositorio de código pueden pensarlo como un sistema de almacenamiento de archivos, similar a una carpeta que ven en su sistema operativo, con la principal diferencia que rastrea y gestiona todos los cambios, archivos e historial de desarrollo. Permite a los programadores guardar versiones, revertir cambios, colaborar simultáneamente y mantener un registro seguro. Esto significa que si cambiamos una medida y lo mandamos al repositorio, generamos una nueva version del archivo con la nueva medida y si queremos alguna vez ver como era el modelo sin esa medida, podemos ver la version antigua.

¿Qué es CICD?

Significa integración y despliegue continuo. Es una metodología (hoy catalogada en la disciplina DevOps) que automatiza las etapas de desarrollo, pruebas y despliegue de software, permitiendo entregas más rápidas y fiables. CI integra cambios (combinar cambios de equipo) y CD automatiza su envío a producción (un área de trabajo), eliminando procesos manuales y reduciendo errores humanos.

¿Para qué hacemos esto?

Podríamos decir que para trabajar en equipo sobre un mismo modelo (podemos mergear código), delimitar etapas de pruebas para validación de requerimientos, que se publiquen solo los reportes, etc.

Inicio

Para poder desarrollar esto podemos y pudimos en el tiempo aplicar distintas prácticas. Con lo que hoy tenemos hay dos conceptos que son innegables:

• Desarrollos de reportes o modelos semánticos guardados como Proyecto. Power Bi Desktop tiene ahora "Guardar como Proyecto" que permite guardar el código y no un archivo binario. Esto permite guardar archivos de código que pueden ser combinables si muchos modifican al mismo tiempo. A su vez no guardan los datos, entonces son muy livianos para trabajar.
• Separación de ambientes (Prod, Test, Dev) en áreas de trabajo. Las áreas son nuestros entornos de implementación y las branches de los repositorios tienen los entornos a deployar en cada área.

No podemos ignorar lo que las grandes nos invitan a realizar. Hoy Microsoft provee un enfoque orientado a Fabric. Bajo una licencia por capacidad somos capaces de realizar integraciones con repositorios git (Articulos Github o Azure DevOps) para el control de versiones. Luego nos invita a usar Deployment Pipelines para cambiar entre etapas. Esta es una buena alternativa para ítems de Fabric pero para SOLO PowerBi, me resulta incomoda por lo siguiente:

• Require una capacidad de Fabric
• Estamos obligados a usar Github o Azure DevOps
• La dirección de Commits no es unidireccional, si se puede editar de atrás para adelante, corre riesgo la solución:
  Desktop → Branch Feature → Branch Prod ↔ Workpace
• Los deployment pipelines requiren su cuidado y mantenimiento

Solución sugerida - Framework SimplePBI-Ops

Mi idea es remover esas barreras cuando trabajamos solo con Power Bi. El Framework SimplePBI-Ops permite:

• Construir soluciones robustas compatibles con TMSL y TMDL
• Trabajar en equipo sobre un mismo proyecto
• No necesita capacidad, solo power bi pro
• De fondo es un proyecto abierto con Python, podrían usarse tecnologías como gitlab, bitbucket, jenkings, etc.
• La dirección del commit es uni direccional:
  Desktop → Branch Feature → Branch Prod → Workpace
• Reduce las licencias pro para desarrolladores

La solución que voy a mostrar esta orientada a Github, pero si son curiosos todo esto apunta a un proyecto libre para llevarlo a otra plataforma.

Paso 0 - setear permisos para usar la API

Si no sabes de que hablo, podes ver éste artículo:

https://blog.ladataweb.com.ar/seteo-powerbi-rest-api-por-primera-vez/

Los permisos delegados requeridos son:

• Item ReadWrite
• Datasets ReadWrite
• Reports ReadWrite
• Workspaces Read

Paso 1 - Orden en PowerBi Service

Delimitar tus áreas de trabajo con un Sufijo que describa el entorno. Si nuestra área de trabajo es "Ventas". Creamos tres áreas, "Ventas_Dev", "Ventas_Test" y "Ventas_Prod". Para prod podríamos no tener el sufijo de forma que sea más amigable a los usuarios. Ejemplo "DeployedApps":

El sufijo puede ser el que quieran, si es " dev" recuerden que es espacio+dev.

Paso 2 - Orden en el repositorio

Ordenar tu repositorio bajo un esquema de carpetas alineado a tus Workspaces sin el sufijo:

La idea es tener una carpeta contenedora "Workspaces" con los nombres de área y lo que vamos a alinear con lo que hay en el servicio. Como indica la imagen la estructura es:

- Workspaces
— DeployedApps
——Roger Federer.Report
——Roger Federer.SemanticModel
—— ….
— Ventas
——AnalisisVentas.Report
——AnalisisVentas.SemanticModel
—— ….

Si mantenemos esta estructura, el framework de SimplePBI-Ops se encargaría de capturar cambios que ocurran dentro de workspaces en carpetas que terminen en "Report" o "SemanticModel" y luego deploarlos en una área de trabajo que lleve el nombre que pusimos, ej: Ventas, en el ambiente correcto (delimitado con el sufijo)

Paso 3 - Crear github action

Para configurarlo crearemos un archivo.yml para cada entorno que coincida con una branch del repositorio, es decir, archivos dev.yml, test.yml y main.yml (en caso que usen la rama por defecto para prod). Cuando creamos un archivo .yml en la siguiente ubicación, estamos creando la acción.

"root/.github/workflows/archivo.yml"

No hace falta que seamos expertos en este código, sino basta en entender las pocas líneas que pegaremos. El archivo tendrá un código bastante simple.

Comienza con "ON" delimitando la branch para detectar los cambios (puede ser dev, test, prod, main, master, etc) y la carpeta que contiene las áreas que arriba la delimitamos como "Workspaces".

Sigue con "JOBS" ejecutando un paso contra una ejecución sin servidor de linux llamando al proecto de LaDataWeb llamado SimplePBI-Ops con variables de entorno.

Paso 4 - Parámetros y secretos

• Deploy_Env: es el sufijo de nuestro entorno. Por ejemplo yo tenía DeployedApps y DeployedApps_Dev en mi PowerBi Service. Cuando capture cambios de desarrollo (archivo dev.yml) en mi Branch "dev" voy a poner esto en "_Dev". Cuando este sobre el archivo prod.yml, voy a poner branch en main (porque el default es mi producción) y enviar el deploy_env vacío porque se llama "DeployedApps" sin sufijo.
• Tenant_id: id de la organización en Azure tomado de la app registrada para service principal
• App_id: id de cliente o app en Azure tomado de la app registrada para service principal.
• Secret_key: valor del secreto creado en la app de azure registrada para service principal.

Estas variables son críticas no puede estar expuestas por seguridad. Dejamos el código con ese ${{ secrets.variable }} que dice ahí y nos dirigimos a la configuración de nuestro repositorio.

Una vez creadas el código las leerá de ahi y no podemos ver su valor de nuevo.

Paso 5 - Probar

Ya esta todo listo para usar. Si se modifica manualmente o con power bi desktop un archivo dentro de una carpeta .report o .semanticmodel. El flujo lo va a detectar y deployar el código de ese archivo. Pueden comprobarlo en Actions:

Al solo deployar código, no ocurre esto que pasaba antes que si mi PBIX estaba viejo, pisaba los datos actuales del servicio. Aquí solamente aparecen los cambios. No hay necesidad de ejecutar una actualización de datos a menos que ustedes específicamente lo requieran.

¿Qué esta ocurriendo en realidad?

Lo que en realidad ocurre es que al ejecutarse un push, se activa un trigger que captura cambios y los registra. Ese registro se envía a un python script que lee puntualmente que ítem debe deployar. Reúne la información necesaria (workspaces id, semantic models id, etc) para efectuar el deploy.

Esto podrían ejecutarlo desde cualquier lado. Si les interesa indagar más aún con el framework en otra tecnología o ejecutar otros pasos en medio, pueden contactarme o leer su código abierto en el repositorio que llaman en el yaml:

https://github.com/ladataweb/SimplePBI-Ops

Espero que esto los ayude a mejorar sus flujos de trabajo en equipo y deploys continuos.