Migración de Sakai 2.4.x a Sakai 2.6.x Lecciones aprendidas

Presentación del tema: "Migración de Sakai 2.4.x a Sakai 2.6.x Lecciones aprendidas"— Transcripción de la presentación:

1 Migración de Sakai 2.4.x a Sakai 2.6.x Lecciones aprendidas
Dr. David Roldán Martínez Analista del ASIC Universidad Politécnica de Valencia

2 Érase una vez… Universidad Politécnica Valencia (UPV) Algunos números
Universidad Pública Líder en innovación y uso de la tecnología Cursos y titulaciones oficiales y no oficiales Algunos números 4 Campuses 15 Escuelas 40 Centros de Investigación 40 Títulos oficiales 20 Títulos de postgrado estudiantes 2.600 profesores 1.400 staff

3

4 Érase una vez… En el curso pusimos en explotación Sakai con el nombre de PoliformaT. Junto con la 2.1.2, hicimos algunos desarrollos propios.

5 Érase una vez… En el curso migramos a la versión 2-4-x.

6 Érase una vez.. En el curso acabamos de migrar a la 2-6-x.

7 ¿Qué será, será…? Futuro: ¿Sakai 3.0?

8 Gestión de cursos – Generación y sincronización
MATRÍCULA REPOSITORIO COURSE MANAGEMENT CONFIGURACIÓN GENERACIÓN SINCRONIZACIÓN

9 Gestión de cursos - Implementación
Hay tres formas de proporcionar datos a la CM: Sincronización a través de un trabajo de Quartz. Acceso directo a los datos de matrícula. Federación de múltiples fuentes de datos. Hay tres formas de proporcionar datos a la CM: Sincronización a través de un trabajo de Quartz: se trata de crear uno o varios trabajos de Quartz que sincronicen los datos de nuestros sistema con los existentes en las tablas de Course Management de Sakai. Reimplementación: consiste en acceder directamente a nuestros datos, para lo que hay que reimplementar el CourseManagementService. Federación de múltiples fuentes de datos: permite acceder en modo “sólo lectura” a fuentes externas de manera que es posible añadir o modificar datos procedentes de una implementación propia.

10 Control de actualizaciones
SERVIDORES DE EXPLOTACIÓN SVN FLAG DE DESPLIEGUE SERVIDOR INTERMEDIO

11 Se genera parche para Sakai_2-4-x
Gestión de versiones Sakai_2-4-x SVN Se hace el merge de Sakai_2-4-x a upv_2-4-x de desarrollo Revisión  Copia inicial de la Revisión  Se genera parche para Sakai_2-4-x upv_2-4-x Puesto de trabajo

12 Gestión de versiones Problemas: Documentación
Proceso complejo tendente a errores Documentación Cada cambio se registraba en un documento de word Las actualizaciones se marcan en el documento

13 Y llegó el momento de migrar…
Empezamos migrando los contenidos de bbdd a sistema de ficheros Seguimos con la migración de Melete Y empezamos a preparar la del resto de Sakai CONTENT_RESOURCE RESOURCE_ID RESOURCE_UUID IN_COLLECTION FILE_PATH XML CONTENT_RESOURCE_BODY_BINARY RESOURCE_ID BODY

14 Preparando la migración (bbdd)
Creamos una copia de la bbdd que teníamos en explotación (2.4.x) Pasamos los scripts de migración a esta copia 2.4 a 2.5 2.5 a 2.6 2.6 Migración 2.4 Explotación 2.5 a 2.6 2.4 a 2.5

15 Preparando la migración (código)
Revisamos el documento de word con el registro de cambio y creamos un excel para: Comprobar los cambios que había que volver a hacer. Crear un JIRA si el cambio estaba pendiente en Sakai (o actualizarlo). Estimar las horas empleadas en los cambios PARA LA NUEVA VERSIÓN.

16 Preparando la migración (código)
Problemas: Dificultad para reproducir algunos cambios No nos acordábamos del tiempo que empleamos y la estimación se hizo “a ojo”. Es un proceso manual, con muchos cambios afectando a varias revisiones -> difícil seguimiento y muy fácil equivocarse. Solución: intentar ser lo más riguroso posible.

17 Preparando la migración (código)
Había que decidir si dejábamos el código en un repositorio público (msub) o seguíamos con una estructura como la de la 2.4.x VENTAJAS INCONVENIENTES Nos evitamos labores de mantenimiento Seguridad Es más sencillo aplicar parches y actualizaciones Problemas legales Cualquiera puede contribuir

18 Preparando la migración (código)
No podíamos parar mientras tomábamos la decisión. Copia local de la 2.6.x para aplicar los cambios de la Excel (nos repartimos las herramientas). Los parches de cada herramienta y se aplicaron a una versión parcheada de la 2.6.x “común para todos” (mi servidor de desarrollo). /sakai_2-6-x 1. Copia local de la 2.6.x 2. Nos repartimos las herramientas 3. Parches locales 4. Parche completo /upv_2-6-x

19 Preparando la migración (código)
El cambio era registrado en una Excel y en GREGAL Cuando nos decidimos por el svn público, copiamos una 2.6.x y aplicamos el parche completo. Como había cambios en el kernel, hicimos lo mismo. /sakai_2-6-x msub/es.upv/PoliformaT

20 Preparando la migración (pruebas)
Cada desarrollador era responsable de comprobar el funcionamiento del cambio antes de subirlo al repositorio. Paralelamente, dos becarios probaban las herramienta una por una. También contamos con la ayuda del CAU.

21 Preparando la migración (pruebas)
Errores cometidos: Falta de definición de una batería de pruebas potente: SE quedan algunas funcionalidades sin probar Difícil comprobar (y comparar) los “efectos colaterales”. Consecuencias: Roces con el CAU por no tener claras las responsabilidades de cada uno. Fallos en el paso a explotación

22 Preparando la migración (pruebas)
Soluciones en marcha: Para cada herramienta, estamos haciendo una batería de pruebas en la que se especifica qué, cómo y el resultado de cada prueba. Baterías automatizadas con Jmeter (pruebas de carga)

23 Pero, lo conseguimos…

24 …aunque tenemos problemas pendientes
Carga excesiva de los servidores Problemas de prestaciones con Samigo

25 Lecciones aprendidas Importancia de tener bien registrados los cambios “upv” realizados. Fundamental ser riguroso en las pruebas Recomendable estar atento las listas de correo de Sakai. ¡Necesitamos más recursos!

26 Y, además, nuevos desarrollos
Chat avanzado Integración con motores Acceso a vistas desde aplicaciones externas Integración con Adobe Connect

27 Preguntas, dudas, sugerencias