Cómo lograr que un sitio Drupal se reconstruya desde una base de datos vacía

En corto: un sitio Drupal se puede reconstruir cuando cada parte tiene un lugar que se puede nombrar. El código y la configuración viven en git. El contenido del que dependen las páginas también vive en git, en archivos de semilla (seeds). El contenido del día a día de los editores y los archivos subidos viven en un respaldo que alguien ya restauró. Con eso, cuatro comandos convierten una base de datos vacía en el sitio. Lo comprobamos en nuestro propio sitio, tecnocratica.com.co, el 30 de septiembre de 2026 y otra vez el 2 de octubre: lo que se construyó desde el repositorio coincidió con producción campo por campo, en los dos idiomas. Abajo va cómo funciona, qué revisaríamos en su página web, y qué demuestra esta prueba y qué no.

¿Su sitio depende de una sola persona?

Si solo una persona sabe desplegarlo, el sitio es de esa persona, no suyo. La prueba es sencilla: tomar una copia, dejarle la base de datos vacía y ver si el repositorio alcanza para volver a levantarla. En nuestro sitio son cuatro comandos:

1. drush site:install --existing-config: instala Drupal con la configuración guardada en el repositorio.
2. drush deploy: el despliegue estándar de Drush. Corre las actualizaciones de la base de datos, importa la configuración, reconstruye las cachés y corre los deploy hooks, en ese orden.
3. drush tecnocratica:seed: crea, desde archivos del repositorio, el contenido del que depende el sitio.
4. drush tec:release-sync: trae desde GitHub las notas de versión de los proyectos, que se publican allá.

Si el resultado es producción, el sitio le pertenece a su repositorio. Si no, la diferencia es justo lo que se perdería el día que esa persona se vaya.

¿Por qué separar el sitio en cuatro corrientes?

Un sitio Drupal no tiene una sola fuente de verdad. Tiene cuatro, y cada una se mueve en su propia dirección:

• El código (PHP, plantillas, dependencias) vive en git y viaja en un solo sentido: del desarrollador, pasando por CI, a producción.
• La configuración (tipos de contenido, campos, vistas, ajustes) se exporta a archivos en git y viaja igual.
• El contenido (páginas, imágenes, traducciones) lo escriben los editores en producción. Solo baja, cuando se llena una copia local desde producción. Nunca sube como una base de datos copiada encima.
• Los archivos subidos también se quedan en producción, y solo bajan.

Por qué le sirve: la historia típica de "se me perdió el trabajo" empieza por copiar una base de datos completa de un ambiente a otro. Con las corrientes separadas, un despliegue cambia el código, la configuración y el contenido que es del código, y deja quieto el trabajo de los editores. Nadie tiene que pedirles que paren.

¿Qué es "configuración como código"?

Drupal puede exportar su configuración en archivos YAML e importarla en otro ambiente: es su propia gestión de configuración. En nuestro sitio, config/sync tiene 784 de esos archivos (al 27 de octubre de 2026), y cada despliegue los importa. Cambiar un campo es exportar el cambio, hacer el commit y dejar que el despliegue lo aplique. Nadie lo cambia a mano en producción.

Dos reglas lo mantienen honesto:

• Antes de un despliegue que agrega o quita un módulo, llenamos una copia local desde producción, corremos drush deploy con el código nuevo y exigimos que drush config:status no muestre diferencias. Ese ensayo atrapa las importaciones que de otro modo solo fallarían en producción.
• Un sitio reconstruido no es una copia idéntica byte por byte. La página de inicio y las imágenes del encabezado apuntan a identificadores de la base de datos, y una base nueva reparte los suyos. El sembrador corrige esas referencias por nombre, así que en un sitio reconstruido la revisión de configuración marca esos pocos elementos como distintos, a propósito. En producción no marca nada.

¿Y el contenido, dónde queda?

El contenido del que dependen las plantillas y la marca va en archivos de semilla: la página de inicio, los menús, las redirecciones, las páginas de aterrizaje con sus secciones, cada proyecto y testimonio, cada traducción al español y las ilustraciones. Un script escribe las semillas desde el sitio en vivo. Recorre los campos de cada tipo de contenido, así que un campo que se agregue mañana se exporta y se siembra sin tocar el script. Ninguna semilla lleva un identificador de base de datos: una página se encuentra por su tipo y su título, una imagen por su nombre.

Cada valor tiene dueño:

• El código es dueño de las imágenes, los menús, las redirecciones y la página de inicio. El sembrador los restaura cada vez que no coinciden.
• El editor es dueño del texto una vez existe. El sembrador lo llena mientras está vacío y nunca lo sobrescribe. Lo que se reescriba en producción vuelve al repositorio la próxima vez que se extraen las semillas.

El sembrador corre en cada despliegue, y una segunda corrida no cambia nada. Hay cosas que nunca van en una semilla, a propósito: lo que los visitantes le dijeron al sitio (los contactos y las conversaciones del concierge) y las fotos de personas reales. Eso se queda en la base de datos y en sus respaldos. Así lo pide también el Habeas Data: los datos personales no se reparten en un repositorio.

¿Por qué nunca escribimos update hooks?

Drupal le permite a un módulo traer un update hook: código que corre una vez por sitio y queda marcado como hecho para siempre. No lo usamos en ningún módulo nuestro, por tres razones:

• No repara. Si alguien borra por error un término o un enlace del menú que ese hook creó, no vuelve, porque el hook ya corrió.
• Se queda viejo. Solo cubre lo que existía el día que corrió.
• Cada corrección pide otro hook. Nuestro propio sitio había acumulado once deploy hooks antes de que los reemplazáramos por sembradores el 2 de octubre de 2026.

La regla se hace cumplir, no se recomienda. Nuestra plantilla pública la registra como la decisión D25, y sus pruebas fallan ante cualquier update hook, post-update o deploy hook, así que un sitio no puede construir una imagen que lo traiga. Las actualizaciones propias del núcleo de Drupal y de los módulos contribuidos sí corren en cada despliegue: es el primer paso de drush deploy.

¿Qué revisaríamos en su sitio?

Una auditoría, o la incorporación que deja un sitio listo para un plan de mantenimiento, arranca con estas preguntas. Las hacemos sobre su repositorio y sobre una copia de su sitio, nunca sobre producción:

• ¿La configuración está en git, y drush config:status sobre una copia de producción sale sin diferencias?
• ¿Alguien distinto de la persona de siempre puede desplegar, con un comando, desde CI?
• ¿Cuántos update hooks y deploy hooks tiene su código a la medida, y qué crean?
• ¿De dónde salen la página de inicio, los menús, las secciones de las páginas de aterrizaje y las traducciones? Si la respuesta es "de la base de datos", una reconstrucción los perdería.
• ¿Qué archivos existen solo en el servidor?
• ¿Alguien ya restauró su respaldo? ¿Dónde y cuándo?
• ¿Dónde están escritas las claves y quién las tiene?

Después intentamos la reconstrucción sobre una copia y anotamos cada diferencia. Esa lista es el primer hallazgo de la auditoría, y es suya, nos contrate o no para el trabajo. Más en cómo trabajamos y en nuestra oferta.

¿Cómo se demuestra?

Construyendo el sitio desde cero y comparándolo con producción, entidad por entidad. Leer las semillas no demuestra nada. Nuestro script de auditoría lo hace sobre una copia local, y nunca escribe en producción:

1. Llena una copia local desde producción y exporta las semillas desde ella.
2. Corre el sembrador sobre esa copia. No puede cambiar nada.
3. Vacía la base de datos, instala desde la configuración guardada, despliega y siembra dos veces (la segunda no puede cambiar nada). Luego compara el resultado con producción. Las referencias se comparan por aquello a lo que apuntan, y las imágenes por una huella de su contenido.

La primera corrida, el 30 de septiembre de 2026, falló. Los sembradores escritos a mano que teníamos habían pasado todas las revisiones que a alguien se le ocurrieron, y la construcción ni siquiera terminó de instalarse. La corrida mostró lo que vivía solo en producción:

• la página de inicio;
• las secciones de las páginas de aterrizaje;
• todas las traducciones al español fuera de los proyectos;
• los textos de los testimonios;
• diez ilustraciones que existían solo en la carpeta de archivos de producción;
• los menús y las redirecciones.

Todo eso pasó a las semillas. El 2 de octubre de 2026 la auditoría se volvió a correr sobre una copia fresca de producción, y lo construido desde el repositorio quedó igual a producción campo por campo.

¿Qué no demuestra?

• No es un respaldo. Una reconstrucción reproduce la estructura y el contenido del que depende el sitio. En un sitio donde los editores publican todos los días, sus artículos vuelven desde un respaldo de la base de datos, y solo una restauración demuestra que ese respaldo sirve. Nuestras restauraciones se ensayan aparte; el primer ensayo completo fue el 18 de septiembre de 2026.
• Tiene fecha. Demuestra que el repositorio coincidía con producción el 2 de octubre de 2026. Un sitio cambia cada semana, así que la prueba se repite; no se enmarca.
• Deja por fuera lo que debe quedar por fuera. Los contactos, las conversaciones y las cuentas del equipo no están en git. Tampoco las claves (la contraseña de la base de datos, el hash salt). Esas vuelven desde sus propias copias protegidas.
• Es por sitio. Este es el registro de tecnocratica.com.co. No lo afirmamos de ningún sitio hasta que la auditoría haya pasado allí.

Si quiere saber si su sitio sobreviviría a una base de datos vacía, escríbanos o pregúntele al concierge en la página de inicio. Una hora con el fundador cuesta 75 dólares.