Administrando el Ciclo de Vida de tus Soluciones en Fabric

Para ser capaces de llevar a cabo un control sobre la publicación de nuevos desarrollos en producción, lo que comúnmente conocemos por CI/CD, es necesario administrar el ciclo de vida de los recursos que forman parte de nuestra solución. En este artículo mostraremos los principales componentes de los que dispone Fabric para poder implementar este proceso de integración y entrega continua.

¡Comenzamos!

Dentro de Fabric disponemos de dos recursos que nos permiten administrar el ciclo de vida de nuestras soluciones, controlando de esta forma la entrega de nuevo contenido en producción: integración de Git y canalizaciones de implementación.

La administración del ciclo de vida de nuestros recursos nos permite disponer de un proceso eficaz y controlado para la gestión de contenido en producción. Esto es lo que se conoce como CI/CD (Integración Continua/Desarrollo Continuo). Dentro de Fabric disponemos de dos componentes principales que nos permiten implementar esta característica:

• Integración de Git
• Canalizaciones de implementación

A continuación, veremos en detalle cada uno de estos componentes, así como los pasos a seguir para implementarlo en nuestra capacidad. Es importante comentar que, a fecha de redacción de este artículo, tanto la integración de Git como algún elemento de las estas canalizaciones de implementación se encuentran en versión preliminar.

La integración de Git en Fabric permite tener un control de versiones de los elementos desarrollados dentro de un área de trabajo, con todas las ventajas que esto conlleva, aunque hay que tener en cuenta que, por el momento, no todos los elementos de Fabric son compatibles con esta funcionalidad. A fecha de redacción, la lista de elementos admitidos es la siguiente:

Además, hasta la fecha, también se debe tener en consideración que solo se admite Git a través de Azure Repos y el inquilino debe ser el mismo que el de Fabric.

Para poder llevar a cabo la integración de Git para todos los elementos de Fabric compatibles es necesario una serie de requisitos previos:

• Disponer de un área de trabajo vinculada a una capacidad de Fabric.
• Dentro del portal de administración de Fabric, se debe habilitar la opción de que los usuarios puedan crear elementos de Fabric. Esta operación debe ser realizada por el administrador del servicio.

Es importante tener en cuenta que únicamente un administrador del área de trabajo podrá conectar y sincronizar la misma con el repositorio de Git. En este enlace se pueden ver las acciones que puede realizar cada rol.

A continuación, vamos a ver el paso a paso de cómo integrar nuestra área de trabajo con Git. Como mencionamos anteriormente, es una configuración a nivel de área de trabajo, por lo que accediendo a la que nos interese, debemos acceder a la configuración y veremos la opción Integración con Git:

Automáticamente se conecta a la cuenta de Azure Repos a través del usuario de AAD, actualmente denominado Microsoft Entra, con el que se ha iniciado sesión dentro de Fabric. Por nuestra parte, debemos configurar el repositorio y la rama a la que deseamos conectarnos y, finalmente seleccionar la opción Conectar y sincronizar.

En esta primera sincronización se pueden dar los siguientes escenarios con los respectivos comportamientos:

• Tanto el área de trabajo como la rama del repositorio tienen elementos que pueden ser distintos: en este caso, se debe seleccionar en qué dirección realizar la sincronización, teniendo en cuenta que se sobrescribirá el contenido.
• Uno de los dos lados contiene elementos, pero el otro está vacío: en este caso, se copiará la información del recurso no vacío al vacío.

Una vez sincronizados, veremos que aparece una nueva columna, Estado de Git, que nos indica cómo se encuentran cada uno de los elementos en comparación al repositorio:

Recientemente, se ha habilitado una nueva característica de la integración de Git que nos permite crear una nueva área de trabajo fácilmente conectada a una nueva rama. Para ello accedemos al menú de Git del área de trabajo:

En ese momento debemos elegir el nombre de la nueva rama, en qué rama se basa y el nombre de la nueva área de trabajo, que se creará sincronizando el contenido automáticamente con la nueva rama. De esta forma, obtenemos un nuevo entorno aislado del principal para nuestros desarrollos.

Las canalizaciones de implementación de Fabric automatizan la entrega de contenido modificado a entornos como pruebas y producción, aunque, al igual que ocurría con la integración de Git, no todos los elementos de Fabric están admitidos para esta característica. Por ejemplo, a fecha de redacción de este artículo no se podrían entregar mediante las canalizaciones de implementación los modelos semánticos de Direct Lake.

A continuación, vamos a ver el paso a paso de la configuración de una canalización. Para crearla debemos acceder a través del panel lateral a la opción de Canalizaciones y asignarle un nombre y una descripción a la misma. En dicho momento, nos aparecerá un desglose para seleccionar las fases que queremos tener en nuestra solución. Por defecto, una canalización constará de tres fases (desarrollo, test y producción), aunque es algo totalmente personalizable a la hora de crear una canalización, pudiendo contener entre dos y diez fases. Para agregar más fases de las predeterminadas haremos uso del botón Agregar.

Una vez tenemos definidas las fases, debemos asignar a cada una de ellas un área de trabajo distinta, que contendrá los elementos de cada una de las fases. Hay que tener en cuenta que cada área de trabajo que vayamos a asignar debe residir en una capacidad de Fabric.

En cada una de las fases podemos definir reglas que nos permiten modificar orígenes de datos (siempre que sean del mismo tipo), parámetros o incluso el lakehouse predeterminado de un cuaderno. Para ello seleccionamos el botón de Reglas de implementación:

En ese momento, nos aparecerá una lista de los elementos en los que se pueden definir las reglas, en nuestro caso, vamos a seleccionar el cuaderno y añadimos la regla que deseamos:

Es importante mencionar, que una vez tengamos configurada nuestra canalización, los despliegues se realizarán mediante emparejamiento de elementos. Es decir, se emparejarán aquellos elementos de las áreas de trabajo correspondientes que tengan el mismo nombre y estén ubicados en la misma carpeta. En el caso en que se añadan elementos a un área de trabajo de una fase posterior a la inicial, este elemento no se emparejará con el elemento correspondiente de la fase inicial (si lo hubiese), por lo que no seremos capaces de detectar cambios en el mismo.

Teniendo esto en cuenta, en el despliegue entre dos etapas, por ejemplo de Desarrollo a Test, se pueden dar las siguientes casuísticas en los elementos emparejados:

• Si un elemento está en Desarrollo pero no en Test, se creará en Test.
• Si un elemento está en Desarrollo y Test pero hay diferencias entre ambos, se actualizará el elemento de Test.
• Si un elemento está en Desarrollo y Test pero no hay diferencias entre ambos, no habrá despliegue de dicho elemento, permanecerá tal y como está.
• Si un elemento está en Test pero no en Desarrollo, no se ha emparejado con ningún elemento por lo que permanece tal y como está.

Estos estados entre elementos emparejados aparecerán reflejados cuando comparamos dos fases:

Al seleccionar la opción Implementar nos divide en dos secciones el contenido que se va a desplegar en la siguiente fase (Diferente y Nuevos):

En este momento, podemos añadir una nota al despliegue que se almacenará en el historial de implementaciones, lo que nos ayudará a llevar un control del histórico de cambios que se han implementado. Si estamos de acuerdo con el contenido que se va a desplegar volvemos a seleccionar Implementar y finalmente podemos ver el estado de ambas fases:

Como comentamos anteriormente, en el caso del lakehouse LH_Test lo que ocurre es que no está emparejado, ya que no existe una referencia al mismo en el entorno de Desarrollo. Podríamos pensar que creando un lakehouse en el área de trabajo DEV solucionaríamos este problema de emparejamiento, pero no es así, ya que el emparejamiento se realiza en el momento de crear la canalización. De hecho, si intentamos crearlo en DEV, la canalización nos devolverá el siguiente error:

Para poder solucionar una situación como la de este tipo, debemos crear el lakehouse en el área de trabajo DEV y eliminarlo del área de trabajo TEST, de forma, que el proceso de implementación de un área a otra se haga a través de la canalización creado.

Una vez tenemos claro el funcionamiento de una canalización de implementación es necesario mencionar los requisitos mínimos a nivel de permisos para poder ejecutar una canalización:

• El usuario debe ser administrador de la canalización, pero no se admiten como administradores los grupos de Microsoft 365.
• El usuario debe tener al menos el rol de miembro en las áreas de trabajo implicadas para poder realizar la implementación sobre dichas áreas. Por ejemplo, si un usuario es miembro de las áreas de trabajo de las fases Desarrollo y Test, pero es visor del área de trabajo correspondiente a la fase de Producción, este va a poder realizar la implementación entre Desarrollo y Test, pero no la implementación de Test a Producción.

Por último, debemos mencionar que, para ejecutar una canalización de implementación desde el servicio, la única manera por el momento es realizarlo manualmente, ya que no es posible automatizarlo. Sin embargo, podemos recurrir a las API de Fabric para automatizar este proceso, tal y como se puede ver en detalle en este enlace.

Como hemos visto a lo largo de este artículo, Fabric nos proporciona dos herramientas que, utilizándolas conjuntamente, nos permite establecer no solo ciertas fases de pruebas en nuestro flujo de despliegue, sino también un control de versiones de los elementos desarrollados, obteniendo de esta forma, un sistema eficaz y controlado de puesta en producción de nuestras soluciones.