Compartir a través de

Elección de la mejor opción de flujo de trabajo de CI/CD de Fabric para usted

  • Artículo

El objetivo de este artículo es presentar a los desarrolladores de Fabric diferentes opciones para crear procesos de CI/CD en Fabric, en función de los escenarios de cliente comunes. Este artículo se centra más en la Implementación continua (CD) del proceso de CI/CD. Para un análisis de la parte de integración continua (CI), consulte Administración de ramas de Git.

Aunque en este artículo se describen varias opciones distintas, muchas organizaciones toman un enfoque híbrido.

Requisitos previos

Para acceder a la característica de canalizaciones de implementación, debe cumplir las condiciones siguientes:

Proceso de desarrollo

El proceso de desarrollo es el mismo en todos los escenarios de implementación y es independiente de cómo publicar nuevas actualizaciones en producción. Cuando los desarrolladores trabajan con el control de código fuente, deben trabajar en un entorno aislado. En Fabric, ese entorno puede ser un IDE en la máquina local (como Power BI Desktop o VS Code) o en un área de trabajo diferente de Fabric. Puede encontrar información sobre las distintas consideraciones para el proceso de desarrollo en Administrar ramas de Git

Diagrama que muestra cómo funciona el proceso de desarrollo.

Proceso de lanzamiento

El proceso de lanzamiento se inicia una vez completadas las nuevas actualizaciones y la solicitud de incorporación de cambios (PR) se combina en la rama compartida del equipo (por ejemplo, Principal, Desarrollo etc.). Desde este punto, hay diferentes opciones para crear un proceso de versión en Fabric.

Opción 1: implementaciones basadas en Git

Diagrama que muestra cómo funciona la implementación basada en Git.

Con esta opción, todas las implementaciones se originan en el repositorio de Git. Cada fase de la canalización de versión tiene una rama principal dedicada (en el diagrama, estas fases son Desarrollo, Pruebas y Producción), que alimenta el área de trabajo adecuada en Fabric.

Una vez que una solicitud de cambios (PR) a la rama Desarrollo se aprueba y combina:

  1. Se desencadena una canalización de versión para actualizar el contenido del área de trabajo de Desarrollo. Este proceso también puede incluir una canalización de Compilación para ejecutar pruebas unitarias, pero la carga real de archivos se realiza directamente desde el repositorio en el área de trabajo, mediante las API de Git de Fabric. Es posible que tenga que llamar a otras API de Fabric para las operaciones posteriores a la implementación que establecen configuraciones específicas para esta área de trabajo o ingieren datos.
  2. A continuación, se crea una solicitud de incorporación de cambios en la rama de Pruebas. En la mayoría de los casos, la incorporación de solicitud de cambios se crea mediante una rama de versión que puede seleccionar el contenido para pasar a la siguiente fase. La solicitud de incorporación de cambios debe incluir los mismos procesos de revisión y aprobación que cualquier otro de su equipo u organización.
  3. Se desencadena otra canalización de compilación y versión para actualizar el área de trabajo de Pruebas, usando un proceso similar al descrito en el primer paso.
  4. Se crea una solicitud de cambios para la rama de Producción, usando un proceso similar al descrito en el paso 2.
  5. Se desencadena otra canalización de compilación y versión para actualizar el área de trabajo de Producción, usando un proceso similar al descrito en el primer paso.

¿Cuándo debe considerar la posibilidad de usar la opción 1?

  • Cuando quiera usar el repositorio de Git como fuente única de la verdad y el origen de todas las implementaciones.
  • Cuando su equipo sigue Gitflow como estrategia de ramificación, incluyendo varias ramas primarias.
  • La carga desde el repositorio va directamente al área de trabajo, ya que no necesitamos entornos de compilación para alterar los archivos antes de implementarlos. Puede cambiarlo llamando a las API o ejecutando elementos en el área de trabajo después de la implementación.

Opción 2: implementaciones basadas en Git mediante entornos de compilación

Diagrama que muestra el flujo de implementación basada en Git mediante entornos de compilación.

Con esta opción, todas las implementaciones se originan en la misma rama del repositorio de Git (Principal). Cada fase de la canalización de compilación tiene una canalización dedicada de compilación y versión. Estas canalizaciones pueden usar un Entorno de compilación para ejecutar pruebas unitarias y scripts que cambian algunas de las definiciones de los elementos antes de cargarlas en el área de trabajo. Por ejemplo, es posible que quiera cambiar la conexión del origen de datos, las conexiones entre elementos del área de trabajo o los valores de los parámetros para ajustar la configuración de la fase correcta.

Una vez aprobada y combinada una solicitud de cambios en la rama de desarrollo:

  1. Se desencadena una canalización de compilación para crear un nuevo entorno de compilación y ejecutar pruebas unitarias para la fase de desarrollo. Después, se activa una canalización de versión para cargar el contenido en un entorno de compilación, ejecutar scripts para cambiar parte de la configuración, ajustar la configuración a la fase de desarrollo y utilizar las API de definición de elemento de actualización de Fabric para cargar los archivos en el área de trabajo.
  2. Una vez finalizado este proceso, que incluye la ingesta de datos y la aprobación de los administradores de las versiones, se pueden crear las siguientes canalizaciones de compilación y versión para la fase de pruebas. Estas fases se crean en un proceso similar al descrito en el primer paso. Para la fase de pruebas, podrían ser necesarias otras pruebas automatizadas o manuales después de la implementación, para validar que los cambios están listos para ser publicados en la fase de Producción.
  3. Una vez finalizadas todas las pruebas automatizadas y manuales, el administrador de versiones puede aprobar y enviar las canalizaciones de compilación y versión a la fase de Producción. Como la fase de Producción suele tener configuraciones diferentes a las de las fases de pruebas/desarrollo, es importante probar también los cambios después de la implementación. Además, la implementación debería desencadenar más ingesta de datos, en función del cambio, para minimizar la posible falta de disponibilidad para los consumidores.

¿Cuándo debe considerar la posibilidad de usar la opción 2?

  • Cuando quiera usar Git como única fuente de verdad y origen de todas las implementaciones.
  • Cuando su equipo sigue el flujo de trabajo basado en troncos como estrategia de ramificación.
  • Necesita un entorno de compilación (con un script personalizado) para modificar los atributos específicos del área de trabajo, como connectionId y lakehouseId, antes de la implementación.
  • Necesita una canalización de publicación (script personalizado) para recuperar el contenido de los elementos de Git y llamar a la correspondiente API de elementos de Fabric para crear, actualizar o eliminar elementos de Fabric modificados.

Opción 3: Implementación mediante canalizaciones de implementación de Fabric

Diagrama que muestra el flujo de implementación basada en Git mediante canalizaciones de implementación.

Con esta opción, Git solo se conecta hasta la fase de desarrollo. Desde la fase de desarrollo, las implementaciones se producen directamente entre las áreas de trabajo de Desarrollo/Pruebas/Producción, usando canalizaciones de implementación de Fabric. Aunque la herramienta en sí es interna de Fabric, los desarrolladores pueden usar las API de canalizaciones de implementación para orquestar la implementación como parte de su canalización de publicación en Azure, o un flujo de trabajo de GitHub. Estas API permiten al equipo compilar un proceso de compilación y versión similar al de otras opciones, usando pruebas automatizadas (que pueden realizarse en el propio área de trabajo, o antes de la fase de desarrollo), aprobaciones, etc.

Una vez aprobada y combinada la solicitud de cambios en la rama principal:

  1. Se desencadena una canalización de compilación que carga los cambios a la fase de desarrollo usando las API de Git de Fabric. Si es necesario, la canalización puede desencadenar otras API para iniciar operaciones/pruebas posteriores a la implementación en la fase de desarrollo.
  2. Una vez finalizada la implementación en desarrollo, se pone en marcha una canalización de versión para implementar los cambios de la fase desarrollo a la fase pruebas. Las pruebas automatizadas y manuales deberían tener lugar después de la implementación, para garantizar que los cambios están bien probados antes de llegar a producción.
  3. Una vez que se han completado las pruebas y el administrador de la versión aprueba la implementación en la fase de Producción, se inicia la implementación en la fase de Producción y se completa la implementación.

¿Cuándo debe considerar la posibilidad de usar la opción 3?

  • Cuando utilice el control de código fuente solo para fines de desarrollo y prefiera implementar los cambios directamente entre las fases de la canalización de versiones.
  • Cuando las reglas de implementación, el enlace automático y otras API disponibles son suficientes para administrar las configuraciones entre las fases de la canalización de versión.
  • Cuando quiera usar otras funcionalidades de las canalizaciones de implementación de Fabric, como la visualización de cambios en Fabric, el historial de implementaciones, etc.
  • Considere también que las canalizaciones de implementación en Fabric tienen una estructura lineal y requieren otros permisos para crear y administrar la canalización.

Opción 4: CI/CD para ISV en Fabric (administrando múltiples clientes o soluciones)

Diagrama que muestra el flujo de implementación basada en Git para ISV.

Esta opción es diferente de las demás. Es más relevante para los proveedores de software independientes (ISV) que crean aplicaciones SaaS para sus clientes sobre Fabric. Los ISV suelen tener un área de trabajo independiente para cada cliente y pueden tener hasta varios cientos o miles de áreas de trabajo. Cuando la estructura de análisis que se proporciona a cada cliente es similar y predefinida, recomendamos tener un proceso centralizado de desarrollo y pruebas que se separe para cada cliente solo en la fase de Producción.

Esta opción se basa en la opción 2. Una vez aprobada y combinada la solicitud de cambios en la rama principal:

  1. Se desencadena una canalización de compilación para crear un nuevo entorno de compilación y ejecutar pruebas unitarias para la fase de desarrollo. Una vez completadas las pruebas, se desencadena una canalización de versión. Esta canalización puede cargar el contenido en un entorno de compilación, ejecutar scripts para cambiar parte de la configuración, ajustar la configuración a la fase de desarrollo y utilizar las API de definición de elemento de actualización de Fabric para cargar los archivos en el área de trabajo.
  2. Una vez completado este proceso, incluida la ingesta de datos y la aprobación de los administradores de versiones, se pueden iniciar las siguientes canalizaciones de compilación y versión para la fase de pruebas. Este proceso es similar al descrito en el primer paso. Para la fase de pruebas, podrían ser necesarias otras pruebas automatizadas o manuales después de la implementación, para validar que los cambios están listos para ser publicados en la fase de Producción en alta calidad.
  3. Una vez pasadas todas las pruebas y finalizado el proceso de aprobación, podrá comenzar la implementación en los clientes de Producción. Cada cliente tiene su propia versión con sus propios parámetros, para que su configuración específica y la conexión de datos puedan tener lugar en el área de trabajo del cliente correspondiente. El cambio de configuración puede producirse a través de scripts en un entorno de compilación, o usando API posteriores a la implementación. Todos los lanzamientos pueden producirse en paralelo, ya que no están relacionados ni dependen unos de otros.

¿Cuándo debe considerar la posibilidad de usar la opción 4?

  • Es un ISV que crea aplicaciones sobre Fabric.
  • Usa diferentes áreas de trabajo para cada cliente con el fin de administrar los múltiples inquilinos de su aplicación.
  • Para una mayor separación, o para pruebas específicas para diferentes clientes, es posible que quiera tener varios inquilinos en fases anteriores de desarrollo o pruebas. En ese caso, tenga en cuenta que con varios inquilinos el número de áreas de trabajo necesarias crece significativamente.

Resumen

Este artículo resume las principales opciones de CI/CD para un equipo que quiere crear un proceso automatizado de CI/CD en Fabric. Aunque exponemos cuatro opciones, las limitaciones de la vida real y la arquitectura de la solución podrían prestarse a opciones híbridas o completamente diferentes. Puede usar este artículo para guiarse por las diferentes opciones y cómo compilarlas, pero no está obligado a elegir solo una de ellas.

Algunos escenarios o elementos específicos pueden tener limitaciones que le impidan adoptar cualquiera de estos escenarios.

Lo mismo sucede con las herramientas. Aunque mencionamos diferentes herramientas aquí, puede elegir otras herramientas que pueden proporcionar el mismo nivel de funcionalidad. Tenga en cuenta que Fabric tiene una mejor integración con algunas herramientas, por lo que elegir otras dan lugar a más limitaciones que necesitan soluciones alternativas diferentes.

Contenido relacionado