fm-explode: versionar FileMaker con Git de verdad

Un archivo .fmp12 es una caja negra binaria. No se puede ver qué ha cambiado, no se puede revisar un cambio antes de aplicarlo y, si dos personas tocan lo mismo, no hay fusión que valga.

Durante años esa fue la parte incómoda de trabajar con FileMaker: una herramienta enorme para construir aplicaciones de negocio, pero atada a un formato que Git no entiende. La “versión anterior” era una copia del archivo con la fecha en el nombre. Todos hemos estado ahí. Este artículo cuenta cómo cambia el panorama cuando la solución se descompone en texto, y cómo encaja eso en la forma en que ya trabajamos.

Por qué Git no sabe qué hacer con un .fmp12

Git está pensado para texto. Compara líneas, muestra qué se ha añadido y qué se ha quitado, y permite combinar el trabajo de varias personas cuando tocan zonas distintas. Con un archivo binario, lo único que puede decir es “ha cambiado” o “no ha cambiado”. No sabe dónde, ni qué, ni por qué.

En la práctica, eso significa que dos desarrolladores no pueden trabajar sobre la misma solución con garantías, que nadie puede revisar un cambio ajeno antes de que entre, y que el historial de la aplicación vive en nombres de fichero con fechas. Funciona mientras trabaja una sola persona con cuidado. Se complica en cuanto hay equipo, o cuando hay que saber qué se tocó hace tres semanas.

La idea: descomponer la solución en piezas de texto

La idea detrás de fm-explode es simple: descomponer la solución en piezas de texto (scripts, layouts, esquema) para que Git pueda hacer su trabajo. Dicho así parece poco, pero es lo que lo cambia todo, porque cuando el cambio es texto, lo demás aparece solo:

• Diffs legibles. Se ve qué líneas de un script se han añadido o eliminado, igual que en cualquier proyecto de código.
• Historial real. Queda registrado qué tocó cada persona y cuándo, en lugar de deducirlo de copias del archivo.
• Revisión antes de integrar. Un cambio se puede mirar, comentar y aprobar antes de que pase a la versión buena.

Si trabajas con FileMaker desde hace tiempo, piensa en lo que supone poder abrir un script y ver exactamente qué se modificó entre una versión y otra, sin abrir dos copias del archivo una al lado de la otra.

Cómo encaja en nuestro flujo

Para nosotros encaja con cómo ya trabajamos. Cuando el proyecto lo pide, ese texto se publica en nuestro Gitea autoalojado, junto al resto de proyectos; cuando no, el historial se queda en la herramienta que lo gestiona. FileMaker deja de ser la excepción rara que se gestiona a mano y pasa a tener el mismo tratamiento que cualquier otro desarrollo: repositorio, historial y revisión.

Esto importa más de lo que parece cuando una consultora lleva varios proyectos a la vez. Tener un solo sitio donde vive todo el código, incluido el de FileMaker, reduce lo que hay que recordar y lo que se puede perder. Si te interesa cómo montamos nuestra propia infraestructura de apoyo, lo contamos en sistemas y cloud, y lo que hacemos con la plataforma en aplicaciones a medida con FileMaker.

Cómo lo hacemos en la práctica

En cada solución en la que trabajamos hay un script que hace el explode. Guarda una copia de la solución en XML, que es una función que FileMaker ya trae, y se la pasa a una pequeña herramienta local que la reparte en carpetas de texto: un fichero por script, por layout, por tabla, por función personalizada, por lista de valores. Lo lanzamos desde el propio FileMaker después de tocar el esquema o los scripts. Es un paso manual, pero es un solo paso.

Con eso en la mano, tres usos se han vuelto cotidianos:

• Saber qué lleva una migración. Cada explode queda marcado según el entorno del que sale, desarrollo o producción. Comparar el último de cada uno dice exactamente qué cambios van a viajar en la próxima subida a producción, en lugar de fiarlo a la memoria de quien hizo los cambios.
• Preguntar a la solución. Sobre ese texto mantenemos un índice que responde a preguntas que antes costaba una tarde contestar: quién llama a este script, qué se rompe si cambio este campo, qué ha cambiado desde tal fecha.
• Dar contexto a la IA. Cuando un agente de IA nos ayuda con una solución, lee primero esa versión en texto para entender cómo está montada antes de proponer nada. Es lo que contamos en Agentic FM: contexto antes que código.

Lo que no resuelve

No es magia y no resuelve los conflictos por ti. Si dos personas modifican la misma parte de un script, alguien tendrá que decidir cuál de los dos cambios se queda, como en cualquier otro proyecto con Git. La diferencia es que ahora puede verlo, en lugar de descubrirlo cuando algo deja de funcionar.

Tampoco convierte FileMaker en un entorno de desarrollo como cualquier otro: sigue siendo FileMaker, con su forma de construir y su propio ritmo. Lo que cambia es la capa de control alrededor del trabajo, no la forma de crear las pantallas ni la lógica.

Lo que nos llevamos

Pasar de “¿qué ha cambiado aquí?” a verlo en un diff cambia bastante la forma de trabajar en equipo. No es una mejora espectacular a primera vista, pero es de las que se notan cada semana: menos miedo a tocar, más facilidad para revisar y un historial en el que se puede confiar. Si tu solución FileMaker ha crecido y empieza a doler el control de versiones, escríbenos a través de contacto y lo hablamos. Y si ya lo tienes resuelto de otra manera, nos interesa saber cómo.