Gestión de liberaciones, despliegue y entregas
La realización de releases vendrá marcada por el calendario propio de entregas de la asignatura. El equipo se encargará de desarrollar sus cambios hasta que la fecha del milestone sea cercana y, entonces, el coordinador requerirá a los integrantes la puesta en común de cambios en la rama develop. Acto seguido, el coordinador podrá decidir si fusionar los cambios con aquellos presentes en el repositorio compartido con el resto de subsistemas. Este paso garantiza la puesta al día de las demás partes de Decide-Ganimedes, pero indirectamente podría introducir conflictos indeseados dada la cercanía del milestone. Es por ello por lo que el coordinador valorará los mismos y procederá de la mejor forma que considere.
Para asegurar que el código que se incluye es correcto y completo en cuanto a funcionalidad, se usará la rama master para la generación de los archivos. Recordemos que esta rama contiene todo el código potencialmente desplegable que ha superado las pruebas tanto específicas como de integración. Es por ello que el siguiente paso a realizar sea volcar el contenido de la rama develop sobre esta para actualizarla con los nuevos cambios.
Las liberaciones están automatizadas usando aprovechando para ello el sistema de integración continua. Recordemos que cuando el CI detecta un cambio sobre cualquier rama este lanza los tests para verificar la corrección de los mismos.
En concreto, para la automatización usando Travis CI, se hace uso de las Variables de Entorno que este nos brinda, como podemos ver en la Figura 1. Estas son sólo unos parámetros con ciertos valores que intervendrán en la ejecución del fichero de configuración .travis.yml, pudiendo modificar su flujo. Cabe destacar que todos los grupos de Decide-Ganimedes utilizamos las mismas variables ya que establecimos un proceso de gestión de liberaciones común.
Figura 1: Variables de Entorno en Travis CI
La lista de variables y sus funcionalidades son las siguientes:
- DEPLOY_TRAVIS: Booleano (1 ó 0). Indica si queremos que Travis CI realice la release tras comprobar los tests.
- EMAIL_TRAVIS: String. Email de la persona que aparece como autor del despliegue.
- MILESTONE_TRAVIS: Integer. Indica el número de milestone actual. Se usa para generar el nombre de la release tras como se indica en Versionado e identificación.
- NOMBRE_ZIP: String. Nombre del fichero generado con los datos comprimidos de la rama.
- RAMA_TRAVIS: String. Travis CI únicamente realiza el despliegue si el nombre de la rama actual coincide con esta variable.
- TOKEN_TRAVIS: String. Token de autenticación necesario para realizar cambios sobre GitHub
- USER_TRAVIS: String. Usuario de la persona que aparece como autor del despliegue.
Si los parámetros son los correctos y previa verificación de los tests, el sistema procede automáticamente a generar un archivo comprimido con los ficheros que se encuentran en la rama especificada por el coordinador en la variable RAMA_TRAVIS. Este archivo, con el resto de la configuración, es usado para generar la release y publicarla en GitHub.
Siguiendo el esquema del protocolo de liberaciones, el servidor de aplicaciones está también automatizado de tal manera que, de cumplirse los requisitos necesarios, despliegue los cambios que existen en la rama master.
Tras la ejecución de los test de comprobación del sistema de integración continua, Heroku comprueba una serie de parámetros que intervienen en el fichero Procfile y settings.py del repositorio. Estos parámetros son:
- HEROKU: Booleano (1 ó 0). Indica si queremos que el servidor de aplicaciones despliegue los cambios que están en la rama.
- REPO_NAME: String. Nombre de la URL del subsistema a desplegar.
Cabe destacar que todos los grupos de Decide-Ganimedes utilizamos los mismos parámetros ya que establecimos un proceso de despliegue en común.
Si los parámetros son los correctos y previa verificación de los tests, el sistema procede automáticamente al despliegue de la aplicación definida por los ficheros que se encuentran en la rama especificada, que en nuestro caso es la master.
Cada módulo perteneciente al equipo de Decide-Ganímedes comenzó con una estrategia de nombrado particular. Tras una reunión entre los coordinadores, se llegó al acuerdo e establecer una política de nombrado común que permitiera así facilitar la identificación de los entregables. Concretamente se acordó el uso de una estrategia de nombrado consistente en secuencias y la importancia del cambio. Para ello, se deberá seguir el siguiente formato vX.0.Z-YYYY, donde:
- X denota el milestone al que el entregable hace referencia. Por norma general, en un nuevo milestone es muy posible que los cambios sean sustanciales en funcionalidad.
- Z denota cambios de carácter medio o menor en funcionalidad.
- YYYY hace referencia al año actual.
Figura 2: Releases en GitHub
Las releases se pondrán bajo el sistema de control de versiones que ofrece GitHub, y que permite tener un directorio con el histórico de las mismas y su código asociado. Por su parte, la versión desplegada en la web y que actualmente se encuentra en ejecución corresponde con la más reciente de las releases que aparecen en el listado de la Figura 2. Se puede acceder a él mediante el siguiente enlace.
Debido a las condiciones de licencia del proyecto heredado, se ha decidido continuar con la misma licencia. En concreto, hablamos de la GNU Affero General Public License v3.0, que garantiza que cualquier modificación aplicada al código deba ser publicada y relicenciada usando la misma.
Con respecto a los componentes que hemos usado para el desarrollo de ciertas funcionalidades en nuestro módulo (como son Chart.js para los gráficos y MaterializeCSS para el estilado general) están licenciados bajo MIT. Esta licencia es de carácter permisivo y nos permite la transformación a la licencia AGPLv3 sin presentar ningún inconveniente.