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

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

Dr. David Roldán MartínezAnalista del ASICUniversidad Politécnica de Valenciahttp://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 PoliformaT.

Junto con la 2.1.2, hicimos algunos desarrollos propios.

Érase una vez…

En el curso 2007-2008 migramos a la versión 2-4-x.

Érase una vez..

En el curso 2009-2010 acabamos de migrar a la 2-6-x.

¿Qué será, será…?

Futuro: ¿Sakai 3.0?

REPOSITORIO

Gestión de cursos – Generación y sincronización

MATRÍCULA

SINCRONIZACIÓN

COURSE MANAGEMENT

CONFIGURACIÓN

GENERACIÓN

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.

Control de actualizaciones

SVN

SERVIDOR INTERMEDIO

SERVIDORES DE EXPLOTACIÓN

FLAG DE DESPLIEGUE

Puesto de trabajo

Gestión de versiones

SVN Sakai_2-4-xRevisión

upv_2-4-x

Se genera parche para Sakai_2-4-x

Copia inicial de la Revisión

Se hace el merge de Sakai_2-4-x a upv_2-4-x de desarrollo

Gestión de versiones

Problemas: 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

Seguimos con la migración de Melete Y empezamos a preparar la del resto de Sakai

CONTENT_RESOURCERESOURCE_ID RESOURCE_UUID IN_COLLECTION FILE_PATH XML

CONTENT_RESOURCE_BODY_BINARYRESOURCE_ID BODY

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.4

Explotación

2.6

Migración

2.4 a 2.52.5 a 2.6

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.

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.

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

• Es más sencillo aplicar parches y actualizaciones

• Cualquiera puede contribuir

• Seguridad• Problemas legales

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 herramientas3.

Parches locales

/upv_2-6-x4. Parche completo

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.

msub/es.upv/PoliformaT

/sakai_2-6-x

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.

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

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)

Pero, lo conseguimos…

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

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!

Preguntas, dudas, sugerencias

darolmar@upvnet.upv.eshttp://moodle-vs-sakai.blogspot.com