Así fue (Muy Probablemente) el Proceso de Producción de Moodle 3.3

1417
How Moodle 3.3 Gets Made: A (Probable) Look Behind The Scenes | Así fue (Muy Probablemente) el Proceso de Producción de Moodle 3.3

Story available in English.

WIRIS

Con el reciente lanzamiento de Moodle 3.3, vale la pena repasar el proceso que tiene lugar cada seis meses en Moodle HQ, la Casa Matriz de Moodle en Perth, Australia. Para construir esta línea de tiempo hemos acudido a la documentación oficial, así como a entrevistas y charlas ofrecidas por miembros del equipo en pasadas conferencias MoodleMoot alrededor del mundo.

La presente descripción no difiere demasiado del ciclo de producción de otros conductos de desarrollo de aplicaciones en otras organizaciones, en particular las que emplean Código Abierto. Existen, no obstante, un par de interesantes diferencias, definidas por la intervención de la comunidad global Moodle, que inciden prácticament en cada etapa.

Esta descripción aplica para lanzamientos de orden mayor o de “primer decimal”, como es el caso de Moodle 3.3, o Moodle 3.2, lanzado en diciembre pasado.

Definición de la Hoja de Ruta

La persona responsable como “Propietario del Producto”, que desde el origen de Moodle ha sido su creador, Martin Dougiamas, establece las líneas de trabajo de la nueva versión.

Dougiamas es reconocido por su permanente contacto con el equipo y la comunidad, a través de los MoodleMoots, los Foros Moodle y apariciones en medios.

Planeación y Desarrollo

La Casa Matriz se divide en dos: equipo Front End, que coordina el diseño y la funcionalidad para el usuario final; y equipo Back End, que coordina las tecnologías y plataformas de apoyo, y la arquitectura de datos. Durante varias semanas, ambos equipos deciden sobre qué funcionalidades van a trabajar, incluyendo nuevas funciones y solución a problemas.

Ambos equipos prestan bastante atención a los errores y sugerencias listados en el sitio tracker.moodle.org, en donde la comunidad reporta e incluso contribuye a resolverlos.

Consultas con la Comunidad

Cuando la nueva versión incluye un nuevo componente que introducirá cambios importantes, líderes de la Casa Matriz toman acciones adicionales para visibilizar los procesos internos y escuchar a la comunidad. Quizás el mejor ejemplo en Moodle 3.2 fue el nuevo tema por defecto “Boost“. Para Moodle 3.3, importantes características, aunque de menor impacto, son la integración con suites de ofimática y el Bloque de Resumen de Curso.

Las ideas y el avance de las nuevas funcionalidades se pueden consultar en los meses previos al lanzamiento, ya sea en los Foros, los sitios de Prototipado, o la Documentación oficial Moodle. Usuarios interesados están invitados a proponer ideas de funcionalidad, tan sencillas como la descripción detallada de un caso de uso.

El ‘Embalaje’

Es la hora de la verdad. En un periodo usualmente de tres semanas, los desarrolladores de la Casa Matriz de Moodle se enfocan a llevar a cabo las líneas de desarrollo acordadas. Cafeína entra, código sale. Aunque es un periodo de trabajo intenso, Moodle ha posibilitado el hábito “80-20”, donde los ingenieros dedican un porcentaje del tiempo a sus projectos personales, con frecuencia Complementos u otro tipo de aportes al LMS. El desarrollo queda registrado en el Sistema de Control de Versión de Código Abierto GitHub, donde la comunidad puede ser testigo de los avances frecuentemente, incluso a diario.

Una vez concluido el “Embalaje” (o en el término original de la metodologia “Sprint“), se decreta una congelación del código. Esto quiere decir que ninguna funcionalidad desarrollada posterior a esta fecha será incluida en la presente versión.

Pruebas de Aseguramiento de la Calidad

El equipo de calidad de Moodle crea una entrada en tracker.moodle.org con el listado de pruebas que la versión de Moodle debe cumplir para considerarse óptima al público. Errores detectados sobre el nuevo desarrollo son solucionados mediante “integración continua”, es decir que son añadidos a la versión tan pronto quedan resueltos. Durante este proceso, varias versiones de prueba Moodle pueden lanzarse, incluso en un mismo día.

Este es quizás el momento más importante para la colaboración por parte de la comunidad, puesto que Moodle deja en manos de esta (es decir, de todos) la realización de la gran mayoría de la pruebas. De otra forma, el cumplimiento de las pruebas le tomaría demasiado al equipo interno. Tanto en Moodle 3.2 como en 3.3 estas pruebas tomaron más de lo esperado, lo que condujo a aplazamientos en ambos casos.

Pruebas en la Versión Candidata

Una vez la versión de Moodle pasa más del 80% de las pruebas de forma exitosa (en Moodle 3.2 y 3.3 la tasa de éxito fue del 100%), una “versión candidata” (release candidate) queda disponible para que desarrolladores y administradores experimentados la desplieguen en contextos reales.

Y es así como en seis meses, una nueva versión de Moodle ve la luz.

Lee el Proceso de Desarrollo de Moodle en la documentación oficial (en inglés).


eThink LogoThis Moodle Governance related post is made possible byeThink Education, a Certified Moodle Partner that provides a fully-managed Moodle experience including implementation, integration, cloud-hosting, and management services. To learn more about eThink, click here.