Canalizaciones de implementación de Power BI: reasignar el área de trabajo

Accidentalmente desasigné un espacio de trabajo de producción de una canalización. Este espacio de trabajo tenía varios permisos para diferentes informes. ¡Ahora tengo que permitir que la canalización vuelva a crear otro espacio de trabajo de producción y luego ingresar todos los permisos nuevamente! No me impresionó.

Lo siento, pero esto no es una solución. Esta es solo una configuración ridícula impulsada por MS.

He estado haciendo desarrollo de software durante mucho tiempo. No puedo entender cómo algunas de las decisiones, especialmente en torno a las integraciones de Power BI, son impactantes. ¿Por qué una canalización crearía un espacio de trabajo? ¿Y cómo se puede desasociar un espacio de trabajo de una etapa de canalización para forzar la creación de un nuevo espacio de trabajo? ¿Es esto en cualquier universo un buen diseño? ¿MS es consciente de que en un entorno empresarial las cosas están segregadas y un desarrollador no puede asociar un espacio de trabajo con una capacidad premium así como así? Una vez que no puede volver a asociar un espacio de trabajo con una canalización, la cantidad de trabajo que se impone a los desarrolladores es increíble. Lo siento, pero esto no fue pensado ni diseñado en absoluto.

@sheigel,

Gracias por sus comentarios sinceros.

Trataré de ser tan honesto también, tienes razón. tener la limitación de asignar solo 1 espacio de trabajo a una canalización y no 3 espacios de trabajo a todas las etapas es una limitación existente que tampoco nos gusta.

Sin embargo, crear esta funcionalidad requirió mucho trabajo adicional que nos habría llevado mucho tiempo entregar y retrasar el lanzamiento de las canalizaciones de implementación. Un recordatorio, las canalizaciones están disponibles por menos de 6 meses, una característica relativamente joven en Power BI. Como tal, aún le faltan muchas funcionalidades importantes que muchos clientes consideran «críticas». Si tuviéramos que construirlos todos antes de lanzar las canalizaciones, tendríamos una gran característica completa, que habría estado disponible para los clientes dentro de 2 años a partir de ahora.

En su lugar, decidimos ofrecer un producto valioso mínimo que los usuarios puedan usar, con sus limitaciones, y trabajamos continuamente para mejorar y agregar funcionalidad.

La capacidad de asignar WS a las 3 etapas es una de ellas, y esperamos entregarla durante CY21.

Hasta entonces, puede decidir no usar canalizaciones de implementación y esperar a que esta función esté disponible.

Esto sonará obstinado, criticar un producto sin una comprensión profunda del mismo y, básicamente, hacer una revisión del diseño del sillón.

Gracias por tomarse el tiempo para responder y continuar la conversación.

Siempre puedo aceptar que obtener algo en producción, reducir el tamaño del lote y tener un flujo fluido de funcionalidad en producción es una pieza fundamental de la agilidad y del aumento del valor entregado.

Esto no es una excusa para crear la función incorrecta y, además, ponerla en producción con limitaciones claras.

Digo producto incorrecto porque no entiendo cómo estas canalizaciones respaldan los esfuerzos de automatización. Además, esta característica no está en línea con las mejoras generales que la mentalidad devops nos ha traído en los últimos años. Realmente no hay una buena razón para reinventar la rueda de CI/CD, de promover un artefacto a través de diferentes etapas.

Ahora estamos atascados con una nueva forma de hacer promociones ambientales, mientras que todavía no se cumplen los requisitos fundamentales para la automatización.

En lugar de construir un sistema de este tipo, hubiera sido bueno brindar soporte concreto para la colaboración y el control de versiones del PBIX en lugar de crear más además de la desastrosa idea de tener un solo archivo binario como artefacto de PBI. Hubiera sido bueno tener una separación clara de modelos e informes en lugar de documentar la división del archivo PBIX binario en dos. Simplemente valida que fue una decisión equivocada tener datos e informes juntos en el mismo archivo binario.

Ahora estamos atascados con «versiones a través de OneDrive» porque con eso «no tendremos conflictos». A menos que uno tenga conflictos que no se pueden resolver.

Le sugiero encarecidamente que reconsidere el camino que empezó.

Si no puede dividir el archivo PBIX, agregue algún paso de compilación que separe el modelo en un archivo bim y el informe en algún otro archivo (aunque esto no hará posible la colaboración). Esta separación permitiría la implementación de archivos bim con Invoke-AsCmd, una herramienta que parece funcionar y desde Azure DevOps Pipeline podríamos implementar en cualquier espacio de trabajo que queramos.

Para el lado de los informes, tendrá que crear un formato de archivo diferente, no binario, y proporcionar un sistema similar.

Comenzaste en el camino equivocado y necesitas aceptarlo y tomarte el tiempo para arreglarlo. De lo contrario, seguirá adelante, mientras que el resto del uso buscaremos alternativas.

Una vez más, agradezco que responda a mis puntos. Espero que puedas ignorar la frustración en mi mensaje. Si no, al menos entienda que se trata de intentar industrializar y crear un proceso profesional para el desarrollo de PBI y no ver un camino a seguir.

Algunos puntos más que me gustaría plantear:

1. Estamos planeando automatizar las canalizaciones de implementación, para que pueda usar herramientas familiares como Azure Pipelines. de hecho, estamos trabajando en esto ahora mismo.
2. Estoy de acuerdo en que el formato de archivo abierto habría sido ideal y abriría muchas más opciones para un proceso completo de lanzamiento de CI/CD, pero este es un proyecto muy (muy) grande que esperamos lograr algún día. hasta entonces, puede obtener algunas ideas y mejores prácticas sobre cómo administrar el contenido en esta publicación de blog detallada.
3. Habiendo dicho todo eso, uno debe recordar que Power BI también es un análisis de código bajo/sin código. plataforma, y ​​parte de Power Platform, que está dirigida a desarrolladores de código bajo/sin código. Como tal, vemos una gran importancia en proporcionar a TODOS los tipos de desarrolladores las herramientas que los ayudarán a lograr más. En nuestro caso, se trata de permitir que CUALQUIER creador de BI o equipo de BI entregue actualizaciones de contenido más rápido y con mayor calidad, incluso si no tienen las habilidades técnicas necesarias. Los métodos DevOps deberían ser una práctica común de la que todos puedan beneficiarse, y esto es lo que estamos tratando de hacer con las canalizaciones de implementación de Power BI.