Nuestro ciclo de entrega es el mismo cada vez.
1. Definir el alcance desde un esqueleto. Empezamos desde
drupal-skeleton (o rust-skeleton para aplicaciones de escritorio).
Heredamos DDEV, PHP 8.3, MariaDB 11.4, Composer + Node 20, y una prueba de humo en verde desde el primer
día. Sin el sprint de «montemos el entorno de desarrollo local».
2. Modelar el contenido primero, la interfaz después. Los tipos de contenido, los campos, las taxonomías y los modos de visualización se bosquejan como YAML antes de dibujar una sola plantilla. El modelo de contenido sobrevive a las reescrituras de plantillas; las plantillas no sobreviven a los cambios del modelo de contenido.
3. Sembrar desde CSV, validar desde CSV. El contenido real llega como
hojas de cálculo. Una superficie Drush de cuatro comandos — import, export,
diff, commit — da a los operadores una superficie de trabajo plana, comparable y comentable,
y da a los desarrolladores la garantía de que el sitio se reconstruye
textualmente desde esos archivos.
4. Desplegar desde GHCR. GitHub Actions construye una imagen OCI en cada
push; los despliegues con clave SSH hacia un único VPS con Traefik al frente hacen pull y recrean.
Los despliegues que cambian el esquema destruyen y reinstalan — sin la deriva de hook_update_N
huérfanos.
5. Retroalimentar hacia adelante. Cuando el proyecto se entrega, cada lección que vale la pena conservar vuelve al esqueleto. El siguiente proyecto empieza con todos los valores por defecto de este, ganados a pulso.
Hemos usado este ciclo en una propiedad bilingüe de Drupal Commerce (Mon Petit Café, Bogotá), en un tema Drupal three.js de calidad contrib, en una aplicación de escritorio de Windows para matrices, en una integración de agente de voz de ElevenLabs. Las constantes viajan; los detalles específicos no.