Saltar al contenido principal

Entrega a Certificación mediante RFC

El Ministerio de Educación Nacional (MEN) gestiona todos los cambios sobre sus ambientes con el formato de Requerimiento de Cambio (RFC) ST-FT-07 v4, vigencia 2026. Toda solicitud de cambio, despliegue o integración sobre los ambientes del Ministerio debe presentarse con este formato.

Descargar formato RFC ST-FT-07 v4 (xlsx) · RFC diligenciado de la entrega de los cinco componentes (xlsx)

Ámbito

  • Aplica a la entrega final al cliente para despliegue en Certificación (https://applicationcert.colombiaaprende.edu.co).
  • En Certificación el equipo de desarrollo tiene solo acceso de consulta vía VPN; no ejecuta ninguna acción directa. La implementación la realiza el equipo técnico del MEN (OTSI) a partir del RFC diligenciado.
  • El RFC no sustituye el runbook interno de despliegue a Pruebas (Procedimiento): ese runbook sigue siendo la fuente de los pasos técnicos, y de él se derivan las hojas "Implementación" y "Rollback" del formato.
  • El código se entrega por el GitLab de MinEducación (rama de entrega); el RFC referencia esa entrega.

Estructura del formato

HojaContenido
RFCFormulario principal: registro, clasificación, categoría, afectación, tipo y efecto del cambio, descripción, justificación, riesgo, impacto en CI, responsables
ImplementaciónPlan paso a paso de la implementación (ítem, sistema, ambiente, actividad, responsable, duración, fechas)
RollbackPlan de reversa con los mismos campos más tiempos de indisponibilidad
MatrizMatriz de evaluación del efecto del cambio (15 preguntas puntuadas: experiencia previa, infraestructura impactada, tiempo fuera de servicio, complejidad, seguridad)
GlosarioDefiniciones: tipos de cambio (Estándar, Normal, Emergencia), Elemento CI, actividades paralelas, duración efectiva, tiempo muerto

Guía de diligenciamiento para este proyecto

Valores que corresponden a una entrega típica del Campus Virtual (los cinco componentes del Manifiesto de entrega, o un subconjunto):

Sección del RFCValor para este proyecto
1. RegistroFecha/hora de la solicitud; número de ID de gestión de cambio asignado por el MEN. "Incidente - Falla No." solo si el cambio responde a un incidente reportado
2.1 Tipo de ambienteCertificación
3. CategoríaAplicaciones
4. AfectaciónIndisponibilidad: NO para instalación/actualización de plugins y tema (la ejecución de upgrade.php activa brevemente el modo mantenimiento de Moodle; si el MEN lo considera indisponibilidad, estimar minutos, no horas)
5. Tipo de cambioNormal para una entrega nueva. Cuando el procedimiento ya esté preaprobado y completamente documentado por el MEN, podrá tramitarse como Estándar (ver Glosario del formato)
6. Efecto del cambioSegún la hoja Matriz; para esta entrega el resultado esperado es Bajo (sin cambios de esquema en tablas core, sin modificación del núcleo de Moodle, rollback documentado)
7. Fecha de ejecuciónVentana acordada con el MEN; duración estimada de la actividad: suma de la columna de duración de la hoja Implementación
8. Descripción del cambioComponentes y versiones exactas del Manifiesto, p. ej. "Instalación/actualización de theme_cdigital (2026072702), local_pccntr8203403_dashboard (2026072700), local_pccntr8203403_aitutor (2026072100), block_pccntr8203403_logros (2026071400), block_pccntr8203403_atencion (2026072700) sobre Moodle 5.1 (APP158C)"
9. Justificación y beneficiosRequerimiento de los tres alcances del proyecto (gamificación, dashboard de aprendizaje, integración IA); enlazar los documentos soporte
10. RiesgoBajo: no se modifica el core de Moodle; los componentes son plugins estándar con desinstalación limpia; backup previo de base de datos obligatorio (paso 1 del plan de implementación)
11. Impacto en otros sistemas (CI)Elemento CI: Aplicativos — APP158C (Campus Virtual Colombia Aprende). Sin impacto en otros CI: los plugins no consumen servicios externos del MEN, salvo el servicio del tutor IA si la entrega incluye local_pccntr8203403_aitutor configurado
12. Capacitación al usuario finalNO para el usuario final. Para gestores de curso, la Guía para gestores cubre la operación de gamificación sin capacitación presencial
13. ¿Implica actualizar la documentación? — esta documentación (sitio Docusaurus) se actualiza con cada entrega
14. ResponsablesResponsable técnico (LT): líder técnico del equipo de desarrollo. Ejecutor del cambio (EJ): equipo técnico del MEN (OTSI). Responsable funcional: según designe el MEN

Hoja "Implementación" — plan modelo

El plan se redacta para que lo ejecute el equipo del MEN sin intervención del equipo de desarrollo: sin rutas de máquinas nuestras, sin llaves SSH nuestras. Deriva del Procedimiento de despliegue con estas equivalencias: el código no se copia por rsync desde una máquina del desarrollador, sino desde la rama de entrega del GitLab de MinEducación; los assets llegan ya compilados en esa rama (Build de assets se hace antes de la entrega, nunca en el servidor).

Modelo de filas (Sistema: Campus Virtual (APP158C) · Ambiente: Certificación · Responsable: Ejecutor MEN):

ÍtemDetalle de actividadDuración (min)
1Backup de la base de datos moodle (mariadb-dump --single-transaction) y verificación del tamaño del dump15
2Actualizar el árbol de código desde la rama de entrega del GitLab (git fetch + git checkout <tag/rama de entrega>), que afecta únicamente public/theme/cdigital/, public/local/pccntr8203403_dashboard/, public/local/pccntr8203403_aitutor/, public/blocks/pccntr8203403_logros/, public/blocks/pccntr8203403_atencion/10
3Restaurar propietario y permisos del árbol de código según el esquema del ambiente5
4Ejecutar php admin/cli/upgrade.php --non-interactive dentro del contenedor web10
5Ejecutar php admin/cli/purge_caches.php (recompila SCSS del tema y recarga plantillas)5
6Confirmar tema activo cdigital y ajustes (Administración del sitio → Apariencia)5
7Verificación post-despliegue: versiones en mdl_config_plugins, Web Services, logs PHP, carga de /my/, /my/courses.php y un curso (Verificación)20

El orden de instalación de componentes es transparente para el ejecutor (una sola actualización de código + un solo upgrade.php procesa los cinco componentes en el orden correcto de dependencias: Moodle instala primero los plugins locales de los que dependen los bloques y el tema).

Hoja "Rollback" — plan modelo

Deriva de Rollback. Se ejecuta si la verificación (ítem 7) falla:

ÍtemDetalle de actividadDuración (min)
1Restaurar el dump de base de datos tomado en el ítem 1 de la implementación20
2Revertir el código a la versión previa (git checkout del tag anterior de la rama de entrega)10
3php admin/cli/purge_caches.php y reinicio del contenedor web si el CSS/JS no refresca10
4Verificación de la versión previa: carga de páginas clave y logs sin errores15

Lista de verificación antes de radicar el RFC

  1. Versiones de version.php de los componentes entregados coinciden con el Manifiesto de entrega y con la sección 8 del RFC.
  2. Assets AMD/SCSS compilados e incluidos en la rama de entrega del GitLab.
  3. Hojas Implementación y Rollback diligenciadas con fechas, responsables del MEN y duraciones reales.
  4. Hoja Matriz respondida y puntaje de efecto coherente con la sección 6.
  5. Documentación (este sitio) actualizada: fichas del Catálogo, páginas de Operación y CHANGELOG.md de la entrega.
  6. La rama/tag de entrega no incluye ningún dato ni dump de Local ni de Pruebas — solo los cinco componentes de código. Ver qué NO incluye la entrega.