¡Nueva herramienta del servicio de Power BI para facilitarnos la vida como desarrolladores!
¿Quién no quiere tener un mejor control de sus objetos de Power BI? Si alguna vez te has visto en alguna de las siguientes situaciones, este es tu post.
- ¿Qué versión de este informe tengo desplegado en el servicio?
- Los usuarios de negocio una vez publicado un informe ¿te han reportado errores?
- Usuarios de negocio que están usando un informe, y se quejan de que ha cambiado
Power BI ha evolucionado muchísimo, ya que tenemos el Self-service BI, el team BI y el Corporate BI, podemos tener soluciones que escalan a montones de métricas para soluciones más eficientes gestionadas directamente por usuarios de negocio
Además, Power BI ha evolucionado desde el desktop, de tener dos capas.
- Dataset que es donde nos conectamos y transformamos la información.
- Los componentes visuales.
A que desde hace un tiempo también engloba Aplicaciones, los Dashboards, los Reports, Reports Paginados, Dataflows y más
Existía la necesidad de una funcionalidad que al menos diera la posibilidad de tener un entorno de desarrollo, de test y de producción, para controlar los desarrollos de las soluciones BI, para ello Microsoft saco los deployment pipelines.
La herramienta de deployment pipeline permite a los creadores de BI administrar el ciclo de vida del contenido de la organización. También permite a los creadores desarrollar y probar contenido en Power BI antes de que los usuarios lo consuman. Los tipos de contenido que están soportados son Informes, Paneles y Conjuntos de Datos.
Esta nueva herramienta nos permite definir fases de desarrollo, test y producción e ir desplegando el contenido a través de nuestras fases de manera global o seleccionada, entre los diferentes elementos hasta llegar a producción.
Sin tocar código, se pueden mover los componentes de un entorno a otro y, además, lo hace de manera incremental al desplegar la Metadata, cosa que cuando se hace Publish para desplegar en un Workspace siempre se sustituye el anterior, perdiendo los anteriores elementos.
Como ejemplo de lo que a veces es un fastidio de sustituir, un Dataset que tiene un refresco incremental, el cual tendríamos que volver a configurar.
La herramienta está diseñada como una secuencia con tres fases para el control de los objetos de Power BI y el proceso está muy automatizado.
Desarrollo
Esta fase se usa para diseñar, compilar y cargar contenido nuevo con los compañeros desarrolladores. También en esta Fase o Workspace de desarrollo se dará solo acceso a aquellos usuarios que desarrollan y/o colaboran
Prueba
Una vez realizados todos los cambios necesarios en el contenido (en la fase de Desarrollo), ya se puede pasar a la fase de prueba. Para ello se carga el contenido desarrollado, a esta fase de prueba. A continuación, se muestran tres ejemplos de lo que se puede hacer en el entorno de prueba:
- Compartir contenido con evaluadores y revisores.
- Cargar y ejecutar pruebas con grandes volúmenes de datos.
- Probar la aplicación para ver cómo se buscarán los usuarios finales.
Producción
Después de probar y validar el contenido en la fase de Prueba, se pasaría a la fase de Producción, para compartir la versión final del contenido con los usuarios de negocio de la organización.
Estos son los tres pasos necesarios para asegurar el contenido y la validación del desarrollo que queremos implementar en el entorno de producción.
¿Es bastante sencillo, verdad? Vamos con algunos datos de interés general.
Esta herramienta la podemos encontrar en licencia Premium, parece que más adelante también la encontraremos en los Premium por Usuario, que actualmente está en preview por Microsoft. Por tanto, un usuario Pro no tendrá acceso a ninguno de estos Workspaces que componen el Deployment Pipeline
Atención que se está hablando de Workspaces y, por tanto, dentro de cada una de las fases tendremos las capacidades propias de un Workspace, seguridad, compartir y publicar son algunos ejemplos más comunes de lo que podemos hacer.
¿Necesitas ampliar tus conocimientos para impulsar tu proyecto?
Tanto si eres usuario de negocio sin experiencia y quieres dar tus primeros pasos en el Business Intelligence como si eres experto y quieres profundizar en tus conocimientos, tenemos algún curso para ti. Comprueba nuestro catálogo de formación en Power BI aquí.
Voy a echar un vistazoCreación de un pipeline
Para crear un pipeline, simplemente damos a crear pipeline
En el cuadro de dialogo que aparece, escribimos el nombre del pipeline
Lo creamos y nos pregunta a que fase pertenece el informe
Solo pueden asociarse los Workspaces que tienen capacidad Premium. Como buenas practicas se dice que los Workspaces se nombren con un identificador de la fase.
Una vez que hemos creado el pipeline y asociado el Workspace, indicamos cuál de los tres pasos es, ya podemos comenzar a mover elementos entre los Workspaces
Dando al botón Deploy Test, está creando un nuevo Workspace y además hace una copia exacta de los objetos del Workspace Sales Analysis. Todos los objetos no, está limitado, no hace copia de los Dataflows, ni de Excel ni de nada de la configuración de Datagateways, pero sí de Dashboards, Reports y Datasets.
En estos Workspaces que se crean, se les puede asignar seguridad y se pueden crear aplicaciones. Como hemos comentado mismas características que un Workspace fuera de un deployment pipeline.
A la hora de hacer un despliegue o pase de fase se pueden seleccionar solo los elementos que se quieran desplegar.
Automáticamente se crea un Workspace de test, en este punto está todo sincronizado.
Para una mayor comodidad se pueden generar reglas, estas pueden ser:
Cambios en el origen de datos que nos permitan tener distintos orígenes de datos por entorno y Workspace
Se pueden parametrizar los connection strings, para tener subconjuntos de los datos por entorno
Se pueden poner parámetros para quedarnos con un subconjunto de los datos en los entornos de desarrollo y pruebas, para optimizar el espacio en GB que ocupan nuestros objetos de Power BI. Ya que, por poner un ejemplo, en este caso estarían triplicados, una vez por fase y, por tanto, el volumen sería más elevado. Con los parámetros podemos controlarlo en cada fase, y quedarnos con el subconjunto deseado de datos
Para añadir parámetros a un Dataset debemos tener primero creado en el Dataset los parámetros
Para añadir/cambiar el valor a los parámetros le damos al botón de “+ Add Rules” en la sección “Parameters Rules”
Después de esto nos aparecerá una sección con un desplegable que nos muestra todos los parámetros que tenemos en nuestro Dataset y podemos cambiar el valor en cada uno de los entornos.
Esto solo cambia los valores del parámetro a la hora de hacer el despliegue, pero si ya se ha desplegado el Dataset, el parámetro no toma el nuevo valor. Si queremos que una vez cambiado el valor haga efecto, tenemos que desplegar de nuevo. Es un pequeño contra que supongo tendrán que mejorar en versiones posteriores.
Una vez definidas las reglas, tenemos que darle de nuevo a Deploy y nos refrescaría los solo los metadatos, posteriormente hay que refrescar manualmente el dato en el Workspace
¿Cómo se puede ver que está usando el parámetro? Voy a Workspace y Settings del Dataset y damos parámetros y aquí en esta sección si se puede ver como el valor del parámetro es el que hemos indicado
Es una limitación ya que no se pueden asignar los parámetros si no tienes un Dataset primero, y tienes que desplegar el Dataset para definir y acceder a los parámetros
Con cargas incrementales hay que refrescar el dato manualmente, como en la anterior imagen
Si se elimina alguno de los elementos enseguida nos aparece el compare indicando que algo ha cambiado
Ventajas
- Se puede volver a una versión anterior a partir de entornos superiores
- Desarrollar con una muestra de datos y no con el conjunto total de datos. Carga más rápida en entorno de desarrollo
- Comparación de metadatos. Con esto no se nos puede pasar cualquier modificación hecha en el modelo u origen del dato.
- Entorno de validación, mientras a versión actual funciona correctamente sin interrupciones
- Mas fiabilidad y estabilidad en los desarrollos
- La gente se olvida de las buenas practicas para poner en producción modificaciones o nuevos elementos en Power BI, lo que puede dar lugar a problemas grandes debido al gran trabajo que llevan los Power BI por detrás, puesto que un PBIX no se hace de un día para otro
- Dejamos atrás los líos de saber que versión está desplegada
- Evitar errores humanos
- Evitar fricciones entre distintos tipos de usuarios debido a posibles bloqueos o errores humanos
- Trabajar en capas con los diferentes usuarios y sus diferentes roles que están interactuando con las diferentes capas, Controllers, QAs, Developers y Usuarios Finales
- Cambios en la naturaleza de la solución de datos varia, cuando estamos desarrollando solemos hacerlo con poco dato para que la máquina en la que trabajamos vaya bien y no se generen tiempos muertos de espera, cuando lo subimos a test queremos simular lo más posible el entorno de producción, para poder ver temas de rendimientos o fallos que puedan darse, y en producción el dato es el que es definitivo.
- Flexibilidad para saltar de una capa a otra
- Debido a todos los conectores que tiene disponibles Power BI y que cada equipo de negocio quiere ver sus cosas en Power BI el trabajo que podemos tener detrás de un Power BI puede ser inmenso.
- Cuando hay una nueva mejora en la solución, traer una tabla, un módulo de datos, un nuevo Job en Data Factory y que todo esto haya que encapsularlo en un entregable para testearlo y ponerlo en producción asegurando que la cadena y el dato están funcionando, sin impactar al usuario final con el desarrollo
- La complejidad de las soluciones ha evolucionado mucho y los usuarios necesitan ver cambios rápidos, esto puede llevar a cometer errores sobre las implicaciones de meter un nuevo conector con una nueva fuente de datos que cambia el modelo sustancialmente
- Si algún día se pierde el desarrollo en Pruebas o en Desarrollo podemos decirle que se haga un despliegue desde producción a estos entornos anteriores, para ello solamente tener en cuenta que el entorno de destino debe estar completamente vacío
Inconvenientes
- Tenemos que gestionar nosotros el refresco de los datos
- Cuando se mueven los informes al abrirlos nos daremos cuenta que está vacío, ¿por qué? Porque en el movimiento hacia cada una de las fases solo mueve la Metadata, no mueve el dato del Dataset, el cual queda en nuestras manos para hacer el refresco. Lo que significa que tenemos que gestionar manualmente los refrescos, credenciales y agendar los refrescos, estos ultimos siempre se pueden parametrizar, pero si hay que lanzarlos de nuevo manualmente tras cada modificación para ver el dato actualizado.
- No se dispone de un repositorio para versionados, y así poder hacer rollback a otra versión anterior en cualquier momento
- El trabajo pasa más lentamente a entornos superiores. Pero debido a los pasos previos de desarrollo y pruebas hace que sea más estable y que los usuarios finales tengan los cambios que han solicitado
- Cumplimiento de reglas configuradas para pasar el código a entornos superiores.
- Esta funcionalidad solo funciona en Premium, cierto es que se va sacar un Premium por usuario por lo que tendrá más aceptación
Conclusiones
Debido a todos los conectores que tiene disponibles Power BI y que cada equipo de negocio quiere ver sus cosas en Power BI, el trabajo que podemos tener detrás de un Power BI puede ser inmenso.
La complejidad de las soluciones ha evolucionado mucho y los usuarios necesitan ver cambios rápidos, esto puede llevar a cometer errores sobre las implicaciones de meter un nuevo conector con una nueva fuente de datos que cambia el modelo sustancialmente
Cuando hay una nueva mejora en la solución, traer una tabla, un módulo de datos, un nuevo Job en Data Factory, todo esto tenemos que encapsularlo en un entregable, para testearlo y ponerlo en producción, debemos asegurar que la cadena y el dato están funcionando, sin impactar al usuario final con el desarrollo por tanto, con esta funcionalidad tenemos automáticamente la posibilidad de probarlo antes en el entorno de Pruebas.
Debido a todo lo expuesto con anterioridad, si es muy buena practica comenzar a utilizar los deployment pipelines para trabajar mejor y mas eficientemente con los Power BI y sus pruebas y pases a producción. Con la ventaja de que en cada entorno solo tendrán acceso los usuarios que sean necesarios y se hará la validación correspondiente tanto, del funcionamiento y como del rendimiento del informe antes de entregarlo al usuario final.
¡Todo ventajas para un trabajo más efectivo!
¡Sácale el máximo partido a Veeam Backup & Replication!
Veeam Backup & Replication es la herramienta de recuperación y copias de seguridad de Veeam Software una solución 4 en 1 para réplicas, backups, snapshots de almacenamiento y réplicas CDP. Apúntate a nuestro Curso de Veeam Backup & Replication y domina la solución de copias de seguridad y réplicas de Veeam y sus últimas novedades.
>> Más info
