Project

General

Profile

Propuesta de actualización de GONG

Situacion y propuesta

GONG esta basado en las siguientes tecnologias que necesitan ser actualizadas

  • ruby = 1.9.3
  • javascript usa la gema “prototype-rails” (3.2.1)
  • rails = 3.2.22.5

En el siguiente documento presentamos una propeusta de actalizacion de las diferentes versiones sobre las que se basa GONG. El objetivo final es pasar a:

  • ruby = 2.2.4
  • javascript = No usar ninguna gema ni libreria especifica
  • rails = 5.0

Fase 1. Hacer los tests con Selenium IDE.

Actualmente no hay test lo cual significa que no podemos con seguridad hacer los upgrades necesarios.

El objetivo es hacer una cantidad suficiente de tests como para poder estar seguro cuando se hace el upgrade (ver appartado “Proposición de estructuración de los test Selenium IDE”).

Se seguirían los siguientes pasos:

  1. Construir un mapa funcional de gong.
  2. Enumerar los test cases de manera interdependiente los unos de los otros (un test case presupondría el estado creado por los test cases anterior). Por ejemplo:
    • 001_crear_usuario_coordinador1
    • 002_crear_proyecto_test1
    • 003_asignar_proyecto_test1_a_coordinador.

El tercero test case depende de los test cases anteriores.

Evaluación: El problema en esta construcción es que habría que rular la test suite hasta el punto de inserción del test_case sobre lo cual se trabaja. Otra solución sería partir esta test suite en varias test suites que podrían compartir test cases. El problema aquí es la dificultad de mantener; la modificación de un test case puede tener consecuencia sobre varias test suites.
Se propone de construir la test suite monolítica y ver con la practica si se divide o no.

Posteriormente será necesario desarrollar los bugfixes y las nuevas funcionalidad creando un test case por lo menos para cada caso que refleje los cambios introducido o que reproduce el contexto de la incidencia y dé cuenta de su arreglo.

Fase 2. Hacer los upgrades de Ruby, JavaScript, Rails.

Para los upgrades se creará un branch, desde el que se irán haciendo "merge's" al trunk del sistema. Detallamos a continuacion cada paso de actualizacion de GONG, junto a los merges que implican.

Actualización Javascript

Reemplazar el uso de la framework “prototype” por javascript.

Pasos para la migración de JavaScript (sustitución de prototype)

Primer MERGE del branch en el trunk

Actualizacion Ruby

Pasar de la versión actual (1.9.3) a la versión ruby-2.2.4.

  • Cambios necesarios para que funcione todo el sistema.
  • Unificar la forma de identación (tabulaciones y/o espaciones)

Segundo MERGE del branch en el trunk

  • Pasar de la notación anterior ){:key => “llave”}) a la nueva en los hashes ({key: “llave”}).
  • Emplear los guiones dobles solamente en los views, templates y cuando hay interpolación (“esa variable es #{variable}”).

Tercer MERGE del branch en el trunk

Ver la Guia de estilo para mas detalles

Actualización Rails

Pasar las versiones hasta la versión actual (5.0).

  • Cambios necesarios para que funcione todo el sistema.
  • Emplear el operator ternario (“ variable = condicion == true ? 'valor1' : 'valor2' ” solamente en los views.

Cuarto MERGE del branch en el trunk

Otras posibles propuestas de mejora del codigo serían:

  • Acortar dividiendo los metodos.
  • Reducir los modelos.

Ver la Guia de estilo para mas detalles

Fase 3. Introducir el testing en la practica de desarrollo.

Actualmente no se tiene un modelo claro de cual será la mejor forma de introducir testing en la metodologia de desarrollo de GONG, pero se barajan las siguientes ideas:

  • Evaluar el introducir practicas de TDD (Testing Driven Development) en la codificación.
  • Se conservaría Selenium IDE (plugin firefox) para los test de comportamiento.
  • Redacción de tickets basados en escenarios.

Calendario para las fases.

  • Fase 1: Febrero/Marzo
  • Fase 2: Marzo/Abril

Pendiente de un detalle mayor

Financiado por:

Desarrollado por:
Software libre forjado en: