migración de sakai 2.4.x a sakai 2.6.x lecciones aprendidas dr. david roldán martínez analista...
Post on 16-Feb-2015
5 Views
Preview:
TRANSCRIPT
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
top related