Saltar al contenido
Alberto LaraAnálisis y arquitectura EdTech
Ir a la web
Dos configuraciones de componentes se conectan mediante una comprobación y un recorrido de retorno al estado anterior.

Operación y automatización· 5 min

Actualizar Moodle: compatibilidad, pruebas y vuelta atrás

Una matriz y un acta para relacionar cada requisito con el ensayo que permite aceptar una actualización.

AL

Una actualización de Moodle puede terminar sin errores y dejar fuera una actividad que el profesorado necesita el lunes. El núcleo arranca, pero falta un tipo de pregunta, una integración ya no matricula o una restauración devuelve los datos de un momento distinto al esperado. La comprobación útil sigue el recorrido académico completo.

Para decidir si una actualización está preparada, propongo reunir tres piezas: una matriz de compatibilidad, un ensayo con recorridos críticos y un acta de aceptación que incluya la recuperación. Son documentos de trabajo. Por sí solos no prueban que una instalación se haya actualizado correctamente.

Del pliego al ensayo

El pliego de mantenimiento de los portales de formación de Girona y Dipsalut, expediente 2026/2091 sitúa las pruebas en preproducción y la vuelta atrás dentro del trabajo de actualización, en su página 9. Esa exigencia plantea una pregunta que conviene resolver antes de fijar la ventana: ¿qué evidencia permitirá aceptar la entrega?

Mi propuesta es traducirla a comprobaciones concretas. Si el curso utiliza una actividad aportada por un complemento, su prueba debe llegar hasta la entrega, la calificación y la consulta posterior del resultado. Si depende de una identidad externa, entrar con una cuenta local de administrador apenas comprueba ese recorrido. Compras puede pedir una evidencia; dirección académica debe reconocer en ella el trabajo que necesita conservar.

Este enfoque amplía el marco de requisitos para una plataforma Moodle. El pliego citado es una fuente pública para analizar una necesidad institucional, no un proyecto en el que afirme haber intervenido.

La compatibilidad necesita versiones concretas

La guía oficial de actualización de Moodle 5.2 pide comprobar requisitos, ensayar sobre una copia del sitio y revisar los complementos. También recoge dos condiciones relevantes: el salto a 5.2 requiere partir de 4.4 o posterior, y al llegar desde 5.0 o anterior hay que atender a la reorganización de directorios introducida en 5.1.

Esas condiciones delimitan una ruta, pero no certifican el conjunto instalado. Una matriz útil identifica el componente y su versión exacta, la versión de destino, la evidencia de compatibilidad y el recorrido que depende de él. Incluye tema, autenticación, matriculación y tipos de pregunta, además de las actividades más visibles.

CampoDecisión que permite tomar
Componente y versión instaladaSaber qué se está evaluando, incluidas modificaciones locales
Versión de destino y dependenciasComprobar que existe una combinación soportada
Fuente y fecha de consultaVolver a comprobar una declaración del mantenedor
Recorrido afectadoRelacionar el componente con una tarea académica u operativa
Evidencia del ensayoDistinguir lo anunciado de lo observado
Responsable y decisión pendienteSaber quién resuelve una incompatibilidad antes del cambio

Una casilla sin información queda pendiente. Si el mantenedor no declara compatibilidad, hace falta investigar o probar; si la declara, sigue haciendo falta comprobar el uso local. Las modificaciones al núcleo merecen un registro separado porque pueden desaparecer o entrar en conflicto al sustituir el código. Ahí se encuentran las decisiones de desarrollo para Moodle con el coste de mantener una plataforma actualizable.

Elegir recorridos que permitan rechazar la entrega

Un ensayo necesita un resultado esperado suficientemente preciso para detectar un fallo. «El cuestionario funciona» deja demasiadas interpretaciones. «La persona de prueba entrega el intento, recibe la calificación prevista y el docente consulta esa misma calificación» permite contrastar tres observaciones.

Propongo seleccionar los recorridos con dirección académica y operación. Una convocatoria puede depender del acceso delegado, de un tiempo límite, de preguntas de un complemento y de la exportación posterior. Otro campus puede depender de una tarea con rúbrica o de la matrícula recibida desde un sistema externo. No existe una selección universal que sustituya ese conocimiento.

El entorno de ensayo debe conservar las características relevantes y aislar los efectos hacia fuera: correos, cobros, altas o notificaciones no deben alcanzar sistemas reales por accidente. Cuando se usan datos de producción, hay que aplicar las restricciones de acceso y el tratamiento de datos acordados. El acta recoge esas diferencias porque una prueba en una copia reducida no acredita el comportamiento bajo la carga real.

Además del recorrido correcto, interesa provocar un fallo controlado. Por ejemplo, una cuenta sin permiso no debería consultar una entrega ajena. La página de pruebas automatizadas del software desarrolla cómo repartir estas comprobaciones entre lógica, integración e interfaz.

La vuelta atrás también tiene un resultado que comprobar

La documentación de copias del sitio distingue base de datos, archivos subidos y código. Para una recuperación coherente hay que identificar qué conjunto se conserva y cómo se restaura. Recuperar únicamente el código anterior después de una transformación de la base de datos no debe tratarse como una reversión completa.

En el acta separo el tiempo objetivo de recuperación del tiempo medido. También separo la pérdida de datos admisible de la observada. Si se restaura una copia anterior a las últimas entregas, el campus puede volver a responder y haber perdido trabajo académico. Hay que comprobar ambas cosas.

El procedimiento debe fijar quién decide volver atrás, hasta cuándo es viable y cómo se tratarán las operaciones posteriores a la copia. Si intervienen otros sistemas, restaurar Moodle no deshace por sí solo una matrícula, un correo o una transacción enviados fuera. Esas dependencias forman parte de la decisión.

Plantilla descargable: matriz y acta

La plantilla de actualización y recuperación está en Markdown para poder completarla en un editor y conservar su historial. Incluye la matriz, el requisito con su fuente y página, el entorno, los recorridos, las evidencias, los tiempos y la decisión final.

Los resultados quedan sin completar. No se ha ejecutado una actualización de Moodle para producir este artículo y la plantilla no contiene cifras de rendimiento ni de recuperación atribuidas a una instalación. Cada equipo debe rellenarla con sus observaciones y adjuntar evidencias que otra persona pueda interpretar.

La aceptación puede quedar pendiente, condicionada o rechazada. Publicar una versión nueva del software no resuelve por sí solo esa decisión: la resuelve comprobar que el trabajo académico acordado sigue siendo posible y que existe una respuesta practicable si algo falla.

Conversar y compartir

¿Comentamos el artículo?

Escríbeme directamente para comentar cualquier punto técnico, compártelo si te ha parecido interesante o ábrelo en ChatGPT para contrastar ideas.

AL
Alberto Lara Hernández
Director tecnológico y arquitecto de sistemas de aprendizaje

Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.

Sobre Alberto Lara y su trayectoria profesional →

Seguir leyendo