Todo desarrollador de software tiene que abordar la tarea de desplegar en producción nuevas versiones del software con corrección de errores y la implementación de nuevas funcionalidades. Lo habitual es que se utilicen sistemas de control de versiones de código como GIT o SUBVERSION que permiten un control sobre la evolución del código y además facilitan la subida al servidor de producción del nuevo código.
 
Esto resuelve la actualización del código que define vistas y controladores pero, ¿y los datos?. En casi cualquier otra plataforma de desarrollo, la base de datos se encuentra separada del código que la consume, con lo que si la nueva versión no afecta a la estructura de datos, la base de datos no hay ni que tocarla, y los datos están de inmediato disponibles.
 
Ahora bien, Filemaker tiene la particularidad de que la base de datos, las vistas (presentaciones) y los controladores (guiones) se encuentran en el mismo archivo (fmp12). Entonces ¿cómo abordar los cambios de versión sobre desarrollos Filemaker?.
 
Ante todo la complejidad de esta tarea dependerá de cómo hayamos construido nuestro desarrollo y de la complejidad del propio sistema. No es lo mismo si tenemos datos e interfaz en el mismo archivo, que si hemos estructurado la solución con un modelo de separación de datos. Cada opción tiene sus pros y sus contras, pero no entraremos en ello. Asimismo, hay otros factores que influyen en la estrategia a utilizar, como la disponibilidad de tiempo para mantener el sistema no operativo.
 
Hacer los cambios directamente en la versión de producción.
 
Filemaker tiene la virtud de que nos permite editar la programación y el diseño estando la App publicada, de modo que si los cambios a realizar son menores (cambio en una presentación, modificación de un guión, incluso con creación de algún nuevo campo) los podemos realizar directamente en el archivo en producción una vez se ha testado suficientemente en una versión de desarrollo. Esta primera vía es muy práctica, pero si tenemos una red de Apps corriendo en distintos servidores (como por ejemplo el software comercial de una red de tiendas), es un trabajo que requiere mucho tiempo y cuidado.
 
Importar los datos sobre un clon de la nueva versión.
 
En este caso, lo que hacemos es generar un clon (versión sin registros) de la nueva versión de la App e importamos los datos desde la versión de producción. Si conocéis el asistente de importación de Filemaker sabréis que no facilita mucho las cosas cuando estamos trabajando con muchos campos, de modo que hay que tener mucha atención en la asociación de campos, el modo de importar, etc.
 
Además hay que revisar posteriormente tabla a tabla que no se ha quedado ningún registro por el camino ni producido ningún error. Además, hay que controlar los valores de los campos con autointroducción de valores secuenciales, comprobar que todas las cuentas de usuario quedan debidamente activadas, etc.
 
En cuanto a tiempos, si se trata de una App compleja, con decenas de tablas y miles de registros, perfectamente se puede llevar un par de horas de trabajo realizar la migración completa.
 
FM Data Migration Tool reduce la tarea de horas a minutos.
 
Con la versión 17 de Filemaker, tenemos disponible una herramienta de linea de comando llamada FM Migration Tool que reduce sensiblemente el tiempo y la complejidad a la hora de publicar una nueva versión de nuestra App.
 
No entraremos en este post en los detalles técnicos de su uso, pero de forma resumida realiza las siguientes tareas entre el archivo con datos “vivos” y la nueva versión a publicar:
 
  • Migra todos los datos de una sola vez en lugar de importar cada tabla por separado.
  • Asocia los campos entre el archivo fuente y destino de forma automática, en lugar de manualmente.
  • Migra las cuentas de usuario, las listas de valores personalizadas y los valores de autointroducción secuencial.
 
La utilidad funciona tanto en Mac OSX como en Microsoft Windows.
 
Gracias a esta nueva utilidad, el trabajo de publicar una nueva versión de la App se reduce a minutos, dependiendo del volumen de datos a migrar. En COCO Making DB llevamos utilizándola durante los últimos meses con éxito, reduciendo significativamente el esfuerzo de nuestro equipo a la hora de desplegar versiones para nuestros clientes.