Azure DevOps para tus desarrollos en Power BI (IV). Qué podemos encontrar en Azure DevOps

6 min readMar 5, 2024

¡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 que herramientas de código abierto íbamos a usar para conseguir nuestros objetivos. En esta ocasión haremos un breve repaso a los diferentes elementos que utilizaremos dentro de Azure DevOps y haremos un overview de lo que se nos viene ;)

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).

1. Introducción

2. ¿Qué es eso de DevOps?

3. Herramientas que vamos a usar

4. Qué podemos encontrar en Azure DevOps ← ESTAMOS AQUÍ

5. Y qué necesito para que esto funcione

6. Pipeline para descomprimir el report

7. Pipeline para las buenas prácticas del report

8. Pipeline de despliegue del report

9. Pipeline de buenas prácticas del modelo semántico

10. Pipeline de despliegue del modelo semántico

11. Conclusiones

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é es Azure DevOps?

Azure DevOps es una plataforma integral para la colaboración y gestión del ciclo de vida del desarrollo de software.

Si llegas de nuevas en este capítulo, te recomendamos que pases antes por ¿Qué es eso de DevOps?

Se usa para:

Colaborar en equipos de desarrollo de software.
Gestionar y versionar el código fuente de aplicaciones.
Automatizar la compilación, prueba y entrega continua.
Realizar pruebas y seguimiento de errores.
Administrar dependencias y reutilizar paquetes de software

Si es la primera vez que trabajas con esta herramienta deberás crear una organización y dentro de esta, crear un proyecto para trabajar sobre él.

Azure Repos

Los repositorios de Azure DevOps son herramientas de gestión de código que permiten a los equipos colaborar en proyectos de software. Estos repositorios proporcionan un espacio centralizado para almacenar y organizar el código de una aplicación.

Las características que más nos interesan son:

Permite realizar un seguimiento de las diferentes versiones del código.
Facilita la colaboración entre miembros del equipo al gestionar los cambios.
Permite la creación de ramas para desarrollar nuevas funciones o realizar correcciones de errores sin afectar la rama principal.

Tip. UNA FUNCIONALIDAD NUEVA, UNA RAMA NUEVA. Y todo con nombres descriptivos. Te facilitará la vida, créenos.

Facilita la fusión de cambios entre diferentes ramas.
Se integra con pipelines de CI/CD para automatizar la compilación, prueba y despliegue de aplicaciones directamente desde el repositorio.

De hecho, justo de esto hablamos en el siguiente punto.

Proporciona características de seguridad y control de acceso para garantizar la protección del código.
Registra actividades y cambios realizados en el repositorio para proporcionar un historial detallado y permitir auditorías.

En este caso deberemos crear dos repositorios, uno para el dataset y otro para el report. Súper importante, que los nombres de estos repositorios sean descriptivos. <nombre del desarrollo>.dataset y <nombre del desarrollo>.report, por ejemplo

Azure Pipelines

Las Pipelines en Azure DevOps son la parte encargada de automatizar el proceso de desarrollo, pruebas y despliegue de aplicaciones. Proporcionan un conjunto de características que facilitan la implementación de prácticas de Integración Continua (CI) y Despliegue Continuo (CD).

Algunos aspectos clave incluyen:

Permite la automatización de tareas como la compilación, las pruebas y el despliegue, optimizando el ciclo de vida del desarrollo.

Automatizar siempre es sinónimo de evitar el posible error humano en tareas repetitivas.

Utiliza archivos YAML para definir la configuración de las pipelines como código, permitiendo un control versionado y una gestión eficiente.
Ofrece un amplio conjunto de extensiones que pueden integrarse con herramientas de terceros, lo que facilita la construcción de pipelines personalizadas para necesidades específicas.

Este punto es importante, la próxima semana veremos las extensiones que hemos usado en nuestras pipes.

Proporciona paneles de control y herramientas de visualización para monitorear el progreso, identificar posibles cuellos de botella y mejorar la eficiencia.

Para nuestro objetivo crearemos un total de 5 pipelines que iremos viendo en detalle las próximas semanas.

¿Qué vamos a tener?

Una organización con un proyecto. (Si no lo tienes ya creado y gestionado por tu empresa).
Dos repositorios. Un repositorio para el report y otro para el dataset. Esto nos permitirá una mayor flexibilidad y granularidad para poder asignar permisos.
Pipelines. Un total de 5 pipelines: dos pipelines para los despliegues del report y dataset, otras dos para el control de buenas prácticas y una quinta para extraer en carpetas y archivos separados la información del report.
Los archivos correspondientes dentro del repositorio. Para el modelo semántico usaremos el model.bim y para el report el .pbix.

¿Qué vamos a hacer?

Aquí tenéis el resumen a alto nivel de lo que hemos desarrollado.

Para nuestro modelo semántico

Nuestro modelo tabular será desarrollado con la herramienta Tabular Editor y lo guardaremos en el formato .bim.
Subiremos este archivo al repositorio de Azure DevOps destinado a nuestros modelos semánticos.
Desde ahí crearemos y gestionaremos nuestras ramas para nuevas características.
Cuando el desarrollo esté listo y queramos unir nuestros cambios harems una pull-request. Esta ejecutará una primera pipeline que nos pasará todos los test de buenas prácticas.
En caso pasar estas pruebas los cambios pasaran a nuestra rama principal. En caso de no pasarlos, deberemos seguir trabajando para conseguirlo.
Una vez tengamos las modificaciones en nuestra rama principal, se ejecutará la pipeline de despliegue al servicio.

Para nuestro report

Para trabajar en nuestro report crearemos una Live Connection al modelo semántico que tengamos desplegado en el servicio y procederemos a hacer nuestros visuales.
Subiremos el archivo pbix al repositorio destinado para el report.
Una vez esté en nuestra rama de feature, se ejecutara la primera pipeline de descomprensión que nos facilitara una estructura de carpetas y archivos json individuales por cada objeto visual.
Una vez queramos que los cambios se integren en nuestra rama principal, haremos pull-request y se ejecutará una segunda pipeline de buenas prácticas.
Si los tests se pasan con éxito los cambios se integrarán. En caso contrario, deberemos volver al punto 1 y arreglar los errores.
Una vez tengamos los cambios en nuestra rama principal, se procederá a ejecutar una tercera pipeline que se encargará de desplegar nuestro reporte en el servicio.

En próximos episodios…

Ahora ya tenemos todas las bases asentadas de lo que vamos a utilizar. Tenemos la visión completa de nuestro mapa del tesoro. La semana que viene nos tocará arremangarnos y conectar todos los elementos para empezar nuestro viaje. Nos esperan Entra ID con su Service Principal, Azure DevOps (al que vamos a empezar a llamar ADO) con su Service Connection y el Servicio de Power BI, con el XMLA endpoint y los permisos necesarios.

Ya sabes, cualquier feedback, recomendación o duda, ¡no te cortes! Déjanoslo en comentarios.