Escenarios de uso de Power BI: publicación de contenido empresarial

Nota

Este artículo forma parte de la serie de artículos sobre el planeamiento de la implementación de Power BI. Esta serie se centra principalmente en la carga de trabajo de Power BI dentro de Microsoft Fabric. Para acceder a una introducción a la serie, consulte el planeamiento de la implementación de Power BI.

Cuando los creadores de contenido colaboran para ofrecer soluciones analíticas importantes para la organización, deben garantizar una entrega oportuna y confiable del contenido a los consumidores. Los equipos técnicos abordan este desafío mediante un proceso denominado DevOps. DevOps permite a los equipos automatizar y escalar procesos mediante la adopción de prácticas que mejoran y aceleran la entrega.

Nota:

Los equipos de datos que abordan los mismos desafíos también podrían practicar DataOps. DataOps se basa en los principios de DevOps, pero DataOps incluye prácticas adicionales específicas de la administración de datos, como el control de calidad de los datos y la gobernanza. En este artículo nos referimos a DevOps, pero tenga en cuenta que los principios subyacentes también se pueden aplicar a DataOps.

Los creadores y consumidores de contenido se benefician de varias ventajas al adoptar prácticas de DevOps para publicar contenido de Power BI. Los siguientes puntos son una visión general de alto nivel de cómo funciona este proceso.

1. Desarrolle contenido y confirme el trabajo en un repositorio remoto: los creadores de contenido desarrollan su solución en su propia máquina. Confirman y guardan su trabajo en un repositorio remoto a intervalos regulares durante el desarrollo. Un repositorio remoto contiene la versión más reciente de la solución y es accesible para todo el equipo de desarrollo.
2. Colabore y administre los cambios de contenido mediante el control de versiones: otros creadores de contenido pueden realizar revisiones en la solución mediante la creación de una rama. Una rama es una copia de un repositorio remoto. Cuando estas revisiones están listas y son aprobadas, la rama se combina con la versión más reciente de la solución. Se realiza un seguimiento de todas las revisiones de la solución. Este proceso se conoce como control de versiones (o control de código fuente).
3. Implemente y promueva contenido mediante canalizaciones: en el escenario de uso de publicación de contenido de autoservicio, el contenido se promueve (o implementa) a través de áreas de trabajo de desarrollo, prueba y producción mediante canalizaciones de implementación de Power BI. Las canalizaciones de implementación de Power BI pueden promover el contenido a áreas de trabajo de Power BI Premium manualmente mediante la interfaz de usuario o mediante programación usando las API de REST. En cambio, la publicación de contenido empresarial (el foco de este escenario de uso) promueve el contenido mediante Azure Pipelines. Azure Pipelines es un servicio de Azure DevOps que automatiza las pruebas, la administración y la implementación de contenido mediante una serie de pasos personalizados y mediante programación. En el escenario de uso de publicación de contenido empresarial, estas canalizaciones también se pueden denominar canalizaciones de integración continua y entrega continua (o CI/CD). Estas canalizaciones integran los cambios automáticamente y con frecuencia, y simplifican la publicación de contenido.

Importante

En ocasiones, este artículo hace referencia a Power BI Premium o a sus suscripciones de capacidad (SKU P). Tenga en cuenta que Microsoft está consolidando actualmente las opciones de compra y retirando las SKU de Power BI Premium por capacidad. Los clientes nuevos y existentes deben considerar la posibilidad de comprar suscripciones de capacidad de Fabric (SKU F) en su lugar.

Para obtener más información, consulte Actualización importante sobre las licencias de Power BI Premium y Preguntas más frecuentes sobre Power BI Premium.

DevOps admite un enfoque consolidado y sistemático para la administración y publicación de contenido. Permite a los creadores de contenido colaborar en las soluciones y garantiza una entrega rápida y confiable del contenido a los consumidores. Al cumplir las prácticas de DevOps, usted se beneficia de flujos de trabajo simplificados, menos errores y experiencias mejoradas para creadores de contenido y consumidores de contenido.

Ha configurado y administrado prácticas de DevOps para la solución de Power BI mediante Azure DevOps. En escenarios empresariales, puede automatizar la publicación de contenido con Azure DevOps y las API de REST de Power BI de tres maneras diferentes.

• API de REST de Power BI con canalizaciones de implementación de Power BI: puede importar contenido a áreas de trabajo de desarrollo y usar canalizaciones de implementación para implementar contenido a través de áreas de trabajo de prueba y producción. Todavía controla la implementación desde Azure DevOps y usa las API de REST de Power BI para administrar las canalizaciones de implementación en lugar de elementos de contenido individuales. Además, se usa el punto de conexión XMLA para implementar metadatos del modelo de datos en lugar de un archivo de Power BI Desktop (.pbix) con Azure DevOps. Estos metadatos permiten realizar un seguimiento de los cambios a nivel de objeto mediante el control de versiones. Aunque es más sólido y fácil de mantener, este enfoque requiere licencias Premium y un esfuerzo moderado de scripting para configurar la importación e implementación del contenido con las API de REST de Power BI. Use este enfoque cuando desee simplificar la administración del ciclo de vida del contenido con canalizaciones de implementación y si tiene una licencia Premium. Los puntos de conexión XMLA y las canalizaciones de implementación de Power BI son características Premium.
• API de REST de Power BI: también puede importar contenido a áreas de trabajo de desarrollo, prueba y producción mediante Azure DevOps y solo las API de REST de Power BI. Este enfoque no requiere licencias Premium, pero implica un alto esfuerzo de scripting y configuración, ya que la implementación se administra fuera de Power BI. Use este enfoque cuando quiera implementar el contenido de Power BI de forma centralizada desde Azure DevOps o cuando no tenga una licencia Premium. Para obtener una comparación visual entre los dos primeros enfoques, consulte el diagrama de flujo de los enfoques de canalización de versión.
• Herramientas de automatización de Power BI con canalizaciones de implementación de Power BI: puede usar la extensión de Azure DevOps deherramientas de automatización de Power BI para administrar las canalizaciones de implementación en lugar de las API de REST de Power BI. Este enfoque es una alternativa a la primera opción, que usa las API de REST de Power BI con canalizaciones de implementación de Power BI. La extensión de herramientas de automatización de Power BI es una herramienta de código abierto. Le ayuda a administrar y publicar contenido desde Azure DevOps sin necesidad de escribir scripts de PowerShell. Use este enfoque cuando quiera administrar canalizaciones de implementación desde Azure DevOps con un esfuerzo mínimo de scripting y si tiene una capacidad Premium.

Este artículo se centra en la primera opción, que usa las API de REST de Power BI con canalizaciones de implementación de Power BI. Describe cómo puede usar Azure DevOps para configurar prácticas de DevOps. También se describe cómo puede usar Azure Repos para los repositorios remotos y automatizar las pruebas, la integración y la entrega de contenido con Azure Pipelines. Azure DevOps no es la única manera de configurar la publicación de contenido empresarial, pero la integración sencilla con Power BI hace que sea una buena opción.

Nota

Este escenario de uso es uno de los escenarios de implementación y administración de contenido. Por motivos de brevedad, algunos aspectos descritos en el tema Escenarios de colaboración y entrega de contenido no se tratan en este artículo. Si quiere obtener una cobertura completa, lea primero esos artículos.

Sugerencia

Microsoft Fabric proporciona otras opciones para la publicación de contenido empresarial mediante la integración de Git de Fabric. La integración de Git le permite vincular un área de trabajo de Fabric a una rama en el repositorio remoto de Azure Repos. El contenido guardado en esa rama se sincronizará automáticamente con el área de trabajo, como si ese contenido se publicara en el área de trabajo. Por el contrario, los creadores de contenido pueden confirmar e insertar cambios del área de trabajo de Fabric en el repositorio remoto.

La integración de Git puede simplificar la colaboración y la publicación de contenido, pero requiere más planeación para usar áreas de trabajo de Fabric y para la estrategia de bifurcación. Para obtener más información sobre cómo configurar y usar la integración de Git de Fabric, consulte Introducción a la integración de Git o Tutorial: Administración de un ciclo de vida completo.

Diagrama del escenario

En el diagrama siguiente se muestra información general de alto nivel de las acciones de usuario más comunes y los componentes de Power BI que se admiten en la publicación de contenido para empresas. El enfoque se centra en el uso de Azure DevOps para administrar y publicar contenido mediante programación a gran escala a través de áreas de trabajo de desarrollo, prueba y producción en el servicio Power BI.

Sugerencia

Le recomendamos que descargue el diagrama de escenariossi desea insertarlo en su presentación, documentación o entrada de blog, o imprimirlo como un póster de pared. Dado que es una imagen de gráficos vectoriales escalables (SVG), puede escalarla o reducirla verticalmente sin pérdida de calidad.

En el diagrama de escenario se muestran las siguientes acciones de usuario, procesos y características.

Elemento	Descripción
	Los creadores de contenido desarrollan modelos de datos mediante Power BI Desktop o el editor tabular y desarrollan informes mediante Power BI Desktop. Los creadores de contenido guardan su trabajo en un repositorio local durante el desarrollo.
	Los creadores de contenido pueden clonar un repositorio remoto para obtener una copia local de ese contenido.
	Algunos orígenes de datos pueden requerir una puerta de enlace de datos local o una puerta de enlace de red virtual para la actualización de datos, como las que residen dentro de una red organizativa privada.
	Los creadores de contenido confirman e insertan periódicamente sus cambios en un repositorio remoto durante el desarrollo mediante un cliente Git, como Visual Studio Code. En este diagrama, el repositorio remoto es Azure Repos.
	Otros creadores de contenido usan Azure Repos para realizar un seguimiento de los cambios con el control de versiones. Colaboran confirmando los cambios en ramas independientes.
	Los cambios en el contenido del repositorio remoto desencadenan Azure Pipelines. Una canalización de validación es la primera canalización que se desencadena. La canalización de validación realiza pruebas automatizadas para validar el contenido antes de que se publique.
	El contenido que pasa la canalización de validación desencadena una canalización de compilación posterior. La canalización de compilación prepara el contenido para la publicación en el servicio Power BI. El proceso hasta este punto se conoce normalmente como integración continua (CI).
	El contenido se publica e implementa mediante canalizaciones de versión. Las canalizaciones de versión usan las API de REST de Power BI o el punto de conexión XMLA del área de trabajo para importar contenido mediante programación al servicio Power BI. La implementación mediante canalizaciones de versión normalmente se conoce como implementación continua (CD).
	Un administrador de versiones controla la implementación en áreas de trabajo de prueba y producción mediante una aprobación de versión de Azure Pipelines. En la publicación de contenido empresarial, un administrador de versiones normalmente planea y coordina la publicación de contenido en entornos de prueba y producción. El administrador coordina y se comunica con los creadores de contenido, las partes interesadas y los usuarios.
	Una canalización de versión publica contenido en el área de trabajo de desarrollo o lleva el contenido de las áreas de trabajo de desarrollo a las áreas de trabajo de prueba, o de las áreas de prueba a las áreas de trabajo de producción.
	Los creadores de contenido que trabajan en un área de trabajo que tiene el modo de licencia de capacidad de Fabric pueden usar la integración de Git. Con la integración de Git, los creadores de contenido pueden trabajar en un área de trabajo privada durante el desarrollo. El creador de contenido sincroniza una rama remota (normalmente una rama de características específica o una rama de errores) de Azure Repos a su área de trabajo privada. Los cambios de contenido se sincronizan entre la rama remota en Azure Repos y el área de trabajo. En este escenario, los creadores de contenido no necesitan usar Azure Pipelines para publicar contenido. Los creadores de contenido también pueden confirmar e insertar periódicamente cambios desde el área de trabajo tras la publicación. Cuando lo tengan todo preparado, los creadores de contenido pueden realizar una solicitud de cambios (PR) para combinar sus cambios en la rama principal.
	Al usar la integración de Git, el área de trabajo de desarrollo se sincroniza con la rama principal para obtener las versiones más recientes del contenido. Este contenido incluye todos los cambios de las solicitudes de incorporación de cambios que un administrador de versiones revisa, aprueba y combina.
	Las áreas de trabajo se establecen en capacidad de Fabric, capacidad Premium, Premium por usuario o modo de licenciaInsertado, para permitir el uso de canalizaciones de implementación de Power BI y el punto de conexión de lectura y escritura XMLA.
	Un administrador de canalizaciones de implementación configura la canalización de implementación de Power BI con tres fases: desarrollo, prueba y producción. Cada fase se alinea con un área de trabajo independiente en el servicio Power BI. Las opciones de implementación y el acceso se configuran para la canalización de implementación.
	El área de trabajo de desarrollo contiene las versiones más recientes del contenido, incluidos todos los cambios aprobados y combinados. Una vez aprobada, una canalización de versión implementa contenido del desarrollo en el área de trabajo de prueba.
	Los revisores del área de trabajo de prueba realizan pruebas y garantizan la calidad del contenido. Una vez aprobada, una canalización de versión implementa contenido de la prueba en el área de trabajo de producción. Al usar la integración de Git con canalizaciones de implementación, el área de trabajo de prueba no se sincroniza con ninguna rama.
	Una vez completada la implementación de la canalización de implementación, los creadores de contenido pueden realizar manualmente actividades posteriores a la implementación. Las actividades pueden incluir la configuración de la actualización de datos programada o la actualización de una aplicación de Power BI para el área de trabajo de producción. Al usar la integración de Git con canalizaciones de implementación, el área de trabajo de producción no se sincroniza con ninguna rama.
	Los consumidores de contenido acceden al contenido mediante el área de trabajo de producción o una aplicación de Power BI.

Sugerencia

Se recomienda revisar también los escenarios de uso depublicación de contenido de autoservicio y administración avanzada de modelos de datos. El escenario de uso de publicación de contenido empresarial se basa en los conceptos que presentan estos escenarios.

Puntos clave

A continuación, se muestran algunos puntos clave para destacar sobre el escenario de publicación de contenido empresarial.

Control de versiones

El seguimiento de los cambios durante el ciclo de vida del contenido es importante para garantizar una entrega estable y coherente del contenido a los consumidores. En este escenario de uso, los creadores de contenido y los propietarios administran los cambios de contenido en un repositorio remoto mediante el control de versiones. El control de versiones es la práctica de administrar los cambios en archivos o código en un repositorio central. Esta práctica permite una mejor colaboración y una administración eficaz del historial de versiones. El control de versiones tiene ventajas para los creadores de contenido, incluida la capacidad de revertir o combinar cambios.

Los creadores de contenido suelen desarrollar modelos de datos en Tabular Editor para facilitar el control de versiones. A diferencia de un modelo de datos que desarrolle en Power BI Desktop, un modelo de datos desarrollado en Tabular Editor se guarda en formato de metadatos legibles por los usuarios. Este formato habilita el control de versiones a nivel de objeto del modelo de datos. Debe usar el control de versiones a nivel de objeto al colaborar con varios usuarios en el mismo modelo de datos. Para obtener más información, consulte los escenarios de uso de administración avanzada de modelos de datos. No es posible ver los cambios realizados en un archivo Power BI Desktop (.pbix), como la definición del informe o el modelo de datos. Por ejemplo, no puede realizar un seguimiento de los cambios en una página de informe, como los objetos visuales usados, sus posiciones y sus asignaciones de campos o formato.

Los creadores de contenido almacenan archivos de metadatos del modelo de datos y archivos .pbix en un repositorio remoto central, como Azure Repos. Estos archivos son mantenidos por un propietario técnico. Mientras un creador de contenido desarrolla una solución, un propietario técnico es responsable de administrar la solución y revisar los cambios, y combinarlos en una única solución. Azure Repos proporciona opciones sofisticadas para realizar un seguimiento y administrar los cambios. Este enfoque difiere del enfoque descrito en el escenario de uso de publicación de contenido de autoservicio, donde el creador usa el almacenamiento de OneDrive con el seguimiento de versiones. Mantener un repositorio bien organizado y documentado es esencial porque es la base de todo el contenido y la colaboración.

Estas son algunas consideraciones clave que le ayudarán a configurar un repositorio remoto para el control de versiones.

• Ámbito: defina claramente el ámbito del repositorio. Lo ideal es que el ámbito del repositorio sea idéntico al ámbito de las áreas de trabajo y las aplicaciones de bajada que se usan para entregar contenido a los consumidores.
• Acceso: debe configurar el acceso al repositorio mediante un modelo de permisos similar al que ha configurado para los permisos de canalización de implementación y los roles de área de trabajo. Los creadores de contenido necesitan acceder al repositorio.
• Documentación: agregue archivos de texto al repositorio para documentar su propósito, propiedad, acceso y procesos definidos. Por ejemplo, la documentación puede describir cómo se deben almacenar provisionalmente y confirmar los cambios.
• Herramientas: para confirmar e insertar cambios en un repositorio remoto, los creadores de contenido necesitan un cliente Git como Visual Studio o Visual Studio Code. Git es un sistema de control de versiones distribuido que realiza un seguimiento de los cambios en los archivos. Para obtener información sobre los conceptos básicos de Git, consulte ¿Qué es Git?.

Nota

Considere la posibilidad de usar el Almacenamiento de archivos de gran tamaño de Git (LFS) si tiene previsto confirmar archivos de Power BI Desktop (.pbix). Git LFS proporciona opciones avanzadas para administrar archivos en los que los cambios no son visibles (archivos indiffables), como un archivo .pbix. Por ejemplo, puede usar el bloqueo de archivos para evitar cambios simultáneos en un informe de Power BI durante el desarrollo. Sin embargo, Git LFS tiene su propio cliente y configuración.

Colaboración con Azure DevOps

A medida que una solución aumenta en el ámbito y la complejidad, podría ser necesario que varios creadores de contenido y propietarios trabajen en colaboración. Los creadores y propietarios de contenido se comunican y colaboran en un centro organizado mediante Azure DevOps.

Para colaborar y comunicarse en Azure DevOps, use los servicios auxiliares.

• Azure Boards: los propietarios de contenido usan paneles para realizar un seguimiento de los elementos de trabajo. Los elementos de trabajo se asignan a un único desarrollador del equipo (y describen problemas, errores o características de la solución) y a las partes interesadas correspondientes.
• Wiki de Azure: los creadores de contenido comparten información con su equipo para comprender y contribuir a la solución.
• Azure Repos: los creadores de contenido realizan un seguimiento de los cambios en el repositorio remoto y los combinan en una única solución.
• Azure Pipelines: los propietarios de canalizaciones configuran la lógica de programación para implementar la solución, ya sea automáticamente o a petición.

Diagrama de flujo de colaboración

En el diagrama siguiente se muestra información general de alto nivel de un ejemplo sobre cómo Azure DevOps permite la colaboración en el escenario de uso de publicación de contenido empresarial. El enfoque de este diagrama se centra en el uso de Azure DevOps para crear un proceso de publicación de contenido estructurado y documentado.

En el diagrama se muestran las siguientes acciones de usuario, procesos y características.

Elemento	Descripción
	Un creador de contenido crea una nueva rama de corta duración mediante la clonación de la rama principal, que contiene la versión más reciente del contenido. La nueva rama se conoce a menudo como rama de características, ya que se usa para desarrollar una característica específica o corregir un problema específico.
	El creador de contenido confirma sus cambios en un repositorio local durante el desarrollo.
	El creador de contenido vincula sus cambios a los elementos de trabajo que se administran en Azure Boards. Los elementos de trabajo describen desarrollos, mejoras o correcciones de errores específicos en el ámbito de su rama.
	El creador de contenido confirma regularmente los cambios. Cuando esté listo, el creador de contenido publica su rama en el repositorio remoto.
	Para probar sus cambios, el creador de contenido implementa su solución en un área de trabajo aislada para su desarrollo (no se muestra en este diagrama). El creador de contenido también puede sincronizar la rama de características con el área de trabajo mediante la integración de Git de Fabric.
	Los creadores de contenido y los propietarios de contenido documentan la solución y sus procesos en una Wiki de Azure, que está disponible para todo el equipo de desarrollo.
	Cuando está listo, el creador de contenido abre una solicitud de cambios para combinar la rama de características con la rama principal.
	Un propietario técnico es responsable de revisar la solicitud de incorporación de cambios y combinar los cambios. Cuando se aprueba la solicitud de cambios, se combina la rama de características con la rama principal.
	Una combinación correcta desencadena la implementación de la solución en un área de trabajo de desarrollo mediante una canalización de Azure Pipeline (no se muestra en este diagrama). Al usar la integración de Git de Fabric, la rama principal se sincroniza con el área de trabajo de desarrollo.
	El administrador de versiones realiza una revisión final y aprueba la solución. Esta aprobación de versión impide que la solución se publique antes de que esté lista. En la publicación de contenido empresarial, un administrador de versiones normalmente planea y coordina la publicación de contenido en áreas de trabajo de prueba y producción. El administrador coordina y se comunica con los creadores de contenido, las partes interesadas y los usuarios.
	Cuando el administrador de versiones aprueba la versión, Azure Pipelines prepara automáticamente la solución para la implementación. Como alternativa, una canalización de Azure Pipeline también puede desencadenar una canalización de implementación para promover el contenido entre áreas de trabajo.
	Los usuarios prueban y validan el contenido del área de trabajo de prueba. Al usar la integración de Git con Azure Pipelines para la implementación, el área de trabajo de prueba no se sincroniza con ninguna rama.
	Después de que los usuarios acepten y validen los cambios, el administrador de versiones realiza una revisión final y una aprobación de la solución para implementarla en el área de trabajo de producción.
	Los usuarios ven el contenido que se publica en el área de trabajo de producción. Al usar la integración de Git con Azure Pipelines para la implementación, el área de trabajo de producción no se sincroniza con ninguna rama.

Para elaborar, los creadores de contenido logran la colaboración mediante una estrategia de ramificación. Una estrategia de bifurcación es la forma en que los creadores de contenido crean, usan y combinan ramas para realizar y administrar de forma eficaz los cambios de contenido. Los creadores de contenido individuales trabajan de forma aislada en su repositorio local. Cuando están listos, combinan sus cambios como una única solución en el repositorio remoto. Los creadores de contenido deben limitar su trabajo a las ramas mediante la vinculación a elementos de trabajo para desarrollos, mejoras o correcciones de errores específicos. Cada creador de contenido crea su propia rama del repositorio remoto para su ámbito de trabajo. El trabajo realizado en su solución local se confirma e inserta en una versión de la rama en el repositorio remoto con un mensaje de confirmación. Un mensaje de confirmación describe los cambios realizados en esa confirmación.

Para combinar los cambios, un creador de contenido abre una solicitud de incorporación de cambios. Una solicitud de incorporación de cambios es un envío para la revisión del mismo nivel que puede llevar a la combinación del trabajo realizado en una única solución. La combinación puede dar lugar a conflictos, que se deben resolver antes de que se pueda combinar la rama. Las revisiones de solicitudes de incorporación de cambios son importantes para garantizar que los creadores cumplan los estándares y prácticas de la organización para el desarrollo, la calidad y el cumplimiento.

Recomendaciones de colaboración

Se recomienda definir un proceso estructurado para la colaboración de los creadores de contenido. Asegúrese de determinar lo siguiente:

• Cómo se define el ámbito de trabajo y cómo se crean, nombran y usan las ramas.
• Cómo los autores agrupan los cambios y los describen con mensajes de confirmación.
• Quién es responsable de revisar y aprobar las solicitudes de incorporación de cambios.
• Cómo se resuelven los conflictos de combinación.
• Cómo se combinan los cambios realizados en distintas ramas en una sola rama.
• Cómo se prueba el contenido y quién realiza las pruebas antes de implementar el contenido.
• Cómo y cuándo se implementan los cambios en áreas de trabajo de desarrollo, prueba y producción.
• Cómo y cuándo se deben revertir los cambios o versiones implementados en la solución.

Importante

El valor proporcionado por DevOps es directamente proporcional al cumplimiento de los procesos que definen su uso.

Una colaboración correcta depende de un proceso bien definido. Es importante describir y documentar claramente el flujo de trabajo de desarrollo de un extremo a otro. Asegúrese de que las estrategias y los procesos seleccionados se alineen con las prácticas existentes en el equipo y, si no es así, cómo administrará el cambio. Además, asegúrese de que los procesos sean claros y se comuniquen a todos los miembros del equipo y a las partes interesadas. Asegúrese de que los miembros del equipo y las partes interesadas que no están familiarizadas con los procesos se entrenan en cómo adoptarlos y que aprecian el valor de la adopción correcta de DevOps.

API de REST de Power BI

La lógica de programación se desarrolla para importar e implementar contenido desde Azure DevOps mediante las API de REST de Power BI. Los archivos de Power BI (.pbix) se importan en un área de trabajo mediante una operación de importación. Use una operación de canalización para implementar parte del contenido o todo el contenido en áreas de trabajo de prueba o producción mediante canalizaciones de implementación de Power BI. La lógica de programación se define en Azure Pipelines.

Se recomienda usar una entidad de servicio para llamar a las API de REST de Power BI en las canalizaciones. Una entidad de servicio está pensada para actividades desatendidas y automatizadas, y no se basa en las credenciales de usuario. Sin embargo, algunas actividades y elementos no son compatibles con las API de REST de Power BI o cuando se usa una entidad de servicio, como los flujos de datos.

Cuando use una entidad de servicio, asegúrese de administrar cuidadosamente los permisos. Tu objetivo debe ser seguir el principio de privilegios mínimos. Debe establecer permisos suficientes para la entidad de servicio sin permisos de aprovisionamiento excesivo. Use Azure Key Vault u otro servicio que almacene de forma segura los secretos y las credenciales de la entidad de servicio.

Precaución

Si tiene un modelo de datos que se guarda como un formato de metadatos en lenguaje natural, no se puede publicar mediante las API de REST de Power BI. En su lugar, debe publicarlo mediante el punto de conexión XMLA. Puede publicar archivos de metadatos mediante herramientas de terceros, como la interfaz de la línea de comandos (CLI) del Editor tabular. También puede publicar archivos de metadatos mediante programación usando su propio desarrollo personalizado de .NET. El desarrollo de una solución personalizada requiere más esfuerzo, ya que debe usar la extensión Modelo de objetos tabulares (TOM) de Microsoft de las bibliotecas cliente de Objetos de administración de análisis (AMO).

Azure Pipelines

Azure Pipelines automatiza mediante programación las pruebas, la administración y la implementación de contenido. Cuando se ejecuta una canalización, los pasos de la canalización se ejecutan automáticamente. Los propietarios de las canalizaciones pueden personalizar sus desencadenadores, pasos y funcionalidad para satisfacer las necesidades de implementación. Por lo tanto, el número y los tipos de canalizaciones varían en función de los requisitos de la solución. Por ejemplo, una canalización de Azure podría ejecutar pruebas automatizadas o modificar los parámetros del modelo de datos antes de una implementación.

Hay tres tipos de canalizaciones de Azure que puede configurar para probar, administrar e implementar la solución de Power BI:

• Canalizaciones de validación.
• Canalizaciones de compilación.
• Canalizaciones de versión.

Nota

No es necesario tener las tres canalizaciones en la solución de publicación. En función del flujo de trabajo y las necesidades, podría configurar una o más de las variantes de las canalizaciones descritas en este artículo para automatizar la publicación de contenido. Esta capacidad para personalizar las canalizaciones es una ventaja de Azure Pipelines sobre las canalizaciones de implementación de Power BI integradas. Por ejemplo, no es necesario tener una canalización de validación; puede usar únicamente canalizaciones de compilación y versión.

Canalizaciones de validación

Las canalizaciones de validación realizan comprobaciones de calidad básicas de los modelos de datos antes de que se publiquen en un área de trabajo de desarrollo. Normalmente, los cambios en una rama del repositorio remoto desencadenan la canalización para validar esos cambios con pruebas automatizadas.

Algunos ejemplos de pruebas automatizadas incluyen examinar el modelo de datos para detectar infracciones de reglas de procedimientos recomendados mediante el Analizador de procedimientos recomendados (BPA) o mediante la ejecución de consultas DAX en un modelo semántico publicado. Los resultados de estas pruebas se almacenan en el repositorio remoto con fines de documentación y auditoría. Los modelos de datos que no pasan la validación no deben publicarse. En su lugar, la canalización debe notificar a los creadores de contenido los problemas.

Canalizaciones de compilación

Las canalizaciones de compilación preparan los modelos de datos para su publicación en el servicio Power BI. Estas canalizaciones combinan los metadatos del modelo serializados en un único archivo publicado más adelante por una canalización de versión (que se describe en el diagrama de canalizaciones de versión). Una canalización de compilación también puede realizar otros cambios en los metadatos, como modificar valores de parámetro. Las canalizaciones de compilación generan artefactos de implementación que constan de metadatos del modelo de datos (para modelos de datos) y archivos de Power BI Desktop (.pbix) que están listos para su publicación en el servicio Power BI.

Canalizaciones de versión

Las canalizaciones de versión publican o implementan contenido. Normalmente, una solución de publicación incluye varias canalizaciones de versión, en función del entorno de destino.

• Canalización de versión de desarrollo: esta primera canalización se desencadena automáticamente. Publica contenido en un área de trabajo de desarrollo después de que las canalizaciones de compilación y validación se realicen correctamente.
• Canalizaciones de versión de prueba y producción: estas canalizaciones no se desencadenan automáticamente. En su lugar, se desencadenan a petición o cuando se aprueban. Las canalizaciones de versión de prueba y producción implementan contenido en un área de trabajo de prueba o producción, respectivamente, después de la aprobación de la versión. Las aprobaciones de versión garantizan que el contenido no se implemente automáticamente en una fase de prueba o producción antes de que esté listo. Los administradores de versiones proporcionan estas aprobaciones, que son responsables de planear y coordinar la publicación de contenido en entornos de prueba y producción.

Hay dos enfoques diferentes para publicar contenido con canalizaciones de prueba y versión. Promover contenido mediante una canalización de implementación de Power BI o publicar contenido en el servicio Power BI desde Azure DevOps.

El siguiente diagrama describe el primer enfoque. En este enfoque, las canalizaciones de versión organizan la implementación en áreas de trabajo de prueba y producción mediante canalizaciones de implementación de Power BI. El contenido se promueve a través de áreas de trabajo de desarrollo, prueba y producción en Power BI. Aunque este enfoque es más sólido y más sencillo de mantener, requiere licencias Premium.

En el diagrama se muestran las siguientes acciones de usuario, procesos y características del primer enfoque.

Elemento	Descripción
	En el primer enfoque, las canalizaciones de versión publican contenido mediante el punto de conexión XMLA y las API de REST de Power BI con canalizaciones de implementación de Power BI. El contenido se publica y después se promueve a través de áreas de trabajo de desarrollo, prueba y producción. Las canalizaciones de implementación de Power BI y el punto de conexión de lectura y escritura de XMLA son características Premium.
	Ya sea una combinación de rama correcta o la finalización de una canalización ascendente desencadena la canalización de compilación. A continuación, la canalización de compilación prepara el contenido para la publicación y desencadena la canalización de versión de desarrollo.
	La canalización de versión de desarrollo publica contenido en el área de trabajo de desarrollo mediante el punto de conexión XMLA (para metadatos del modelo de datos) o las API de REST de Power BI (para archivos de Power BI Desktop, que pueden contener modelos de datos e informes). La canalización de desarrollo usa la interfaz de línea de comandos (CLI) del Editor tabular para implementar metadatos del modelo de datos mediante el punto de conexión XMLA.
	Una aprobación de versión o un desencadenador a petición activa la canalización de versión de prueba.
	La canalización de versión de prueba implementa contenido mediante las operaciones de implementación de la API de REST de Power BI, que ejecutan la canalización de implementación de Power BI.
	La canalización de implementación de Power BI promueve el contenido del área de trabajo de desarrollo al área de trabajo de prueba. Después de la implementación, la canalización de versión realiza actividades posteriores a la implementación mediante las API de REST de Power BI (no se muestran en el diagrama).
	Una aprobación de versión o un desencadenador a petición activa la canalización de versión de producción.
	La canalización de versión de producción implementa contenido mediante las operaciones de implementación de la API de REST de Power BI, que ejecutan la canalización de implementación de Power BI.
	La canalización de implementación de Power BI promueve el contenido del área de trabajo de prueba al área de trabajo de producción. Después de la implementación, la canalización de versión realiza actividades posteriores a la implementación mediante las API de REST de Power BI (no se muestran en el diagrama).

El siguiente diagrama describe el segundo enfoque. Este enfoque no usa canalizaciones de implementación. En su lugar, usa canalizaciones de versión para publicar contenido en áreas de trabajo de prueba y producción desde Azure DevOps. En concreto, este segundo enfoque no requiere licencias Premium al publicar únicamente archivos de Power BI Desktop con las API de REST de Power BI. Implica más esfuerzo de configuración y complejidad, ya que debe administrar la implementación fuera de Power BI. Los equipos de desarrollo que ya usan DevOps para soluciones de datos fuera de Power BI podrían estar más familiarizados con este enfoque. Los equipos de desarrollo que usan este enfoque pueden consolidar la implementación de soluciones de datos en Azure DevOps.

En el diagrama se muestran las siguientes acciones de usuario, procesos y características del segundo enfoque.

Elemento	Descripción
	En el segundo enfoque, las canalizaciones de versión publican contenido mediante el punto de conexión XMLA y las API de REST de Power BI únicamente. El contenido se publica en áreas de trabajo de desarrollo, prueba y producción.
	Ya sea una combinación de rama correcta o la finalización de una canalización ascendente desencadena la canalización de compilación. A continuación, la canalización de compilación prepara el contenido para la publicación y desencadena la canalización de versión de desarrollo.
	La canalización de versión de desarrollo publica contenido en el área de trabajo de desarrollo mediante el punto de conexión XMLA (para metadatos del modelo de datos) o las API de REST de Power BI (para archivos de Power BI Desktop, que pueden contener modelos de datos e informes). La canalización de desarrollo usa la interfaz de línea de comandos (CLI) del Editor tabular para implementar metadatos del modelo de datos mediante el punto de conexión XMLA.
	Una aprobación de versión o un desencadenador a petición activa la canalización de versión de prueba.
	La canalización de versión de desarrollo publica contenido en el área de trabajo de prueba mediante el punto de conexión XMLA (para metadatos del modelo de datos) o las API de REST de Power BI (para archivos de Power BI Desktop, que pueden contener modelos de datos e informes). La canalización de desarrollo usa la interfaz de línea de comandos (CLI) del Editor tabular para implementar metadatos del modelo de datos mediante el punto de conexión XMLA. Después de la implementación, la canalización de versión realiza actividades posteriores a la implementación mediante las API de REST de Power BI (no se muestran en el diagrama).
	Una aprobación de versión o un desencadenador a petición activa la canalización de versión de producción.
	La canalización de versión de desarrollo publica contenido en el área de trabajo de producción mediante el punto de conexión XMLA (para metadatos del modelo de datos) o las API de REST de Power BI (para archivos de Power BI Desktop, que pueden contener modelos de datos e informes). La canalización de desarrollo usa la interfaz de línea de comandos (CLI) del Editor tabular para implementar metadatos del modelo de datos mediante el punto de conexión XMLA. Después de la implementación, la canalización de versión realiza actividades posteriores a la implementación mediante las API de REST de Power BI (no se muestran en el diagrama).

Las canalizaciones de versión deben administrar las actividades posteriores a la implementación. Estas actividades pueden incluir la configuración de credenciales del modelo semántico o la actualización de la aplicación de Power BI para áreas de trabajo de prueba y producción. Se recomienda configurar notificaciones para informar a los usuarios pertinentes sobre las actividades de implementación.

Sugerencia

El uso de un repositorio para el control de versiones permite a los creadores de contenido crear un proceso de reversión. El proceso de reversión puede revertir la última implementación restaurando la versión anterior. Considere la posibilidad de crear un conjunto independiente de canalizaciones de Azure que pueda desencadenar para revertir los cambios de producción. Piense detenidamente qué procesos y aprobaciones son necesarios para iniciar una reversión. Asegúrese de que estos procesos estén documentados.

Canalizaciones de implementación de Power BI

Una canalización de implementación de Power BI consta de tres fases: desarrollo, prueba y producción. Asigne una única área de trabajo de Power BI a cada fase de la canalización de implementación. Cuando se produce una implementación, la canalización de implementación promueve elementos de Power BI de un área de trabajo a otra.

Una canalización de versión de Azure Pipelines usa las API de REST de Power BI para implementar contenido mediante una canalización de implementación de Power BI. Se requiere acceso tanto al área de trabajo como a la canalización de implementación para los usuarios que realizan una implementación. Se recomienda planear el acceso a la canalización de implementación para que los usuarios de la canalización puedan ver el historial de implementación y comparar el contenido.

Sugerencia

Al separar las áreas de trabajo de datos de las áreas de trabajo de informes, considere la posibilidad de usar Azure Pipelines para organizar la publicación de contenido con varias canalizaciones de implementación de Power BI. Los modelos semánticos se implementan primero y, después, se actualizan. Por último, se implementan los informes. Este enfoque le ayuda a simplificar la implementación.

Licencias Premium

Las canalizaciones de implementación de Power BI y el punto de conexión de lectura y escritura de XMLA son características Premium. Estas características están disponibles con una capacidad de Power BI Premium y Power BI Premium por usuario (PPU).

PPU es una manera rentable de administrar la publicación de contenido empresarial para áreas de trabajo de desarrollo y prueba, que normalmente tiene pocos usuarios. Este enfoque tiene la ventaja adicional de aislar las cargas de trabajo de desarrollo y prueba de las cargas de trabajo de producción.

Nota

Aun así puede configurar la publicación de contenido empresarial sin una licencia Premium, como se describe en el segundo enfoque de la sección de canalización de versión. En el segundo enfoque, se usa Azure Pipelines para administrar la implementación de archivos de Power BI Desktop en áreas de trabajo de desarrollo, prueba y producción. Sin embargo, no puede implementar metadatos del modelo mediante el punto de conexión XMLA porque no es posible publicar un modelo semántico de formato de metadatos con las API de REST de Power BI. Además, no es posible promover el contenido a través de entornos con canalizaciones de implementación sin una licencia Premium.

Instalación de la puerta de enlace

Normalmente, se requiere una puerta de enlace de datos al acceder a orígenes de datos que residen en la red organizativa privada o en una red virtual. Los dos propósitos de una puerta de enlace son actualizar los datos importados y ver un informe que consulta una conexión dinámica o un modelo semántico de DirectQuery (no se muestra en el diagrama de escenarios).

Al trabajar con varios entornos, es habitual configurar conexiones de desarrollo, prueba y producción en diferentes sistemas de origen. En este caso, use reglas de origen de datos y reglas de parámetros para administrar valores que difieren entre entornos. Puede usar Azure Pipelines para administrar puertas de enlace mediante las operaciones de puerta de enlace de las API de REST de Power BI.

Nota

Se recomienda encarecidamente una puerta de enlace de datos centralizada en modo estándar por sobre las puertas de enlace en modo personal. En el modo estándar la puerta de enlace de datos admite conexiones dinámicas y operaciones de DirectQuery (además de las operaciones de actualización de datos programadas).

Supervisión del sistema

El registro de actividad registra los eventos que se producen en el servicio Power BI. Los administradores de Power BI pueden usar el registro de actividad para auditar las actividades de implementación.

Puede usar las API de análisis de metadatos de Power BI para crear un inventario de inquilinos. Los resultados de la API son útiles para comprobar qué elementos se han implementado en cada área de trabajo, comprobar el linaje y validar la configuración de seguridad.

También existe un registro de auditoría en Azure DevOps, que está fuera del servicio Power BI. Los administradores de Azure DevOps pueden usar el registro de auditoría para revisar las actividades en repositorios remotos y canalizaciones.

Contenido relacionado

Para ver otros escenarios útiles que le ayuden con las decisiones de implementación de Power BI, consulte el artículo Escenarios de uso de Power BI.