Administración de ramas en áreas de trabajo de Microsoft Fabric
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 parte de integración continua (CI) del proceso de CI/CD. Para obtener una explicación de la parte de entrega continua (CD), consulte el artículo sobre cómo administrar canalizaciones de implementación.
En este artículo se describen varias opciones de integración distintas, pero muchas organizaciones usan una combinación de las mismas.
Requisitos previos
Para integrar Git con el área de trabajo de Microsoft Fabric, debe configurar los siguientes requisitos previos tanto para Fabric como para Git.
Requisitos previos de Fabric
Para acceder a la característica de integración de Git, necesita una de las siguientes opciones:
- Licencia de Power BI Premium. Una licencia de Power BI Premium solo admite todos los elementos de Power BI.
- Capacidad de Fabric. Se requiere una capacidad de Fabric para usar todos los elementos de Fabric admitidos. Si aún no tiene ninguna, suscríbase para obtener una evaluación gratuita.
Además, los siguientes conmutadores de inquilino deben habilitarse desde el portal de administración:
- Los usuarios pueden crear elementos de Fabric
- Los usuarios pueden sincronizar los elementos del área de trabajo con sus repositorios de Git
- Solo para usuarios de GitHub: los usuarios pueden sincronizar elementos del área de trabajo con repositorios de GitHub
Estos conmutadores se pueden habilitar mediante el administrador de inquilinos, el administrador de capacidad o el administrador del área de trabajo, en función de la configuración de la organización.
Requisitos previos de Git
La integración de Git se admite actualmente para Azure DevOps y GitHub. Para usar la integración de Git con el área de trabajo de Fabric, necesita lo siguiente en Azure DevOps o GitHub:
- Una cuenta de Azure activa registrada en el mismo usuario que usa el área de trabajo de Fabric. Crear una cuenta gratuita.
- Acceso a un repositorio existente.
Proceso de desarrollo
El área de trabajo de Fabric es un entorno compartido que accede a elementos activos. Los cambios realizados directamente en el área de trabajo invalidan y afectan a todos los demás usuarios del área de trabajo. Por lo tanto, el procedimiento recomendado de Git es que los desarrolladores trabajen de forma aislada fuera de las áreas de trabajo compartidas. Hay dos maneras de que un desarrollador funcione en su propia área de trabajo protegida.
- Desarrolle usando herramientas de cliente, como Power BI Desktop para informes y modelos semánticos, o VS Code para cuadernos.
- Desarrolle en un área de trabajo de Fabric independiente. Cada desarrollador tiene su propia área de trabajo donde conecta su propia rama independiente, sincroniza el contenido en esa área de trabajo y, a continuación, vuelve a confirmarla en la rama.
Para trabajar con ramas usando la integración de Git, conecte primero el área de trabajo del equipo de desarrollo compartido a una única rama compartida. Por ejemplo, si su equipo usa un área de trabajo compartida, conéctela a la rama principal del repositorio de su equipo y sincronice el área de trabajo con el repositorio. Si el flujo de trabajo de su equipo tiene varias ramas compartidas, como las ramas de Desarrollo/pruebas/producción, cada rama puede conectarse a un área de trabajo diferente.
A continuación, cada desarrollador puede elegir el entorno aislado en el que trabajar.
Escenario 1: Desarrollo mediante herramientas de cliente
Si los elementos que va a desarrollar están disponibles en otras herramientas, puede trabajar en esos elementos directamente en la herramienta de cliente. No todos los elementos están disponibles en todas las herramientas. Los elementos que solo están disponibles en Fabric deben desarrollarse en Fabric.
El flujo de trabajo para desarrolladores que usa una herramienta de cliente como Power BI Desktop debe tener un aspecto similar al siguiente:
Clone el repositorio en un equipo local. (Solo tiene que realizar este paso una vez).
Abra el proyecto en Power BI Desktop con la copia local de PBIProj.
Realice cambios y guarde los archivos actualizados localmente. Haga commit en el repositorio local.
Cuando esté listo, inserte la rama y los commits en el repositorio remoto.
Para probar los cambios con otros elementos o más datos, conecte la nueva rama a un área de trabajo separada y cargue el modelo semántico y los informes con el botón Actualizar todo del panel Control de código fuente. Realice pruebas o cambios de configuración allí antes de combinarlos en la rama principal .
Si no se requieren pruebas en el área de trabajo, el desarrollador puede combinar los cambios directamente en la rama principal, sin necesidad de otra área de trabajo.
Una vez que se combinan los cambios, se solicita al área de trabajo del equipo compartido que acepte la nueva confirmación. Los cambios se actualizan en el área de trabajo compartida y todos los usuarios pueden ver los cambios en esos modelos semánticos e informes.
Si quiere saber cómo usar el nuevo formato de archivo de Power BI Desktop en Git, consulte Formato de código fuente.
Escenario 2: Desarrollo con otra área de trabajo
Para un desarrollador que trabaja en la Web, el flujo sería el siguiente:
En la pestaña Ramas del menú Control de código fuente, seleccione Ramificar hacia una nueva área de trabajo.
Especifique los nombres de la rama y del área de trabajo. La nueva rama creada en función de la rama conectada al área de trabajo actual.
Seleccione Ramificar.
Fabric crea la nueva área de trabajo y rama. Se abre automáticamente la nueva área de trabajo.
El área de trabajo se sincroniza con la rama de características y se convierte en un entorno aislado en el que trabajar, como se muestra. Ahora puede trabajar en este nuevo entorno aislado. La sincronización puede tardar unos minutos. Para más información acerca de la ramificación, consulte las sugerencias para la solución de problemas.
Guarde sus cambios y haga "commit" en la rama de características.
Cuando esté listo, cree una solicitud de incorporación de cambios en la rama principal . Los procesos de revisión y combinación se realizan a través de Azure Repos en función de la configuración definida por el equipo para ese repositorio.
Una vez completada la revisión y combinación, se crea una nueva confirmación en la rama principal . Esta confirmación solicita al usuario que actualice el contenido en el área de trabajo del equipo de desarrollo con los cambios combinados.
Para más información, consulte Limitaciones de ramificación.
Proceso de lanzamiento
El proceso de versión comienza una vez que las nuevas actualizaciones completan un proceso de solicitud de cambios y se combinan en la rama compartida del equipo’(por ejemplo, Main, Dev, etc.). Desde este punto, describiremos las distintas opciones para crear un proceso de versión en Fabric. Puede encontrar las distintas consideraciones para el proceso de versión en el artículo sobre cómo administrar canalizaciones de implementación.
Cambio de rama
Si el área de trabajo está conectada a una rama de Git y quiere cambiar a otra rama, puede hacerlo rápidamente desde el panel Control de código fuente sin desconectar y reconectar.
Al cambiar de rama, el área de trabajo se sincroniza con la nueva rama y se invalidan todos los elementos del área de trabajo. Si hay versiones diferentes del mismo elemento en cada rama, se reemplaza el elemento. Si un elemento está en la rama anterior, pero no en el nuevo, se elimina.
Para cambiar entre ramas, siga estos pasos:
En la pestaña Ramas del menú Control de código fuente, seleccione Cambiar rama.
Especifique la rama a la que desea conectarse o cree una nueva rama. Esta rama debe contener el mismo directorio que la rama actual.
Seleccione Cambiar rama.
No puede cambiar las ramas si tiene cambios no confirmados en el área de trabajo. Seleccione Cancelar para volver atrás y confirmar los cambios antes de cambiar de rama.
Para conectar el área de trabajo actual a una nueva rama mientras mantiene el estado del área de trabajo existente, seleccione Desproteger nueva rama. Obtenga más información sobre cómo desproteger una nueva rama en Resolución de conflictos en Git.