Azure DevOps para tus desarrollos en Power BI (VII). Pipeline para las buenas prácticas del report
¡Seguimos con esta serie de artículos! En ellos pretendemos que te introduzcas en el mundo de Azure DevOps, que será nuestro principal aliado en esta aventura. La semana pasada vimos la pipeline que automatizaran el proceso de descomprimir el thin report y obtener una estructura más organizada. Esta semana veremos como aplicar tests de buenas prácticas en nuestro report de forma automática.
Como son varios temas y no queremos dejarte sin aliento, hemos preferido separarlos en artículos independientes. Nuestra intención es entregarte uno nuevo cada semana (o cada vez que podamos).
3. Herramientas que vamos a usar
4. Qué podemos encontrar en Azure DevOps
5. Qué necesito para que esto funcione
6. Pipeline para descomprimir el report
7. Pipeline para las buenas prácticas del report ← ESTAMOS AQUÍ
8. Pipeline de despliegue del report
9. Pipeline de buenas prácticas del modelo semántico
10. Pipeline de despliegue del modelo semántico
Esta serie de artículos los hemos escrito conjuntamente Adrià Belmonte y una servidora y son la fusión de juntar un arquitecto cloud con una ingeniera de datos.
¡Cualquier duda o propuesta de mejora no dudes en dejárnoslo en comentarios!
¡¡Seguimos!!
¿Qué vamos a necesitar?
Crear una pipeline
Lo primero, necesitaremos una nueva pipeline.
La semana pasada, con nuestra primera pipeline, vimos como se creaba. Te dejamos el enlace por aquí para que puedas revisarlo si lo necesitas.
JSON de buenas prácticas
Necesitaremos guardar el JSON con las buenas prácticas en la carpeta a la que luego apuntaremos en nuestra pipe:
\pipelines\config\bparules2.json
Puedes descargar el archivo en el mismo repositorio de PBI Inspector. Al tratarse de un archivo JSON podremos modificarlo para adaptarlo a nuestras necesidades.
Si necesitas profundizar un poco más en qué es PBI Inspector y que incluyen estas normas te dejamos el enlace del artículo en el que hablábamos de ello.
Veamos la pipeline en detalle
A esta pipe la hemos llamado ci-pipelines-scan y será la encargada de analizar nuestro thin report para comprobar que sigue las buenas prácticas que hemos definido. Como en el caso anterior, te dejamos el enlace al repositorio donde la puedes encontrar, no sin antes recomendarte que te tomes un tiempo en entender bien como funciona y que hace cada paso.
Para realizar esta acción utilizaremos la herramienta PBI-Inspector-CLI que es la versión ejecutable por línea de comandos.
El funcionamiento de ci-pipelines-scan a alto nivel es el siguiente:
- Definimos las variables necesarias para poder acceder a la herramienta que necesitamos y al archivo.
- Ejecutaremos el análisis.
- Generaremos un informe HTML donde podremos ver los resultados del paso anterior.
Pero vamos a lo interesante.
- En este caso la pipeline no tiene ningún trigger.
Quedaros con el punto 1, que luego os explicaremos el porqué :)
2. Le indicamos que usaremos los agentes públicos de tipo Windows.
3. Disponemos de distintas variables que, como hemos comentado antes, necesitaremos para instalar PBI Inspector y llamar a nuestro JSON.
- Nos descargaremos PBI Inspector en nuestro agente.
- Procedemos a ejecutar el análisis y generar el informe en formato HTML.
- Ejecutaremos un segundo análisis para que nos muestre en pantalla el resultado que ha tenido nuestro report.
- Subiremos el informe generado de nuestro report como Artifact.
- Publicaremos el informe como HTML. Esto es lo que nos va a permitir ver la información de la siguiente manera:
El informe lo podremos ver en la sección de HTML.
¿Y qué pasa con el trigger del principio? ¿Si no hay trigger como hago que la pipeline se ejecute?
Decirle a la pipeline que se ejecute con una pull-request
En el planteamiento que os mostramos al principio de la serie de artículos, esta pipeline se ejecuta cuando creamos una pull-request. Para conseguir que se ejecute cuando esto suceda deberemos realizar una serie configuraciones extras en nuestro repositorio de Azure DevOps. ¡Vamos a ello!
- Nos dirigiremos a la parte de nuestro repositorio dentro de Project Settings.
2. Iremos a la parte de Repositories
3. Accedemos a nuestro repositorio.
- Iremos a la sección de Policies
- Seleccionamos nuestra rama de main.
Una vez dentro de nuestra rama main, seleccionaremos la opción Build Validation. Donde configuraremos este paso indicando nuestra pipeline y los requisitos que deseemos. Para el caso de Policy Requirement podemos indicar que si no pasa todos los tests no se pueda aceptar la pull-request (Required) o indicar que, aunque no se pasen las buenas prácticas, se pueda aceptar de forma manual (Opcional).
Nuestra recomendación: Habilitar la opción de Required, así nos evitaremos que puedan pasar a producción reportes con errores o fallos.
Con está configuración, cada vez que se ejecute la pipeline se hará con estas normas.
¿Qué veremos la próxima semana?
La próxima semana veremos como está construida la pipeline encargada de desplegar de forma automática nuestro desarrollo al servicio de Power BI.
Referencias y enlaces de interés
GitHub — NatVanG/PBI-Inspector: A rules-based Power BI report layout testing tool.
PBI-Inspector/Rules/Base-rules.json at main · NatVanG/PBI-Inspector · GitHub
