1 / 25

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. Migración de Sakai 2.4.x a Sakai 2.6.x Lecciones aprendidas. Érase una vez…. En el curso 2006-2007 pusimos en explotación Sakai 2.1.2 con el nombre de PoliformaT.

cybil
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dr. David Roldán Martínez Analista del ASIC Universidad Politécnica de Valencia http://moodle-vs-sakai.blogspot.com Migración de Sakai 2.4.x a Sakai 2.6.xLecciones aprendidas

  2. É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.

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

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

  5. ¿Qué será, será…? • Futuro: ¿Sakai 3.0?

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

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

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

  9. Gestión de versiones SVN Sakai_2-4-x upv_2-4-x 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 Puesto de trabajo

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

  11. 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 CONTENT_RESOURCE_BODY_BINARY RESOURCE_ID RESOURCE_ID RESOURCE_UUID BODY IN_COLLECTION FILE_PATH XML

  12. 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 Migración Explotación 2.4 2.6 2.4 a 2.5 2.5 a 2.6

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

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

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

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

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

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

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

  20. 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)

  21. Pero, lo conseguimos…

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

  23. 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!

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

More Related