Un editor visual guarda el diseño de una página en la base de datos. Un repositorio guarda el mismo diseño como código. Ninguna de las dos copias nace por error. El editor da edición inmediata a quien no programa. El repositorio da historial, revisión y despliegues repetibles. Cuando un mecanismo intenta tener las dos al día, cada guardado reabre la misma pregunta sobre cuál manda.
Qué es una fuente de verdad en la práctica
Una fuente de verdad es el lugar cuyo valor gana cuando dos lugares discrepan. Dicho en operativo, para cada dato existe un único sitio donde una persona lo escribe, y todos los demás lo leen, lo derivan o lo guardan como copia que nunca se reaplica sola.
Un dato puede ocupar tres papeles. La tabla los separa.
| Papel | Se escribe a mano | Se puede reaplicar de forma automática | Ejemplo |
|---|---|---|---|
| Fuente | Sí, en un único sitio | No aplica | La maquetación de una página en el editor |
| Derivado | No | Sí, se recalcula cuando cambia la fuente | Un índice, un mapa de relaciones, un fichero de resumen para agentes de IA |
| Copia de seguridad | No | No, solo por orden humana y con comprobaciones | Una exportación periódica del contenido |
El fallo aparece cuando una copia de seguridad se comporta como una segunda fuente. Escribe sobre la primera sin que nadie lo pida, o la primera la sobrescribe a ella en cada guardado. Desde ese momento hay dos fuentes y ningún árbitro.
Cuándo se genera el problema
Se genera con una intención razonable. Alguien quiere que el contenido del editor viva también en git, o que el código pueda reconstruir una página si la base de datos se pierde. Las señales de que ya se cruzó la línea son bastante reconocibles.
- Existe un comando que vuelca código al editor y otro que hace el camino inverso.
- Un guardado en el editor dispara una tarea que escribe en el repositorio.
- Aparecen commits que ninguna persona escribió.
- Los desajustes entre las dos copias se resuelven caso a caso, preguntando cuál era la buena.
- Alguien duda antes de guardar un cambio en el editor por lo que pueda regenerarse después.
- El código lleva escritos valores que solo tienen sentido en una instalación, como direcciones locales o identificadores de registros.
Basta una de ellas. Dos o más indican que el sistema ya paga el coste de la doble fuente sin cobrar su beneficio.
Método paso a paso
1. Inventariar los datos con doble vida
Se recorre el sistema y se lista cada dato que existe en más de un sitio. El alcance supera a las páginas. Entran los textos de plantillas, los menús, las opciones de configuración, los catálogos y los valores por defecto. Para cada uno se anota dónde se escribe hoy, dónde se lee y quién lo cambia.
2. Asignar una fuente a cada dato
La asignación sale de dos preguntas. Quién lo cambia y con qué frecuencia. Lo que cambia una persona sin perfil técnico, a menudo, es del editor. Lo que cambia un desarrollador al ritmo de los despliegues es del código.
El último nodo recoge un caso frecuente. Un valor tiene un defecto razonable en el código y un administrador puede cambiarlo. La regla es que lo guardado por la persona siempre gana, y el código solo rellena lo que falta.
3. Cortar la ruta de vuelta
Una fuente única exige que las demás copias no puedan escribir sobre ella. Se retiran el comando que regenera el contenido del editor desde el código y el que congela el contenido del editor en código. Se retira también el programador que los lanzaba. Si queda una sola ruta de escritura automática entre ambos lados, la doble fuente sigue viva.
4. Sustituir la sincronización por copias versionadas
Lo que el código hacía a la fuerza, guardar el estado del editor para poder recuperarlo, lo hace mejor una copia de seguridad con propiedades concretas.
- Exporta el estado completo a un formato legible, con un fichero por unidad de contenido.
- Calcula una huella del conjunto. Si la huella no cambió, no se guarda nada y el historial no se llena de duplicados.
- Aplica una retención con límite de tiempo y conserva siempre la copia más reciente.
- Vive en un repositorio propio, separado del código, de modo que la historia del contenido no se mezcla con la de las funcionalidades.
- Deja fuera lo que no debe versionarse, como usuarios, licencias, claves y envíos de formularios.
- Restaura cada elemento sobre su mismo identificador, y solo en la instalación que generó la copia, porque los identificadores pertenecen a cada base de datos.
- Crea una copia del estado actual antes de restaurar, y si esa copia falla, no restaura.
La diferencia con la sincronización es de dirección. La copia mira siempre hacia atrás. Nunca se aplica por sí sola.
5. Comprobar que la restauración funciona
Una copia que nadie ha restaurado es una hipótesis. Se cambian varios elementos de una instalación de prueba, se borra uno, se restaura y se compara la huella resultante con la de la copia original. Si coinciden, la restauración queda demostrada para ese entorno. Si el único entorno probado es el local, así se anota, porque producción puede comportarse distinto.
6. Vigilar la divergencia que queda
Con una sola fuente, la divergencia posible es entre la fuente y sus derivados. Se detecta comparando el derivado con lo que generaría la fuente, con ejecución a intervalos regulares o antes de cada entrega. También se vigila la propia copia de seguridad. Un bloqueo huérfano o un proceso que muere sin avisar dejan al sistema sin copias recientes, y nadie se entera hasta que hacen falta.
Errores típicos
- Sincronizar en los dos sentidos. Resuelve el miedo a perder contenido y crea dos fuentes. La recuperación se resuelve con copias que miran hacia atrás.
- Dar por buena una copia que nadie restauró. Una exportación completa puede ser inservible si un campo no se escribió bien al volver.
- Dejar que un comando falle en silencio. Un mecanismo de respaldo que, ante un error de entorno, escribe una versión reducida y registra éxito es peor que no tener ninguno.
- Versionar secretos junto al contenido. Las copias viajan a un repositorio y de ahí a más sitios. Las claves, los usuarios y las licencias se quedan fuera por definición.
- Copiar identificadores entre instalaciones. Una copia solo se aplica donde nació. En otra base de datos el mismo número apunta a otro registro o a ninguno.
- Confundir fuente y vista. Un fichero de resumen, un índice o un mapa de relaciones se calculan. Editarlos a mano reabre el problema.
- Dejar documentos del flujo antiguo con apariencia de vigentes. Un documento que cita comandos retirados lleva a alguien a ejecutarlos. Se archivan con una advertencia o se actualizan.
Criterio de decisión
| Situación | Fuente | Comentario |
|---|---|---|
| Un equipo editorial cambia las páginas varias veces por semana | Editor | Copias de seguridad con huella y retención |
| La página se genera a partir de un catálogo de datos | Datos o código | El editor no la toca, y si la toca, el cambio se pierde por diseño |
| Un valor tiene un defecto razonable y una persona puede cambiarlo | Opción guardada | El código solo rellena lo que falta |
| El mismo diseño debe ser idéntico en varias instalaciones | Código | El editor lo muestra, pero no lo guarda |
| Un dato se calcula a partir de otro | La fuente del dato original | El derivado se regenera, nunca se edita |
| Hace falta un plan de recuperación | Ninguna, es una copia | Exportación periódica, restauración probada |
Si una fila no encaja, la pregunta de fondo sigue siendo la misma. Quién escribe este dato, y qué pasa si otra copia dice algo distinto.
Del caso al principio
El método se aplicó a una web con varias decenas de landings cuyo diseño se mantenía en dos sitios, y la sincronización automática acabó produciendo más trabajo del que evitaba. El detalle de lo que falló, de la auditoría que lo midió y de lo que ocupó su lugar está en Retirar el generador de landings.
Del caso se extrae una regla de diseño. Un mecanismo que protege el contenido debe poder equivocarse sin tocar la fuente. Una copia de seguridad cumple esa condición y una sincronización bidireccional no. La regla se escribió además en el fichero de instrucciones que lee el agente de IA en cada sesión, que se desarrolla en Programar con un agente de IA, y aplica de forma natural al patrón de monorepo multi-marca, donde los identificadores de contenido pertenecen a cada sitio.