El equipo despliega de madrugada y nunca los viernes
Sospecho que el equipo no confía en la vuelta atrás si siempre despliega de madrugada y evita los viernes, sobre todo si nadie puede explicar otra razón operativa para esa ventana.
Moodle · Ingeniería
Integración y despliegue continuos en Moodle
Ante el miedo a desplegar, compruebo cuatro posibles causas: falta el inventario de lo que sube en cada despliegue, faltan comprobaciones automáticas superadas de antemano, el entorno de pruebas no se parece al de producción o no existe una forma ensayada de volver atrás. Resuelvo esas cuatro carencias para reducir la improvisación y dejar ensayadas las respuestas ante esos fallos; el riesgo residual se identifica y se acepta por separado. En una plataforma Moodle controlo, además del código, la versión del núcleo, las extensiones, la configuración y los pasos de actualización de la base de datos. No doy por reversibles sus efectos. Si el cambio no incluye un procedimiento específico de reversión probado con éxito, solo vuelvo atrás mediante una restauración.
- Versiono el núcleo o su referencia exacta, las extensiones y la configuración declarativa. Las credenciales, claves y demás secretos quedan fuera del repositorio.
- Las comprobaciones automáticas se ejecutan antes de que nadie revise, no después de desplegar.
- El entorno de pruebas debe reproducir la versión, las extensiones, el volumen y la forma de los datos con muestras sintéticas o desvinculadas de la identidad y con controles equivalentes; no necesita copiar datos personales de producción.
- Los cambios de base de datos no se deshacen solos: la vuelta atrás hay que diseñarla aparte.
Experiencia en ingeniería
Mantengo el código y la configuración declarativa bajo control de versiones y ejecuto comprobaciones automáticas en cada cambio. Reproduzco el despliegue en un entorno de pruebas representativo, registro la versión de producción y ensayo la vuelta atrás, incluidas las actualizaciones de base de datos, las cachés y las tareas en segundo plano.
Mi trayectoriaCuándo se nota que falta
Estas cuatro señales me indican que la costumbre decide los despliegues.
La versión de producción no está registrada
Encuentro en la instalación cambios que no constan en ningún sitio. Alguien que ya no está los hizo a mano en algún momento.
El entorno de pruebas no sirve para probar
No doy por válido lo que compruebo en ese entorno: tiene otra versión, otras extensiones o cuatro cursos de ejemplo, y no me dice qué pasará.
Cada despliegue acaba en una incidencia
Subo los cambios sin medios para observar qué ocurre después. Algo se rompe y la primera señal me llega con la llamada de un usuario.
Las cinco piezas
Estas cinco piezas aparecen con frecuencia en aplicaciones con estado y resultan especialmente relevantes en Moodle. Las concreto para el núcleo, las extensiones, los pasos de actualización, el modo de mantenimiento y las tareas en segundo plano.
- 01
Código y configuración declarativa bajo control de versiones
Registro el núcleo —o la referencia a su versión exacta—, cada extensión y la configuración declarativa necesaria para reconstruir el entorno. Inyecto las credenciales y los demás secretos desde un gestor de secretos o mediante el mecanismo seguro de cada entorno.
- 02
Comprobaciones automáticas en cada cambio
Automatizo la comprobación del estándar de código, el análisis estático y las pruebas antes de la revisión humana. Lo que no supera esos controles no llega a esa revisión; así evito revisar manualmente incumplimientos de criterios ya acordados y codificados.
- 03
Entorno de pruebas representativo
Enumero los elementos de producción que debe reproducir el entorno: versión de la aplicación y sus dependencias, extensiones, configuración e integraciones críticas, perfil de recursos, datos representativos y minimizados, y recorridos de prueba. Sin una carga parecida a la prevista, no he detectado los problemas de rendimiento hasta producción.
- 04
Despliegue reproducible
Uso el mismo procedimiento en cada entorno, sin pasos manuales que dependan de la memoria de nadie. Incluyo en él el modo de mantenimiento y la actualización de la base de datos.
- 05
Vuelta atrás y seguimiento
En Moodle no doy por reversibles los cambios de esquema. Solo considero reversible un cambio si incluye un procedimiento específico de reversión y ese procedimiento funciona. En caso contrario, mido cuánto tarda una restauración antes de necesitarla. Después de desplegar el cambio, observo los errores, los tiempos de respuesta y las tareas en segundo plano durante el periodo acordado.
Lo que sale mal
Seis problemas que he encontrado al desplegar plataformas Moodle.
Actualizaciones de base de datos irreversibles
No intento deshacer una transformación de datos volviendo el código atrás, porque no funciona. Preveo cómo revertirla; si no lo hago, la única salida es restaurar.
Cachés que mantienen el comportamiento anterior
Despliego el código nuevo, pero la plataforma mantiene el comportamiento anterior hasta que purgo las cachés. Incluyo esa purga en el procedimiento y no dependo de que alguien la recuerde.
Tareas en segundo plano activas durante el despliegue
Antes del despliegue impido que comiencen tareas nuevas y compruebo qué procesos siguen activos. Espero a que terminen o aplico el mecanismo de cancelación segura definido para cada tarea; solo después cambio el código. Al finalizar, reanudo la planificación y verifico las tareas pendientes.
Configuración distinta entre entornos
Funciona en pruebas y no en producción por un ajuste que nadie replicó. Versiono la parte declarativa y comparo de forma segura los valores que dependen de cada entorno.
Despliegue parcial entre varios nodos
Con varios servidores web conviven versiones distintas durante unos segundos. Decido antes si eso es aceptable para el servicio o si desvío primero el tráfico.
Nadie mira nada después
Reconozco este patrón: el fallo aparece dos horas después, durante una tarea nocturna, y lo atribuimos a cualquier otra cosa.
Cómo decidir hasta dónde llegar
Planteo cinco preguntas para decidir cuánto invertir.
- 01
¿Cada cuánto se despliega?
Para calcular si compensa automatizar, tengo en cuenta la frecuencia de despliegue, pero no decido solo con ese dato. Incluso con dos despliegues al año, puedo considerar que compensa si el proceso manual es largo o arriesgado. Con despliegues semanales, comparo igualmente el coste de automatizar con el tiempo, los fallos y la capacidad de recuperación actuales.
- 02
¿Cuánto cuesta una parada?
Si el campus puede estar veinte minutos parado sin consecuencias, la ventana de mantenimiento es una herramienta válida. Si no, el despliegue tiene que poder hacerse sin cortar.
- 03
¿Se puede volver atrás hoy y cuánto tarda?
Si para volver atrás tengo que restaurar una copia, mido cuánto tarda realmente. Ese tiempo determina con qué tranquilidad despliego.
- 04
¿Hay un entorno donde equivocarse?
Sin un entorno que reproduzca las condiciones relevantes de producción, no considero completa ninguna inversión en automatización: la publicación automática pone en producción algo que no he podido probar.
- 05
¿Qué miro después de desplegar?
Si no reviso nada después, doy por terminado el despliegue al cabo de un tiempo, no tras comprobar que ha ido bien.
Diez comprobaciones sobre vuestro despliegue
Si fallan las tres primeras comprobaciones, no avanzo con las demás: dependen de esa base.
- Sé exactamente qué versión y qué extensiones hay en producción.
- El código y la configuración declarativa de producción están versionados; los secretos quedan fuera del repositorio.
- Existe un entorno de pruebas representativo de producción.
- Las comprobaciones automáticas se ejecutan antes de la revisión humana.
- El procedimiento de despliegue no depende de la memoria de nadie.
- Purgar cachés forma parte del procedimiento.
- Las tareas en segundo plano se detienen y reanudan de forma ordenada.
- Sé cuánto tardaría en volver atrás y lo he comprobado.
- Está definido qué se observa en la hora siguiente al despliegue.
- Puede desplegar más de una persona del equipo.
Qué cambia con la criticidad
Ajusto la inversión al coste de parar el servicio y a la frecuencia de las entregas.
- Despliegues esporádicos
En despliegues esporádicos y servicios de baja criticidad, puede bastar el control de versiones, un procedimiento escrito y una ventana anunciada, siempre que la recuperación necesaria esté comprobada.
- Entregas mensuales
Automatizo las comprobaciones y uso un entorno de pruebas representativo. Así reduzco más riesgo por cada euro invertido.
- Entregas frecuentes
Automatizo el despliegue, ensayo la vuelta atrás y defino qué observo después. Así convierto el despliegue en una rutina.
- Sistema que no puede parar
En los despliegues graduales hago convivir dos versiones durante un intervalo. Si esa convivencia no es aceptable, elijo y ensayo una estrategia que cambie el tráfico de forma coordinada.
Qué exigir sobre el despliegue en un contrato
Evito heredar una plataforma que solo el proveedor sabe desplegar.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Código y configuración declarativa versionados | Repositorio con el núcleo o su referencia exacta, las extensiones y la configuración declarativa; inventario del mecanismo de gestión de secretos | Reconstruir el entorno sin guardar credenciales ni claves en el repositorio |
| Comprobaciones automáticas | Comprobación del cumplimiento del estándar, análisis estático y pruebas en cada cambio | Ningún cambio llega a producción sin haber pasado las pruebas |
| Entorno de pruebas representativo | Versión de la aplicación, dependencias y extensiones; configuración e integraciones críticas; perfil de recursos; datos representativos y minimizados; y recorridos acordados | Las condiciones relevantes de producción están enumeradas y cada entrega se prueba en esas condiciones antes de pasar a producción |
| Procedimiento de despliegue reproducible | Automatización o script documentado sin pasos manuales | Lo ejecuta el equipo propio sin el proveedor delante |
| Vuelta atrás ensayada | Procedimiento y duración real medida | Reversión probada en el entorno de pruebas |
Tres costumbres que perpetúan el miedo
He visto estas tres costumbres pasar por prudentes, aunque en realidad impiden mejorar.
Desplegar menos veces
He comprobado que acumular cambios durante meses agranda cada despliegue y aumenta el riesgo. Cuando algo falla, me cuesta mucho más aislar cuál de los cuarenta cambios lo ha provocado.
Copiar ficheros a mano al servidor
Consigo que funcione, pero no dejo rastro de lo que he subido. Tampoco puedo repetir exactamente la misma operación en otro entorno ni deshacerla con garantías.
Probar en producción con cuidado
Sin un entorno que reproduzca las condiciones relevantes, compruebo los cambios con usuarios dentro. Por mucho cuidado que tenga, sigo sin un sitio donde equivocarme sin consecuencias.
Referencias
Fuentes y límites
- Documentación oficialInstalación desde el repositorio — documentación oficial
Gestión de la instalación mediante control de versiones y actualización desde el repositorio. Consultado el 1 de agosto de 2026.
- Documentación oficialModo de mantenimiento — documentación oficial
Cómo dejar la plataforma fuera de servicio de forma ordenada durante una actualización. Consultado el 1 de agosto de 2026.
- Documentación oficialHerramienta oficial de integración continua para extensiones
Conjunto de comprobaciones automáticas pensado para extensiones de la plataforma. Consultado el 1 de agosto de 2026.
Los tres niveles de madurez y el criterio para elegir entre ellos son propios, no una metodología publicada. Lo relativo a la instalación por repositorio, el modo de mantenimiento y las herramientas de comprobación está en la documentación oficial enlazada y conviene verificarlo allí, porque cambia entre versiones. El comportamiento de los pasos de actualización de base de datos depende de cada extensión: la afirmación de que no se revierten solos es general y admite excepciones cuando quien la desarrolló previó el caso.
Blog
Casos, pruebas y fuentes.
En el blog desarrollo casos particulares, pruebas y fuentes que amplían esta página de referencia.
Ir a blog.albertolarah.comContacto
Cuando desplegar sigue dando miedo
Miro con qué frecuencia se despliega, si todo está bajo control de versiones, en qué se parece el entorno de pruebas a producción y qué pasó la última vez que hubo que volver atrás. Con eso decido por dónde empezar.
hola@albertolarah.comLinkedIn ↗