Preguntas más frecuentes sobre las herramientas de administración del ciclo de vida de Fabric

La administración del ciclo de vida tiene dos partes, la integración y la implementación. Para comprender qué integración se encuentra en Fabric, consulte la introducción a la integración de Git. Para entender qué son las canalizaciones de implementación en Fabric, consulte la introducción a las canalizaciones de implementación.

Para obtener una explicación breve de la integración de Git, consulte Introducción a la integración de Git. Esta es una respuesta multilínea o con formato a la pregunta. Use cualquier formato de Markdown que desee, siempre que mantenga la sangría en las líneas después de los caracteres |.

Para una breve explicación de las canalizaciones de implementación, consulte la Introducción a las canalizaciones de implementación.

Para obtener información sobre las licencias, consulte Fabric licencias.

Todas las áreas de trabajo deben asignarse a una licencia de Fabric. Sin embargo, puede usar diferentes tipos de capacidad para diferentes áreas de trabajo.

Para obtener información sobre los tipos de capacidad, consulte Capacidad y SKU.

El modelo de permisos de canalizaciones de implementación se describe en la sección Permisos.

Para configurar reglas de implementación en canalizaciones de implementación, debe ser el propietario del modelo semántico.

Si la capacidad del área de trabajo está en una ubicación geográfica mientras el repositorio de Azure DevOps se encuentra en otra ubicación, el administrador de Fabric puede decidir si habilitar exportaciones entre regiones geográficas. Para obtener más información, consulte Usuarios pueden exportar elementos a repositorios de Git en otras ubicaciones geográficas.

Comenzar con la integración de Git mediante las instrucciones para comenzar.

Podría haber varias razones por las que se quitó un elemento del área de trabajo.

• Si el elemento no se ha confirmado y lo seleccionaste en una acción de deshacer, el elemento se quita del área de trabajo.
• Si el elemento hubiera sido confirmado, podría eliminarse si cambia de rama y el elemento no existe en la nueva rama.

Las consideraciones siguientes son importantes tener en cuenta:

• Limitaciones de las reglas de implementación
• Orígenes de datos admitidos para las reglas de los modelos semánticos y los flujos de datos
• Actualización incremental
• Automation

Puede asignar un área de trabajo a la canalización e implementarla en las siguientes fases de la canalización, o bien asignar un área de trabajo diferente a cada fase de canalización. Para obtener más información, consulte Asignar un área de trabajo a una tubería de despliegue.

Los conjuntos de datos que usan el modo de conectividad DirectQuery o Composite y tienen tablas de variación o fecha y hora automáticas no se admiten en las canalizaciones de implementación. Si se produce un error en la implementación y cree que es porque tiene un conjunto de datos con una tabla de variaciones, puede buscar la propiedad variations en las columnas de la tabla. Puede usar uno de los métodos siguientes para editar el modelo semántico para que funcione en las canalizaciones de implementación.

• En el conjunto de datos, en lugar de usar DirectQuery o el modo Composite, use el modo de importación.

• Quite las tablas de fecha y hora automáticas del modelo semántico. Si es necesario, elimine las variaciones restantes de todas las columnas de las tablas. La eliminación de una variación puede invalidar las medidas creadas por el usuario, las columnas calculadas y las tablas calculadas. Use este método solo si comprende cómo funciona su modelo semántico, ya que puede provocar la corrupción de datos en sus visualizaciones.

Al anclar un icono a un panel, si el icono se basa en un elemento no admitido (cualquier elemento que no está en esta lista no es compatible) o en un elemento que no tiene permisos para implementar, después de implementar el panel, el icono no se representa. Por ejemplo, si crea un icono a partir de un informe que se basa en un modelo semántico del que no es administrador, al implementar el informe recibirá una advertencia de error. Pero al implementar el panel con el icono, no recibirá un mensaje de error; la implementación se realizará correctamente, pero el icono no mostrará ninguna información.

Para una breve explicación de los planes de despliegue, consulte la visión general del plan de despliegue.

El tipo de elemento del plan de despliegue aparece solo después de que un administrador de Fabric active la configuración de inquilino. En el portal de administración, en Configuración del inquilino>Microsoft Fabric, habilite Los usuarios pueden crear elementos de plan de implementación (versión preliminar), establezca Aplicar a en toda la organización o un grupo de seguridad, y seleccione Aplicar.

Hasta que esta configuración esté activada, el tipo de objeto permanece oculto en todos los espacios de trabajo.

El despliegue vuelve a su comportamiento por defecto. Los elementos se despliegan sin una orden declarada y sin acciones previas o posteriores al despliegue. Cualquier dependencia que protegía el plan, como una vista de almacén de datos que lee una tabla de lakehouse alimentada por un notebook, vuelve a fallar.

Un plan correctamente ordenado despliega los metadatos de los elementos en el orden en que los declaras, pero desplegar un lakehouse no inserta filas en sus tablas. Una vista de almacén que lee una tabla lakehouse no se vincula a menos que un cuaderno o una tubería de datos haya producido esa tabla primero. Añade una acción posterior al despliegue entre la casa del lago y el almacén que produce la mesa. Una acción informa de la finalización cuando la acción termina, no cuando los servicios que alimenta se han puesto al día, así que pon cualquier comprobación de preparación en la última celda del cuaderno o en la última actividad de la cadena de datos. Para un ejemplo, véase ejemplos de planes de despliegue.

El campo predeterminado de la casa del lago de un cuaderno contiene IDs que apuntan a una casa específica en un espacio de trabajo concreto. Después de que el cuaderno aterriza en un nuevo espacio de trabajo a través de Git, esos IDs pueden seguir apuntando al espacio de trabajo original. O bien establecer el lakehouse predeterminado para el entorno de destino en la configuración del cuaderno antes de la ejecución, o bien hacer que el cuaderno determine su lakehouse en tiempo de ejecución. Para obtener más información, consulte Control de código fuente de Notebook e implementación.

La salida de ejecución es visible desde el despliegue en el portal. Las ejecuciones de acción enlazan al historial de ejecuciones del elemento subyacente para registros y detalles de pasos.

Un despliegue fallido no revierte los despliegues de ítems completados ni los cambios realizados por acciones. Para obtener instrucciones para la recuperación, consulta La implementación se detuvo a mitad del proceso.

No directamente. Inicia Actualización desde Git mediante un programador externo como Azure Pipelines o Acciones de GitHub, y el plan adjunto se ejecuta como parte de esa implementación.

Sí, si la pipeline impulsa el despliegue a través de una API Fabric que soporta adjuntar un plan, como la API de sincronización de Git, la API de despliegue de las canalizaciones de despliegue o la API de importación por lotes. Un despliegue impulsado por la CLI de Fabric, el proveedor de Terraform para Fabric, o la biblioteca Python fabric-cicd no puede adjuntar un plan.

N.º Un plan regula los elementos en un despliegue y las acciones que los rodean. La configuración a nivel de espacio de trabajo no forma parte de un despliegue, por lo que configuraciones como la identidad del espacio de trabajo, la configuración de Spark y la conexión Git no se crean ni actualizan mediante un plan.

Configúranlas en el espacio de trabajo objetivo antes de desplegarlas. Un elemento que depende de la configuración a nivel de espacio de trabajo, como un cuaderno que se autentica mediante la identidad del espacio de trabajo, falla en tiempo de ejecución si el espacio de trabajo destino no está configurado igual que el origen.

N.º Un plan de despliegue sigue el modelo estándar de espacio de trabajo de Fabric. Para más información, consulte permisos para planes de despliegue.

El propietario de un informe paginado implementado es el usuario que implementó el informe. Al implementar un informe paginado por primera vez, se convertirá en el propietario del informe.

Si se va a implementar un informe paginado en una fase que ya contiene una copia del informe paginado, se sobrescribirá el informe anterior y se convertirá en su propietario, reemplazando al propietario anterior. En tales casos, debe tener credenciales para el origen de datos subyacente, de modo que los datos se puedan usar en el informe paginado.

Los subinformes de un informe paginado se guardan en la misma carpeta que contiene el informe paginado. Para evitar problemas de representación, al usar la copia selectiva para copiar un informe paginado con subinformes, seleccione el informe primario y los subinformes.

Las reglas de informe paginado se pueden crear si desea apuntar el informe paginado al modelo semántico en la misma fase. Al crear una regla de implementación para un informe paginado, debe seleccionar una base de datos y un servidor.

Si establece una regla de implementación para un informe paginado que no tiene un modelo semántico de Fabric, ya que el origen de datos de destino es externo, debe especificar tanto el servidor como la base de datos.

Sin embargo, los informes paginados que usan un modelo semántico de Fabric usan un modelo semántico interno. En tales casos, no puede confiar en el nombre del origen de datos para identificar el modelo semántico de Fabric al que se conecta. El nombre del origen de datos no cambia al actualizarlo en la fase de destino mediante la creación de una regla de origen de datos o una llamada a la API de actualización de orígenes de datos. Al establecer una regla de implementación, debe mantener el formato de la base de datos y reemplazar el identificador de objeto del modelo semántico en el campo de base de datos. Dado que el modelo semántico es interno, el servidor permanece igual.

• Database: el formato de base de datos de un informe paginado con un modelo semántico de Fabric, es sobe_wowvirtualserver-<dataset ID>. Por ejemplo, sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Reemplace <dataset ID> por el identificador del conjunto de datos. Puede obtener el identificador del conjunto de datos desde la dirección URL seleccionando el GUID que va después de datasets/ y delante de la siguiente barra diagonal.

  

• Servidor: el servidor que hospeda la base de datos. Mantenga el servidor existente tal cual.

Después de una implementación, si descarga el archivo RDL del informe paginado, puede que no esté actualizada con la versión más reciente que puede ver en el servicio de Power BI.

Cuando tiene un flujo de datos que contiene modelos semánticos configurados con actualización incremental, la directiva de actualización no se copia ni se sobrescribe durante la implementación. Después de implementar un flujo de datos que incluya un modelo semántico con actualización incremental en una fase que no incluya este flujo de datos, si tiene una directiva de actualización, deberá volver a configurarlo en la fase de destino. Si implementa un flujo de datos con actualización incremental en una etapa donde ya reside, la política de actualización incremental no se copiará. En esos casos, si quiere actualizar la política de actualización en la fase de destino, tendrá que hacerlo manualmente.

Contenido relacionado

• Comenzar con la integración de Git
• Comienza con las canalizaciones de implementación