LCS DB API: automatizando la copia de la DB de Prod a Dev

El nuevo endpoint de la LCS DB API para exportar una base de datos ha sido publicado! Con él ya tenemos una forma de automatizar el refresco de datos de tu Dynamics 365 FnO desde producción a un entorno de desarrollo Tier 1.

El problema con los bacpac #

Uno de los mayores inconvenientes que tenemos ahora mismo con mover datos desde producción es que no es algo precisamente rápido porque tenemos que:

• Refrescar un entorno Tier 2+ con los datos de Prod
• Exportar un bacpac del entorno Tier 2+
• Restaurar el bacpac en una VM Tier1

Esto es así porque los entornos Tier 2+ usan Azure SQL como motor de la DB, y las VM Tier 1 usan SQL Server. El tiempo que tada todo el proceso depende del tamaño de la base de datos y del rendimiento de la VM en la que vas a restaurar el bacpac. Pero no es un proceso rápido para nada. Para una DB de 60GB obtendremos un bacpac de unos 7GB que tardará:

• 1 a 2 horas en refrescar UAT con datos de Prod
• 2 a 4 horas para exportar el bacpac
• Por lo menos 4 horas en restaurar el bacpac en un Tier 1

Eso hace un total de entre 7 y 11 horas hasta que tienes la DB en una máquina de desarrollo. Una vez la tienes ahí puedes sacar el BAK rápido y compartirlo. Pero necesitas prácticamente el tiempo de un día de trabajo para tenerlo disponible. Como para tener prisa.

¡Sálvanos LCS DB API! #

Gracias al nuevo endpoint de la LCS DB API podemos hacer todos estos pasos automáticamente, y con las d365fo.tools será incluso más fácil. Pero antes… Debido a lo largo de todo el proceso primero tenemos que planificar como lo haremos (diariamente, semanalmente, etc.) y que ello sea compatible con nuestra cadencia de subidas a UAT/Prod, porque solo se puede ejecutar una operación a la vez. Y hay otro problema, pero lo veremos después de los scripts.

Mi propuesta #

Para poder hacer el último paso del flow de la LCS DB API de prod a dev necesitaremos una máquina virtual tipo Tier 1 donde restaurar el bacpac. Mi idea es usar la VM de build en la suscripción de Microsoft y un pipeline de Azure DevOps para ejecutar todos los scripts que restaurarán la DB en esa máquina. Es una máquina que tiene poco uso y nos va perfecta para esto. Quiero aclarar por qué he pensado en hacer esto con la VM de build. En la mayoría de los casos esta VM no hace nada por la noche, como mucho ejecutar algunos tests, y es durante este período cuando sugiero hacer todo esto. Pero tened en cuenta que dependiendo del tamaño de vuestra DB esto no se podrá hacer o os quedaréis sin espacio en 2 o 3 copias. Así que pensad si os va mejor desplegar otra VM y ponerle el agente, pero sobretodo no toqueteéis nada de la VM de build si no sabéis qué estáis haciendo! Probad esto en una VM de desarrollo o donde queráis si pensáis que podéis romper algo. Recordad que si rompéis la máquina de build os quedaréis sin la posibilidad de generar DPs o ejecutar pipelines! Este post es solo un ejemplo de una posible solución, necesitais decidir qué os va mejor en vuestro proyecto! Fin de la actualización. Como dije antes usaré las d365fo.tools de Mötz Jensen, podría hacerlo todo sin, usando llamadas REST pero sería un poco de tontos porque con las tools todo es más fácil, rápido y claro. He separado los pasos en 3 scripts de Powershell: ejecutar el refresco, exportar el bacpac y restaurar el bacpac.

Refrescar datos #

Este script lanza la copia de prod a un entorno Tier 2+:

Exportar la base de datos #

Con este paso lanzamos la exportación del bacpac del entorno Tier 2+ donde hemos restaurado prod:

Restaurar el bacpac #

Finalmente descargamos el bacpac en la VM de build y lo restauramos en una nueva base de datos:

Usandolos en un pipeline de Azure DevOps #

Esto es. Creamos un script de Powershell, lo guardamos en la VM de build y lo llamamos en el pipeline. Esto es sólo válido para el agente hospedado en la VM de build. Seguramente se pueda ejecutar todo en un agente de Azure, pero no lo voy a explicar porque pienso que usando la VM de build, donde podemos restaurar los datos, nos será más útil.

Tiempos #

Estos 3 scripts van a hacer las llamadas a la LCS DB API para refrescar, exportar y restaurar los datos. Pero tenemos un problema de tiempos. Como hemos visto, refrescar la DB lleva un tiempo, igual que exportarla. Necesitas encontrar una forma de controlar el estado de las operaciones. La LCS DB API nos ofrece una operación que nos permite obtener el estado de una actividad en marcha. Usando las d365fo.tools: Podemos controlar esto dentro de nuestro script de Powershell, pero su usamos el agente en la VM de build esto significa que no lo podemos usar para nada más mientras esto esté ejecutándose. Por eso he separado el proceso en 3 pasos. Puedes programar manualmente 3 pipelines, una para cada paso a las horas que sepas que ha terminado cada stage. Y así también se puede elegir el orden: exportar, restaurar, refrescar o refrescar, exportar, restaurar. También podríamos usar el Windows Task Scheduler y olvidarnos de los pipelines de AZDO, pero no lo haremos porque nos encantan los pipelines. Y eso es todo, al fin tenemos una forma de mover datos sin tener que hacerlo a mano, podemos programarlo pero necesitamos tomar antes algunas decisiones sobre cómo lo haremos. Y eso os lo dejo a vosotros 🙂