Planeamiento de la implementación de Power BI: desarrollo del contenido y administración de los cambios

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 experiencia de Power BI en Microsoft Fabric. Para obtener una introducción a la serie, consulte el planeamiento de la implementación de Power BI.

Este artículo le ayuda a desarrollar contenidos y administrar los cambios como parte de la administración del ciclo de vida del contenido. Se dirige principalmente a:

• Equipos del centro de excelencia (COE) y BI: los equipos que son responsables de supervisar Power BI en la organización. Estos equipos incluyen responsables de la toma de decisiones que deciden cómo administrar el ciclo de vida del contenido de Power BI. Estos equipos también pueden incluir roles como administradores de versiones, que administran el ciclo de vida de las versiones de contenidos, o los ingenieros que crean y administran los componentes necesarios para usar y respaldar eficazmente la administración del ciclo de vida.
• Creadores de contenido y propietarios de contenido: usuarios que crean contenido que quieren publicar en el portal de Fabric para compartirlos con otros usuarios. Estas personas son responsables de administrar el ciclo de vida del contenido de Power BI que crean.

La administración del ciclo de vida consta de los procesos y prácticas que se usan para controlar el contenido desde su creación hasta su retirada final. En la primera fase de la administración del ciclo de vida, usted planifica y diseña el contenido, lo que implica planificar la solución y tomar decisiones clave que afectan a su enfoque de la administración del ciclo de vida. En la segunda fase, desarrolla contenido y administra los cambios.

La administración de cambios de contenido durante su ciclo de vida es importante para garantizar una colaboración eficaz entre creadores de contenido y entrega estable y coherente de contenido a los consumidores.

En la imagen siguiente se muestra el ciclo de vida del contenido de Power BI, en el que se resalta la fase dos, donde se desarrolla el contenido y se administran los cambios.

Nota:

Para obtener información general sobre la administración del ciclo de vida de contenido, consulte el primer artículo de esta serie.

Sugerencia

Este artículo se centra en las decisiones y consideraciones clave para ayudarle a desarrollar contenido y administrar los cambios a lo largo de su ciclo de vida. Para más instrucciones sobre cómo desarrollar contenido y administrar cambios, consulte:

• ¿Qué es la administración del ciclo de vida en Microsoft Fabric?: este artículo proporciona una introducción técnica y tutorial a la integración del Git de Fabric y a las canalizaciones de implementación.
• Procedimientos recomendados para la administración del ciclo de vida: este artículo contiene recomendaciones prácticas y orientación para usar las características de administración del ciclo de vida de Fabric y Power BI para desarrollar contenidos y administrar cambios.
• Integración de Power BI Desktop OneDrive y SharePoint: este artículo contiene una introducción a las opciones para usar y almacenar archivos guardados en OneDrive para el trabajo y la escuela o SharePoint cuando se realiza el control de versiones con archivos .pbix.
• Introducción a Git en Azure Repos: esta serie de artículos contiene consejos prácticos, tutoriales y orientación para realizar el control de código fuente usando un repositorio de Git en Azure Repos.

Los creadores y propietarios de contenidos deben administrar los cambios de contenido usando 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 facilita la colaboración y la administración de contenido más eficaces.

Otras ventajas del control de versiones incluyen la capacidad de:

• Combinar los cambios de varios creadores de contenido y controlar los conflictos de combinación.
• Identificar qué contenido cambió y qué cambió en ese contenido.
• Vincular cambios de contenido a elementos de trabajo específicos.
• Agrupar los cambios en distintas versiones con historial de versiones.
• Revertir cambios o versiones completas del contenido.

Sugerencia

Se recomienda usar el control de versiones para todo el contenido que cree, siempre que sea posible. El uso del control de versiones tiene ventajas significativas tanto para los creadores de contenido como para los consumidores y reduce el riesgo de interrupción debido a la pérdida de archivos o a la incapacidad de revertir los cambios.

El primer paso para configurar el control de versiones es decidir cómo desarrollar contenido.

Decidir cómo desarrollar el contenido

Dependiendo de cómo cree contenido, tomará diferentes decisiones sobre cómo administrarlo. Por ejemplo, para los modelos semánticos y los informes de Power BI, un archivo de Power BI Desktop (.pbix) tiene menos opciones para el control de versiones en comparación con el formato Proyecto de Power BI Desktop (.pbip). Esto se debe a que un archivo .pbix es un formato binario, mientras que el formato .pbip contiene contenido y metadatos legibles para personas basados en texto. Tener contenido y metadatos legibles para personas permite realizar un seguimiento más sencillo de los cambios de modelo e informe mediante control de código fuente. El control de origen es cuando se visualizan y administran los cambios dentro del contenido en su código y metadatos.

Sugerencia

Al desarrollar modelos semánticos e informes mediante Power BI Desktop, se recomienda usar archivos .pbip en lugar de archivos .pbix. Al desarrollar modelos semánticos mediante herramientas XMLA, se recomienda usar el formato de Lenguaje de definición de modelos tabulares (TMDL), en lugar de archivos .bim.

Los formatos .pbip y TMDL admiten un seguimiento y combinación más sencillos de los cambios de nivel de objeto. Esto significa que puede ver y administrar los cambios en objetos individuales, como las medidas o tablas DAX.

Power BI Desktop

Puede usar Power BI Desktop para crear modelos o informes semánticos, que puede guardar como archivos .pbix o .pbip. Hay archivos de contenido personalizados adicionales que también puede usar al usar Power BI Desktop. Al usar Power BI Desktop para crear contenido, algunas decisiones clave que debe tomar incluyen:

• El formato de archivo que se va a usar: puede guardar contenido como archivos .pbix o .pbip. Por ejemplo, la integración de Git requiere que use archivos .pbip, los creadores de autoservicio pueden encontrar archivos .pbix más sencillos para administrar y mantener en Teams, SharePoint o OneDrive.
• Administración de contenido personalizado: puede agregar temas, objetos visuales personalizados o imágenes a archivos de Power BI Desktop, lo que puede requerir consideraciones distintas para la administración del ciclo de vida. Por ejemplo, cuando los creadores de contenido hacen sus propios objetos visuales personalizados, deben guardar y administrar la definición del objeto visual en un archivo independiente.
• Administración de características en versión preliminar: puede participar en la versión preliminar de características o configuraciones en Power BI Desktop, que modifica el contenido y cómo lo usará. Por ejemplo, puede realizar pasos adicionales para validar el contenido que usa características en versión preliminar.

Creación web

Algunos contenidos, como los flujos de datos, los paneles y los cuadros de mando, solo pueden crearse en el portal de Fabric. También puede crear o modificar algunos contenidos (como modelos semánticos, informes e informes paginados) tanto en el portal de Fabric como usando herramientas locales. Al crear contenido mediante la creación web, algunas decisiones clave que debe tomar incluyen:

• Administración de cambios: puede realizar cambios en muchos tipos de elementos mediante la creación web, pero estos cambios se pueden guardar al instante, sobrescribiendo versiones anteriores. Por ejemplo, si colabora con otros usuarios, es posible que quiera evitar la creación web en elementos compartidos, trabajando en su lugar en su propia copia.
• Cómo recuperar copias de seguridad de contenido: puede crear contenido como informes o modelos semánticos mediante la creación web, pero estos elementos no se pueden descargar en archivos .pbix locales. Por ejemplo, puede optar por realizar una copia de seguridad de este contenido recuperando y almacenando sus metadatos.

Sugerencia

Al desarrollar flujos de datos y cuadros de mandos, se recomienda recuperar las definiciones de elementos para administrar los cambios y almacenar una copia de seguridad. Puede automatizar el flujo de datos y la recuperación de cuadros de mandos mediante las API de REST de Fabric. En concreto, puede usar los puntos de conexión Obtener flujo de datos y Obtener cuadros de mando, respectivamente.

Precaución

Algunos contenidos, como los paneles de control, no tienen la opción de recuperar una definición. Para este contenido, no puede realizar un seguimiento de los cambios ni recuperar fácilmente una copia de seguridad.

Otras herramientas

Puede usar otras herramientas para crear o administrar determinados tipos de contenido. Estas herramientas pueden proporcionar ventajas adicionales, adaptarse mejor al flujo de trabajo o ser necesarias para administrar características o tipos de contenido específicos. Puede usar otras herramientas de Microsoft o herramientas de terceros para crear y administrar contenido. Otras herramientas que puede usar para crear o administrar contenido son las siguientes.

• Visual Studio o Visual Studio Code: un entorno de desarrollo integrado para que los desarrolladores creen y administren modelos semánticos o cuadernos de Fabric. Con Visual Studio y Visual Studio Code, los desarrolladores también pueden realizar la administración del control de código fuente (SCM) confirmando e insertando cambios locales en un repositorio remoto.
• Editor tabular: una herramienta de terceros para desarrollar y administrar modelos semánticos.
• Excel: herramienta cliente para tablas dinámicas y tablas conectadas dinámicas que funcionan con un modelo semántico.
• Power BI Report Builder: una aplicación de escritorio para crear archivos de informes paginados (.rdl).

Al crear contenido mediante otras herramientas, algunas decisiones clave que debe tomar incluyen:

• Administración de licencias: otras herramientas pueden requerir licencias adicionales que debe administrar.
• Cómo publicar contenido: otras herramientas pueden requerir pasos adicionales para publicar contenido, como el uso de puntos de conexión XMLA o las API de REST de Power BI.

Una vez que decida cómo creará contenido, deberá elegir dónde publicará y probará el contenido mientras lo desarrolla.

Decidir cómo configurará y usará áreas de trabajo

Al desarrollar contenido, debe usar varias áreas de trabajo (o fases) para separar el contenido de producción que usa la organización del contenido que se está desarrollando o validando. Usar áreas de trabajo separadas para su contenido tiene varias ventajas:

• Puede desarrollar y probar contenido sin afectar al contenido que está actualmente en uso. Esto evita los cambios que pueden provocar interrupciones involuntarias en el contenido en producción.
• Puede usar recursos separados para desarrollar y probar el contenido, como usar capacidades de Fabric o puertas de enlace de datos independientes. Esto evita que los recursos usados para el desarrollo y las pruebas interrumpan las cargas de trabajo de producción, lo que provoca actualizaciones de datos lentas o informes.
• Puede crear un proceso más estructurado para desarrollar, probar y publicar contenidos teniendo entornos discretos para cada una de estas fases. Esto le ayuda a mejorar la productividad.

En Fabric y Power BI, recomendamos usar áreas de trabajo Fabric separadas, como se describe en los artículos de planeamiento de nivel de inquilino y nivel de área de trabajo.

Importante

El uso de entornos independientes es un paso esencial para garantizar el éxito del enfoque de administración del ciclo de vida de contenido.

Hay varias maneras de usar áreas de trabajo de Fabric para separar entornos. Normalmente, además del entorno local, se usan dos o más áreas de trabajo para administrar el contenido durante su ciclo de vida.

Responda a las siguientes preguntas mientras planifica cómo usará las distintas áreas de trabajo a lo largo del ciclo de vida de este contenido:

• ¿Cuántas áreas de trabajo necesito?
• ¿Va a separar las áreas de trabajo según el tipo de elemento?
• ¿Quién tendrá acceso a cada área de trabajo?
• ¿Pertenecerán las áreas de trabajo a una canalización de implementación de Fabric, u organizará la implementación usando otros enfoques, como por ejemplo usando Azure Pipelines?
• ¿Cómo administrará la publicación entre áreas de trabajo? Por ejemplo, ¿necesita asegurarse de que los informes de un área de trabajo de prueba para informes se conectan con los modelos semánticos de un área de trabajo de prueba separada para elementos de datos?
• ¿Necesita usar también recursos de apoyo independientes para los elementos de las áreas de trabajo de producción, como un clúster de puerta de enlace de datos local independiente?

Las siguientes secciones ofrecen una introducción de alto nivel de los distintos enfoques que puede adoptar para separar las áreas de trabajo y facilitar la administración del ciclo de vida.

Nota:

Las secciones siguientes se centran en cómo configurar y usar áreas de trabajo independientes. Puede implementar contenido en estas áreas de trabajo mediante uno de los cuatro enfoques siguientes:

• Publicación desde Power BI Desktop.
• Implementación de contenidos desde otra área de trabajo usando canalizaciones de implementación de Fabric.
• Sincronización del contenido de un repositorio de Git remoto usando la integración de Git.
• Implementación del contenido mediante programación usando las API de REST de Fabric, las API de REST de Power BI o los puntos de conexión de XMLA.

Para más información sobre estos enfoques para implementar contenidos, consulte Fase 4: Implementación de contenidos más adelante en esta serie.

Áreas de trabajo de pruebas y producción

Al entregar contenido más sencillo que no es crítico para la organización, dos áreas de trabajo a menudo pueden ser suficientes. En este escenario, los creadores de contenido suelen tener una colaboración limitada en los mismos elementos y desarrollar contenido localmente.

En el diagrama siguiente se muestra un ejemplo de alto nivel de cómo puede usar entornos independientes solo con un área de trabajo de prueba y producción.

En el diagrama se muestran los siguientes procesos y componentes para separar áreas de trabajo en este enfoque.

Elemento	Descripción
	Los creadores de contenido desarrollan contenido en su entorno local.
	Cuando estén listos, los creadores de contenido publicarán el contenido en un área de trabajo de prueba. Los creadores de contenido pueden desarrollar contenido que solo se puede generar con la creación web y realizar la validación de contenido en el área de trabajo de prueba.
	Cuando estén listos, los creadores de contenidos los implementarán en un área de trabajo de producción. En el área de trabajo de producción, los creadores de contenido distribuyen contenido publicando una aplicación de Power BI o compartiendo contenido desde el área de trabajo.

Nota:

Hay muchas maneras diferentes de configurar y usar áreas de trabajo independientes e implementar contenido entre estas áreas de trabajo. Sin embargo, se recomienda no realizar el desarrollo local y, a continuación, publicar contenido directamente en un área de trabajo de producción. Esto puede provocar interrupciones y errores evitables.

Áreas de trabajo de desarrollo, pruebas y producción

Al entregar contenido crítico para la empresa, normalmente se usan tres o más áreas de trabajo independientes. En este escenario, los creadores de contenido suelen colaborar en un área de trabajo de desarrollo adicional que contiene la versión más reciente de la solución.

En el diagrama siguiente se muestra un ejemplo de alto nivel de cómo puede usar entornos independientes con un área de trabajo de desarrollo, prueba y producción.

En el diagrama se muestran los siguientes procesos y componentes para separar áreas de trabajo en este enfoque.

Elemento	Descripción
	Los creadores de contenido desarrollan contenido en su entorno local.
	Cuando esté listo, los creadores de contenido publican contenido en un área de trabajo de desarrollo. En el área de trabajo de desarrollo, los creadores de contenido pueden desarrollar contenido que solo se puede producir con la creación web. Los creadores de contenido también pueden validar el contenido en el área de trabajo de desarrollo.
	Cuando estén listos, los creadores de contenidos implementarán el contenido en un área de trabajo de prueba. En el área de trabajo de prueba, los usuarios validan el contenido, ya sea en el área de trabajo o en una aplicación.
	Cuando estén listos, los creadores de contenidos los implementarán en un área de trabajo de producción. En el área de trabajo de producción, los creadores de contenido distribuyen contenido publicando una aplicación de Power BI o compartiendo contenido desde el área de trabajo.

Nota:

Puede usar hasta diez entornos diferentes con canalizaciones de implementación. Por ejemplo, es posible que desee tener un entorno de preproducción entre pruebas y producción que sea específicamente para tipos especiales de validación, como las pruebas de rendimiento.

Área de trabajo privada con integración de Git

Al entregar contenidos críticos para la empresa, cada desarrollador puede usar también su propia área de trabajo privada para el desarrollo. En este escenario, un área de trabajo privada permite a los creadores de contenido probar contenido en el portal de Fabric o usar características como la actualización programada sin arriesgar la interrupción a otros usuarios del equipo de desarrollo. Los creadores de contenido también pueden desarrollar contenido en el portal de Fabric aquí, como flujos de datos. Las áreas de trabajo privadas pueden ser una buena opción al administrar los cambios de contenido mediante la integración de Git junto con Azure DevOps.

Nota:

Azure DevOps es un conjunto de servicios que se integran con Power BI y Fabric para ayudarle a planear y organizar la administración del ciclo de vida del contenido. Al usar Azure DevOps de esta manera, normalmente aprovecha los siguientes servicios:

• Azure Repos: permite crear y usar un repositorio de Git remoto, que es una ubicación de almacenamiento remota que se usa para realizar un seguimiento y administrar los cambios de contenido.
• Azure Pipelines: permite crear y usar un conjunto de tareas automatizadas para controlar, probar e implementar contenido desde un repositorio remoto en un área de trabajo.
• Azure Test Plans: permite diseñar pruebas para validar la solución y automatizar el control de calidad junto con Azure Pipelines.
• Azure Boards: permite usar paneles para realizar un seguimiento de tareas y planes como elementos de trabajo y vincular o hacer referencia a elementos de trabajo de otros servicios de Azure DevOps.
• Wiki de Azure: permite compartir información con su equipo para comprender y contribuir al contenido.

En el diagrama siguiente se muestra un ejemplo de alto nivel de cómo puede usar entornos independientes mediante un área de trabajo privada con la integración de Git.

Nota:

En el diagrama se muestran los desarrolladores independientes que trabajan en ramas independientes de una solución (rama uno y dos) antes de combinar sus cambios en una rama principal. Esta es una representación simplificada de una estrategia de ramificación de Git para ilustrar cómo los desarrolladores pueden integrar sus cambios con un repositorio de Git remoto y beneficiarse de la integración de Git en Fabric.

En el diagrama se muestran los siguientes procesos y componentes para separar áreas de trabajo en este enfoque.

Elemento	Descripción
	Cada creador de contenido desarrolla contenido en su propio entorno local.
	Cuando están listos, los creadores de contenido confirman y envían sus cambios a un repositorio remoto, como un repositorio de Git de Azure Repos.
	En el repositorio remoto Git, los creadores de contenidos hacen un seguimiento de los cambios y los administran usando el control de código fuente, y ramifican y combinan contenidos para facilitar la colaboración.
	Los creadores de contenido sincronizan una rama del repositorio remoto con un área de trabajo privada. Después de la sincronización, los cambios más recientes que un creador confirma e inserta en la rama están visibles en esa área de trabajo privada. Los distintos creadores de contenidos trabajan en sus propias ramas separadas a medida que realizan cambios.
	En las áreas de trabajo privadas, los creadores de contenido pueden desarrollar contenido mediante la creación web y validar sus propios cambios. Los cambios realizados en el contenido realizado por la creación web pueden sincronizarse con la rama en el repositorio de Git cuando el creador del contenido confirma e inserta estos cambios desde el área de trabajo. Diferentes creadores de contenido trabajan en sus propias áreas de trabajo privadas independientes.
	Cuando están listos, los creadores de contenido realizan una solicitud de cambios para combinar sus cambios en la rama principal de la solución.
	Después de combinar los cambios, la rama principal se sincroniza con el área de trabajo de desarrollo.
	En el área de trabajo de desarrollo, los creadores de contenido pueden desarrollar contenido que no sea compatible con la integración de Git de Fabric, como paneles. Los creadores de contenido también validan la solución integrada que contiene todos los cambios más recientes.
	Cuando estén listos, los creadores de contenidos implementarán el contenido en un área de trabajo de prueba. En el área de trabajo de prueba, los usuarios realizan pruebas de aceptación del usuario del contenido.
	Cuando estén listos, los creadores de contenidos los implementarán en un área de trabajo de producción. En el área de trabajo de producción, los creadores de contenido distribuyen contenido publicando una aplicación de Power BI o compartiendo contenido desde el área de trabajo.

Recursos auxiliares para áreas de trabajo

Al usar entornos independientes, también debe tener en cuenta cómo afectará a varios recursos auxiliares que use en estos entornos. Para estos recursos auxiliares, considere si también necesita separarlos en el mismo número de fases, o bien cómo coordinará su uso en estos entornos.

• Puertas de enlace: considere la posibilidad de usar clústeres de puerta de enlace de datos locales independientes y puertas de enlace de red virtual para cargas de trabajo de producción. Esto es beneficioso para evitar interrupciones, pero también para garantizar el tiempo de actividad cuando necesite actualizar estas puertas de enlace.
• Aplicaciones: considere la posibilidad de tener aplicaciones independientes para áreas de trabajo de prueba y producción. No es posible implementar ni copiar aplicaciones entre fases. Las aplicaciones del área de trabajo de prueba están diseñadas para ayudarle a probar el contenido y la experiencia de la aplicación antes de implementar los cambios en el área de trabajo de producción. Las aplicaciones del área de trabajo de producción están diseñadas para entregar contenido a los usuarios finales en una experiencia estructurada.
• Azure DevOps: si tiene previsto usar Azure DevOps para colaborar y organizar el control e implementación de código fuente, considere cómo usará ramas y Azure Pipelines para implementar contenido entre estos entornos. Para más información sobre cómo usar Azure Pipelines para implementar contenido, consulte Fase 4: Implementar contenido.

Una vez que haya decidido cómo configurará y usará las áreas de trabajo, el siguiente paso es decidir cómo realizará el control de versiones para realizar un seguimiento de los cambios de contenido y administrarlos.

Decidir cómo va a usar el control de versiones

En Power BI, puede realizar el control de versiones usando SharePoint/OneDrive, o usando un repositorio de Git remoto, como Azure Repos, que es un componente de Azure DevOps. En ambos enfoques, agregará archivos de contenido local a una ubicación de almacenamiento remoto para ayudar a realizar un seguimiento y administrar los cambios. Se recomienda usar SharePoint o OneDrive solo para proyectos más pequeños y sencillos, ya que carece de las características y la solidez para admitir escenarios más grandes o más complicados.

Estas son algunas consideraciones generales que le ayudarán a configurar y usar el control de versiones.

• Alertas: debería establecer alertas para cuando otras personas agreguen, eliminen o modifiquen archivos críticos.
• Ámbito: defina claramente el ámbito de la ubicación del almacenamiento remoto. Lo ideal es que el ámbito de la ubicación de almacenamiento remoto sea idéntico al ámbito de las áreas de trabajo y las aplicaciones que use para entregar contenidos a los consumidores.
• Acceso: debe configurar el acceso a la ubicación de almacenamiento remoto 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 a la ubicación de almacenamiento remoto.
• Documentación: agregue archivos de texto a la ubicación de almacenamiento remoto para describir la ubicación de almacenamiento remoto y su propósito, propiedad, acceso y procesos definidos.

En las secciones siguientes se describen cada enfoque y consideraciones clave para decidir cuál debe usar.

Control de versiones usando SharePoint o OneDrive para el trabajo y la escuela

SharePoint tiene control de versiones integrado para archivos. Los creadores de contenido pueden desarrollar modelos semánticos o informes localmente, y sus cambios se sincronizan con una biblioteca de documentos de SharePoint o OneDrive para el trabajo y la escuela.

Sugerencia

Use SharePoint o OneDrive solo para el control de versiones en escenarios más sencillos y más pequeños, como publicación de contenido de autoservicio. Para escenarios más grandes o complicados, debería considerar realizar el control de código fuente usando un repositorio de Git remoto.

En el diagrama siguiente se muestra información general de alto nivel sobre cómo realizar el control de versiones mediante SharePoint o OneDrive.

En el diagrama se describen los siguientes procesos y componentes.

Elemento	Descripción
	Los creadores de contenido desarrollan modelos semánticos e informes en su entorno local y guardan estos modelos e informes como archivos .pbix.
	Cuando están listos, los creadores de contenidos guardan sus cambios, que sincronizan con una biblioteca remota de SharePoint o OneDrive para el trabajo y la escuela.
	En la biblioteca remota, los creadores de contenido realizan un seguimiento de los cambios de nivel de archivo que facilitan el control de versiones.
	Los creadores de contenido pueden vincular un modelo semántico publicado o un informe a un archivo .pbix para facilitar la actualización de OneDrive. La actualización de OneDrive publica automáticamente los cambios de contenido cada hora.
	En el área de trabajo Fabric, los creadores de contenido ven los cambios en el contenido de Power BI una vez finalizada la actualización de OneDrive.

Importante

Solo puede realizar el control de versiones mediante archivos de SharePoint o OneDrive para Power BI Desktop que contienen modelos o informes semánticos. No puede realizar fácilmente el control de versiones mediante SharePoint o OneDrive para otros tipos de elementos de Power BI, como flujos de datos, o para tipos de elementos de Fabric como cuadernos. Para estos otros tipos de elementos, debe realizar el control de versiones mediante un repositorio de Git remoto, como Azure Repos.

En resumen, los creadores de contenido pueden vincular un modelo semántico publicado o un informe a un archivo .pbix almacenado en una biblioteca de SharePoint o OneDrive para el trabajo y la escuela. Con este enfoque, los creadores de contenido ya no tienen que publicar el modelo semántico para ver los cambios. En su lugar, los cambios son visibles después de una actualización automática de OneDrive, que se produce cada hora. Aunque conveniente, este enfoque conlleva algunas consideraciones, y no puede invertirse fácilmente.

Aunque es fácil de configurar y administrar, el control de versiones con SharePoint o OneDrive tiene más limitaciones. Por ejemplo, no es posible ver los cambios dentro del contenido, y tampoco es posible comparar versiones. Además, no es posible configurar procesos más sofisticados para administrar estos cambios (como la bifurcación o las solicitudes de incorporación de cambios, descritos más adelante en este artículo).

Considere usar SharePoint o OneDrive para realizar el seguimiento de los cambios y administrarlos en los siguientes escenarios:

• El contenido consiste solo en modelos semánticos o informes guardados como archivos .pbix.
• Los usuarios de autoservicio crean y administran el contenido.
• Los creadores de contenido colaboran con Microsoft Teams.
• Los creadores de contenido no tienen experiencia con Git y la administración del control de código fuente.
• Los creadores de contenido administran un solo elemento con una complejidad y colaboración limitadas.
• Los archivos .pbix tienen una etiqueta de confidencialidad aplicada que cifra su contenido.

Nota:

OneDrive y SharePoint admiten contenido que tiene etiquetas de confidencialidad aplicadas, excepto en algunos escenarios limitados. En cambio, la integración de Git de Fabric no es compatible con las etiquetas de confidencialidad.

Evite usar SharePoint o OneDrive para realizar el seguimiento de los cambios y administrarlos en los siguientes escenarios:

• El contenido consta de tipos de elementos distintos de los modelos semánticos e informes.
• El contenido es complejo o grande en el ámbito.
• Los creadores de contenido deben trabajar de forma colaborativa en el mismo elemento al mismo tiempo.

En las secciones siguientes se describen consideraciones adicionales para usar eficazmente el control de versiones mediante SharePoint o OneDrive con Power BI.

Integración de Microsoft Teams

Puede usar las bibliotecas de documentos de Microsoft Teams si los creadores de contenido las usan para su colaboración. Las bibliotecas de documentos son sitios de SharePoint, y usar las bibliotecas de documentos (en lugar de un sitio de SharePoint o una carpeta de OneDrive independientes) garantiza la centralización del contenido, los archivos y la colaboración.

Protección y desprotección de archivos

Debería proteger los archivos en los que esté trabajando para evitar posibles conflictos de cambios. Una vez completados los cambios, compruebe los archivos con comentarios que describen el cambio. La protección y desprotección de archivos le ayudan a mejorar la colaboración entre creadores de contenido al usar SharePoint o OneDrive para el trabajo y la escuela para el control de versiones. Si protege y desprotege archivos con varios creadores de contenido, puede modificar la biblioteca del sitio de SharePoint para ver la última actualización y los comentarios de la última desprotección.

Historial de versiones

Asegúrese de realizar una copia de seguridad del contenido en una ubicación independiente en caso de interrupciones inesperadas en la biblioteca de documentos del sitio de SharePoint. También debe establecer límites en el número de versiones que se mantienen en el sitio de SharePoint y eliminar versiones anteriores. Esto garantiza que el historial de versiones siga teniendo sentido y no ocupe demasiado espacio.

Para un control de versiones más sofisticado, puede almacenar archivos en un repositorio remoto, como Azure Repos, y administrar los cambios mediante el control de código fuente.

Control de código fuente mediante un repositorio de Git remoto

Un repositorio de Git remoto facilita el control de código fuente de los archivos, lo que permite a los creadores de contenido realizar un seguimiento y administrar los cambios. En resumen, los creadores de contenido pueden desarrollar contenido localmente o en el servicio Power BI y, a continuación, confirmar e insertar esos cambios en un repositorio de Git remoto, como Azure Repos.

Nota:

También puede realizar el control de código fuente del contenido sin usar la integración de Git. En este escenario, seguirá supervisando y administrando los cambios de contenido en un repositorio de Git remoto, pero implementará el contenido usando las API de REST o los puntos de conexión de lectura/escritura de XMLA. Para más información sobre estos métodos de implementación de contenidos, consulte Fase 4: Implementación de contenidos.

El siguiente diagrama muestra una introducción de alto nivel sobre cómo realizar el control de código fuente mediante

En el diagrama se describen los siguientes procesos y componentes.

Elemento	Descripción
	Los creadores de contenido desarrollan modelos semánticos e informes en su entorno local y guardan estos modelos e informes como archivos .pbip. Los creadores de contenido también pueden desarrollar modelos semánticos y guardar metadatos del modelo.
	Cuando están listos, los creadores de contenidos guardan sus cambios, que confirman y envían a un repositorio de Git remoto a intervalos regulares.
	En el repositorio de Git remoto, los creadores de contenido realizan un seguimiento de los cambios en el nivel de objeto, lo que facilita el control de versiones. Los creadores de contenido también pueden crear ramas para trabajar en el contenido y combinar sus cambios en una sola rama mediante solicitudes de incorporación de cambios.
	Los creadores de contenido pueden sincronizar contenido desde el repositorio remoto mediante la integración de Git. También pueden implementar contenidos usando otros enfoques, como las Azure Pipelines junto con las API de REST.
	En las áreas de trabajo de Fabric, los creadores de contenido ven los cambios en el contenido de Power BI una vez finalizada la sincronización o la implementación. Los creadores de contenido pueden crear contenido como flujos de datos o cuadernos en el área de trabajo. Si usan la integración de Git, los creadores de contenido vinculan esta área de trabajo a una rama específica del repositorio remoto.
	Los creadores de contenido pueden confirmar e insertar cambios de un área de trabajo en el repositorio remoto mediante la integración de Git. Estos cambios pueden importar definiciones de elementos para el contenido admitido creado en el área de trabajo, como flujos de datos y cuadernos.

En resumen, los creadores de contenido almacenan archivos .pbip, archivos de metadatos y documentación en un repositorio remoto central de 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 más sofisticadas para realizar un seguimiento y administrar los cambios en comparación con SharePoint y OneDrive. Mantener un repositorio bien organizado y documentado es esencial porque es la base de todo el contenido y la colaboración.

Considere usar el control de código fuente para supervisar y administrar los cambios en los siguientes escenarios:

• Los equipos centralizados o descentralizados crean y administran el contenido.
• Los creadores de contenido colaboran mediante Azure DevOps.
• Los creadores de contenido están familiarizados con los principios de Git, administración del control de código fuente o DataOps.
• Los creadores de contenido administran contenido complejo o importante o esperan que el contenido escale y aumente en complejidad e importancia.

Estos son algunos requisitos previos y consideraciones que le ayudarán a usar eficazmente el control de código fuente con Azure DevOps.

• Git: para confirmar y enviar cambios a un repositorio remoto, los creadores de contenido necesitan descargar e instalar Git. 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?.
• Herramientas: para usar Git, los creadores de contenidos necesitan usar una interfaz de línea de comandos (CLI) o un cliente de interfaz gráfica de usuario (GUI) para SCM, como Visual Studio o Visual Studio Code.
• Licencias y permisos: para crear y usar un repositorio de Git de Azure Repos, los creadores de contenido deben tener lo siguiente:
  • Nivel de acceso establecido en Básico (en lugar de Interesado).
  • Pertenecer a una organización y a un proyecto.
  • Permisos de repositorio apropiados.
• Integración del Git de Fabric: para sincronizar el contenido de un repositorio remoto con un área de trabajo de Microsoft Fabric, los creadores de contenido usan la Integración de Git de Fabric. Esto es importante para supervisar y administrar los cambios en el contenido que se crea en el portal de Fabric, como los flujos de datos.

Sugerencia

Para facilitar el control de código fuente con el desarrollo local, recomendamos usar una aplicación cliente como Visual Studio Code. Si usa Power BI Desktop para desarrollar contenido, puede usar Visual Studio Code para llevar a cabo la administración del control de código fuente de ese contenido, mediante la preparación, confirmación y envío de cambios a su repositorio remoto.

Advertencia

La integración de Git de Fabric tiene algunas limitaciones con los elementos y escenarios admitidos. Asegúrese de que primero valida si la integración del Git de Fabric se adapta mejor a su escenario específico, o si debería adoptar un enfoque diferente para implementar el control de código fuente.

Además, las etiquetas de confidencialidad no son compatibles con la integración de Git con Fabric, y la exportación de elementos con etiquetas de confidencialidad podría deshabilitarse. Si el contenido tiene etiquetas de confidencialidad, debe planear cómo puede lograr el control de versiones mientras respeta las directivas de prevención de pérdida de datos.

Una ventaja clave del uso del control de código fuente con Azure Repos es mejorar la colaboración entre creadores de contenido y más personalización y supervisión con respecto a los cambios y la implementación del contenido.

En el diagrama siguiente se muestra información general de alto nivel sobre cómo Azure DevOps permite la colaboración con el control de código fuente.

Nota:

En el diagrama anterior se muestra un ejemplo de cómo colaborar mediante Azure DevOps. Elija un enfoque que mejor se adapte a las necesidades y a la forma de trabajar de su equipo.

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.

En las secciones siguientes se describen consideraciones adicionales para usar eficazmente el control de código fuente mediante Azure DevOps y Power BI.

Importante

El uso eficaz de la bifurcación, las confirmaciones, las solicitudes de incorporación de cambios y las combinaciones es esencial para beneficiarse más del control de código fuente al administrar el ciclo de vida del contenido de Power BI.

Usar ramas

Los creadores de contenidos logran la colaboración usando una estrategia de ramificación. Una estrategia de ramificación permite a los creadores de contenido individuales trabajar 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 y se envía a una versión de la rama en el repositorio remoto con un mensaje de confirmación descriptivo. Un mensaje de confirmación describe los cambios realizados en esa confirmación.

Al usar una estrategia de bifurcación para administrar el contenido de Fabric, tenga en cuenta los siguientes factores.

• El contenido de las ramas que los creadores deberían clonar para su propio trabajo. Por ejemplo, si estas ramas son un clon de la rama principal (lo que se conoce como desarrollo basado en troncos) o si son otras ramas, como las ramas de publicación para versiones específicas y planificadas del contenido.
• Si va a definir el ámbito del trabajo específico para distintas versiones de contenido mediante ramas de versión.
• Qué ramas se conectan a qué áreas de trabajo cuando usa la integración de Git de Fabric.

Sugerencia

Consulte Adoptar una estrategia de ramificación de Git para obtener orientación y recomendaciones específicas sobre cómo usar mejor una estrategia de ramificación para facilitar la colaboración de forma eficaz.

Cambios por lotes en confirmaciones

Al desarrollar contenido, los creadores deben realizar periódicamente cambios en lotes (o grupos). Estos cambios deben abordar un elemento de trabajo específico para la solución (por ejemplo, una característica o un problema). Cuando están listos, los creadores de contenidos confirman estos cambios preparados.

Realizar los cambios por lotes de esta forma tiene varias ventajas.

• Ayuda a estructurar el desarrollo y ofrece a los creadores de contenido la oportunidad de revisar y documentar los cambios que han agrupado.
• Mejora la alineación entre el planeamiento y el desarrollo, lo que facilita la vinculación de características y problemas y obtiene transparencia sobre cómo se está realizando el trabajo.
• Los propietarios técnicos pueden revisar más fácilmente las solicitudes de incorporación de cambios de los creadores de contenido si los cambios se procesan por lotes adecuadamente y tienen mensajes de confirmación claros.

Al preparar y confirmar los cambios en el contenido de Power BI, tenga en cuenta los siguientes factores.

• Si va a preparar y confirmar los cambios desde un repositorio local o desde las áreas de trabajo de Fabric.
• Coloque los archivos .pbip en las carpetas de nivel superior cuando almacene varios modelos o informes en un único repositorio. Esto hará que sea más fácil identificar y agrupar los cambios que realice.
• Omita los cambios de metadatos inocuos o poco útiles usando un archivo gitignore o un archivo .gitattributes. Esto garantizará que todos los cambios que confirme sean significativos.

Sugerencia

Consulte Guardar su trabajo con confirmaciones para obtener orientación y recomendaciones específicas sobre cómo preparar y confirmar su trabajo en un repositorio de Git.

Creación de solicitudes de incorporación de cambios para combinar cambios

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.

Al usar solicitudes de incorporación de cambios para combinar cambios en el contenido de Power BI, tenga en cuenta los siguientes factores.

• Qué estándares y prácticas usará para realizar la revisión, si existe. Por ejemplo, puede usar reglas del Analizador de procedimientos recomendados para modelos semánticos.
• Cómo revisará los cambios en los metadatos del informe, que no es fácil de leer y comprender sin usar herramientas de terceros.
• Cómo solucionar y resolver conflictos de combinación.

Sugerencia

Consulte Acerca de las solicitudes de cambios y Estrategias de combinación y combinación con "squash" para obtener orientación y recomendaciones específicas sobre la mejor manera de usar las solicitudes de cambios para facilitar la colaboración mediante la combinación de cambios en el contenido.

Lista de comprobación: al planear dónde almacenará archivos, las decisiones clave y las acciones incluyen:

• Elegir las herramientas de desarrollo: asegúrese de que el enfoque para desarrollar contenido se alinea con la forma en que colaborará con otros creadores de contenido y usará el control de versiones.
• Elegir entre formatos .pbip y .pbix para modelos e informes: normalmente, el formato .pbip es más beneficioso para el control de código fuente, pero los usuarios de autoservicio pueden encontrar los archivos .pbix más fáciles de usar.
• Desarrollo de informes y modelo semántico independientes: el control de versiones es más eficaz cuando se administran los cambios para distintos tipos de elementos, por separado. Separar el desarrollo del modelo y del informe se considera una buena práctica.
• Decidir cuántas áreas de trabajo necesita: el uso de entornos independientes es fundamental para el éxito de la administración del ciclo de vida del contenido. Asegúrese de que ha aclarado cuántas áreas de trabajo necesita y lleve a cabo el planeamiento adecuado de nivel de área de trabajo.
• Decidir cómo implementará el control de versiones: decidir entre un enfoque más sencillo mediante SharePoint o OneDrive para la Empresa, o mediante Azure DevOps para facilitar el control de código fuente.
• Configurar el repositorio remoto: crear un espacio estructurado en la carpeta de OneDrive o en el repositorio de Git donde almacenará contenido para realizar un seguimiento y administrar los cambios.
• Si usa el control de código fuente, configure archivos .gitignore y .gitattributes: asegúrese de configurar el repositorio para que solo realice un seguimiento de los cambios significativos.
• Si usa el control de código fuente, defina estrategias de ramificación y combinación: asegúrese de definir procesos claros para cómo configurará y usará el control de código fuente para admitir mejor el desarrollo. Evite sobrecomplicar el proceso. En su lugar, intente complementar la forma actual de trabajar en los equipos de desarrollo.

Contenido relacionado

En el próximo artículo de esta serie, aprenderá a validar el contenido como parte de la administración del ciclo de vida del contenido.