Azure DevOps para tus desarrollos de Power BI (II). ¿Qué es eso de DevOps?

¡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 hicimos una breve introducción hablando de cómo nos habíamos apañado hasta ahora, de la integración de Azure DevOps con Fabric y del nuevo formato de archivo con el que podemos guardar, el .pbip.

Como son varios temas no queremos dejarte sin aliento, hemos preferido separarlos en artículos independientes. Nuestra intención es entregarte uno nuevo cada martes (o cada vez que podamos).

1. Introducción

2. ¿Qué es eso de DevOps? ← ESTAMOS AQUÍ

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

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 SRE con una ingeniera de datos.

¡Cualquier duda o propuesta de mejora no dudes en dejárnoslo en comentarios!

¡¡Con café en mano, continuamos!!

CI/CD

Estas siglas hacen referencia a las prácticas de CI (Integración Continua) y CD (Despliegue Continuo) en el desarrollo de software.

• Integración Continua (CI). Es un enfoque donde los desarrolladores integran su código en un repositorio compartido. Cada integración se verifica automáticamente mediante pruebas, asegurando que el código funcione correctamente y no cause conflictos con otras contribuciones.
• Despliegue Continuo (CD).Una vez que el código ha pasado las pruebas de integración, el Despliegue Continuo implica llevar ese código probado a nuestro entorno seleccionado. Este despliegue está automatizado y no necesita de factor humano que lo lleve a cabo.

CI/CD busca automatizar y agilizar el proceso de desarrollo de software, desde la escritura del código hasta su implementación. Esto ayuda a detectar errores más fácilmente y en fases no productivas, mejora la calidad del software y permite entregas más rápidas y frecuentes.

¿Qué es git?

Git es un sistema de control de versiones que permite a los desarrolladores rastrear los cambios en su código fuente a lo largo del tiempo.

Por otro lado, GitHub, GitLab y Azure DevOps son servicios basados en la nube que utilizan Git como sistema de control de versiones y ofrecen funcionalidades adicionales para facilitar la colaboración y la gestión del desarrollo de software.

Git es el sistema de control de versiones, mientras que GitHub, GitLab y Azure DevOps son plataformas que utilizan Git y proporcionan servicios adicionales para facilitar la colaboración y la gestión del desarrollo de software en equipo. Visto de otra manera, Git sería la tecnología y GitHub, GitLab y Azure DevOps las herramientas que usan esa tecnología. Vendría a ser como el caso de Netflix al streaming, el streaming es la tecnología y Netflix se basa en esa tecnología.

Ramas

Este es el esquema más básico de ramas de Git:

Las ramas en Git son líneas independientes de desarrollo que permiten a los equipos trabajar en características, correcciones de errores o mejoras sin interferir directamente con el código principal. Hay diferentes estrategias aplicadas a la gestión de las ramas, te presentamos las más comunes:

1. Feature Branching (Ramas de características): Cada nueva característica se desarrolla en una rama separada. Esto ayuda a mantener un historial limpio y aislado para cada función.
2. Git Flow: Es una metodología que define un conjunto específico de ramas y reglas para cómo deben fusionarse. Incluye ramas como master, develop, feature, release y hotfix. Es utilizado para proyectos más grandes.
3. GitHub Flow: Una estrategia simple centrada en el uso de una rama principal (generalmente main), con ramas de características que se crean y fusionan de forma continua. Ideal para proyectos más pequeños y equipos ágiles.
4. Hay muchas otras estrategias, es cuestión de encontrar la que más se adecue a tu equipo o adaptar las ya existentes

La elección de la estrategia depende del tamaño del proyecto, la estructura del equipo y las preferencias del desarrollo. Es importante tener una estrategia de ramificación (branch) clara para facilitar la colaboración y el mantenimiento del código.

Flujo de trabajo

Cuando comienzas un proyecto, generalmente dispones de una rama principal (por lo general llamada main). Os queremos enseñar los comandos básicos de git y como funcionan. Hoy en día, podemos utilizar distintos editores de código, como VSCode o el propio portal de Azure DevOps, que nos permite realizar todas estás acciones desde una interfaz. Pero es importante conocer los comandos

1. Clonar el repositorio:

• Descarga una copia del repositorio remoto en tu máquina local.
• Comando: git clone <URL_del_repositorio> . También lo puedes hacer desde la interfaz de usuario.

Cuando necesitas trabajar en una nueva característica o corrección de errores, creas una nueva rama. Esto se hace para evitar afectar el código en la rama principal.

2. Crear una nueva rama de feature:

• Crea una nueva rama para trabajar en una nueva característica o corrección sin afectar la rama principal.
• Comando: git branch <nombre_de_la_rama> (Crea la rama)
• Comando adicional: git checkout <nombre_de_la_rama> (Cambia a la nueva rama)

3. Trabajar en la rama:

• Realiza cambios en los archivos de la nueva rama.

4. Publicar en el repositorio en remoto:

• Guarda tus cambios localmente en la rama.
• Comando: git add . (Añade los cambios al área de preparación)
• Comando: git commit -m "Mensaje descriptivo" (Guarda los cambios). Se puede hacer desde la interfaz de usuario.

5. Crear una Pull Request:

• Proporciona una solicitud para fusionar tus cambios en la rama principal.
• Comando: git commit -m "Mensaje descriptivo" Se puede hacer desde la interfaz de usuario.

6. Resolver los conflictos:

• Si hay conflictos entre tu rama y la rama principal, debes solucionarlos. Utiliza un editor de código o una herramienta para resolver los conflictos.

Una vez que tus cambios están listos y probados, puedes fusionar la rama de la característica de nuevo en la rama principal. Después de la fusión, puedes decidir eliminar la rama de la característica si ya no la necesitas.

7. Fusionar los cambios:

• Incorpora los cambios de tu rama en la rama principal.
• Comando: git checkout <nombre_de_la_rama_principal> (Cambia a la rama principal)
• Comando: git merge <nombre_de_tu_rama> (Fusiona tus cambios en la rama principal)

¿Qué veremos la próxima semana?

¡Segunda semana superada!

Para la próxima empezaremos a meternos en materia viendo que herramientas vamos a usar para mejorar la calidad de nuestros desarrollos. Nos esperan pbi-tools, Tabular Editor y PBI Inspector.

← Introducción

Herramientas que vamos a usar →

Referencias y enlaces de interés

GitFlow: https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow

GIT: https://learn.microsoft.com/es-es/devops/develop/git/what-is-git

CICD: https://unity.com/es/solutions/what-ci-cd#:~:text=%C2%BFQu%C3%A9%20es%20CI%2FCD%3F,la%20entrega%20continua%20de%20c%C3%B3digo.