Migracin de Sakai 2 4 x a Sakai

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 http: //moodle-vs-sakai. blogspot. com

Érase una vez… En el curso 2006 -2007 pusimos en explotación Sakai 2. 1. 2 con el nombre de Poliforma. T. n Junto con la 2. 1. 2, hicimos algunos desarrollos propios. n

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

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

¿Qué será, será…? n Futuro: ¿Sakai 3. 0?

Gestión de cursos – Generación y sincronización MATRÍCULA GENERACIÓN COURSE MANAGEMENT CONFIGURACIÓN SINCRONIZACIÓN R E P O S I T O R I O

Gestión de cursos - Implementación 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. ¨

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

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

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

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

Preparando la migración (bbdd) Creamos una copia de la bbdd que teníamos en explotación (2. 4. x) n Pasamos los scripts de migración a esta copia n 2. 4 a 2. 5 ¨ 2. 5 a 2. 6 ¨ Migración Explotación 2. 6 2. 4 a 2. 6 2. 5

Preparando la migración (código) n 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. ¨

Preparando la migración (código) n 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. ¨ n Solución: intentar ser lo más riguroso posible.

Preparando la migración (código) n 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 • Nos evitamos labores de mantenimiento • Es más sencillo aplicar parches y actualizaciones • Cualquiera puede contribuir INCONVENIENTES • Seguridad • Problemas legales

Preparando la migración (código) No podíamos parar mientras tomábamos la decisión. n Copia local de la 2. 6. x para aplicar los cambios de la Excel (nos repartimos las herramientas). n 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). n /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

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

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

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

Preparando la migración (pruebas) n 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) ¨

Pero, lo conseguimos…

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

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

Preguntas, dudas, sugerencias darolmar@upvnet. upv. es http: //moodle-vs-sakai. blogspot. com