• Grupo 3
• Curso escolar: 2024/2025
• Asignatura: Evolución y gestión de la configuración

• Indicadores del proyecto
• Integración con otros equipos
• Resumen ejecutivo
• Descripción del sistema
• Visión global del proceso de desarrollo
• Entorno de desarrollo
• Ejercicio de propuesta de cambio
• Conclusiones y trabajo futuro

La tabla contiene la información de cada miembro del proyecto y el total de la siguiente forma:

• Horas: número de horas empleadas en el proyecto
• Commits: solo contar los commits hechos por miembros del equipo, no lo commits previos
• LoC (líneas de código): solo contar las líneas producidas por el equipo y no las que ya existían o las que se producen al incluir código de terceros
• Test: solo contar los test realizados por el equipo nuevos
• Issues: solo contar las issues gestionadas dentro del proyecto y que hayan sido gestionadas por el equipo
• Work Item: principal WI del que se ha hecho cargo el miembro del proyecto

Equipos con los que se ha integrado y los motivos por lo que lo ha hecho y lugar en el que se ha dado la integración:

• salmorejo-hub-2: breve descripción de la integración. A continuación:

Configuramos workflows personalizados de GitHub para validar pruebas y adaptarse a nuestro sistema. Contamos con un workflow de integración continua que sincroniza los cambios de la rama main del repositorio hijo con la rama develop del repositorio padre. En caso de conflictos, se notifica al usuario y se genera una pull request en su lugar.

En la rama develop del repositorio padre se integran los cambios de ambos equipos, resolviendo problemas y conflictos a medida que surgen. Una vez que todas las pruebas pasan y las funcionalidades están implementadas e integradas, los cambios se promueven de develop a main.

La rama main representa el entorno de producción, por lo que todo debe estar completamente funcional. Además, se realiza una sincronización con los forks hijos para asegurarse de que contengan los cambios de la rama main del repositorio padre.

Nuestro proyecto tiene como objetivo extender las funcionalidades de un sistema de gestión de datasets existente (repositorio base) para la asignatura de Evolución y Gestión de la Configuración (EGC) durante el curso 2024-25. A lo largo del proyecto, hemos ido implementando nuevas funcionalidades clave, incluyendo:

• Recordar contraseña (feat/WI1-remember-my-password).
• Generación de tokens API (feat/WI2-generate-api-token).
• Descarga de todos los datasets (feat/WI3-download-all-datasets).
• CLI avanzada (feat/WI4-rosemary-cli).
• Filtrado avanzado (feat/WI5-advanced-filtering).
• Bot de Discord (feat/WI6-discord-bot).
• Validación de registro (feat/WI7-sign-up-validation).
• Fakenodo

Estas funcionalidades se han desarrollado intentando seguir buenas prácticas de gestión de cambio e incidencias, gestión del código, integración continua, pruebas automatizadas y despliegue. Hemos establecido y seguido políticas de commits, ramas, pull request, issues, integración y versionado.

El sistema desarrollado se centra en la gestión de datasets, ofreciendo nuevas funcionalidades que mejoran la experiencia del usuario y la eficiencia operativa. Entre las principales funcionalidades destacan:

• Inicio de sesión con recordatorio de contraseña: Permite a los usuarios recuperar sus credenciales de manera sencilla.
• Generación de tokens API: Facilita el acceso seguro a las APIs del sistema.
• Descarga masiva de datasets: Brinda la posibilidad de descargar múltiples datasets en un solo paso.
• CLI avanzada: Rosemary CLI permite a los usuarios interactuar con el sistema desde la línea de comandos.
• Filtrado avanzado: Mejora la capacidad de búsqueda y análisis de datasets.
• Bot de Discord: Ofrece integración con Discord para notificaciones y acciones automatizadas.
• Validación de registro: Refuerza la seguridad y consistencia en los datos de usuarios registrados.

El sistema sigue una arquitectura modular que combina varias capas y subsistemas:

1. Capa de backend: Implementada en Python usando Flask, proporciona APIs RESTful y maneja la lógica de negocio.
2. Base de datos: Utiliza MariaDB para el almacenamiento de datos.
3. Integraciones externas:
   • Zenodo API: Para la gestión y carga de datasets.
   • Flamapy: Para análisis y modelado de variabilidad.
   • Discord Bot: Para acceder a las funcionalidades de uvlhub desde un bot.
4. Rosemary CLI: Una herramienta de línea de comandos que interactúa con las APIs del sistema.

El sistema se puede instalar y desplegar manualmente en local, en remoto en render y mediante Docker, lo que garantiza consistencia y facilidad de uso en diferentes entornos.

El proyecto sigue una estructura modular detallada en la documentación de arquitectura, que organiza los componentes principales de manera clara y escalable.

El equipo trabajó en los siguientes work items seleccionados:

• feat/WI1-remember-my-password: Implementación del recordatorio de contraseña.
• feat/WI2-generate-api-token: Generación de tokens API para seguridad.
• feat/WI3-download-all-datasets: Descarga masiva de datasets.
• feat/WI4-rosemary-cli: Desarrollo de una CLI avanzada para interacciones rápidas.
• feat/WI5-advanced-filtering: Mejoras en el filtrado y análisis de datos.
• feat/WI6-discord-bot: Integración con Discord para automatizaciones.
• feat/WI7-sign-up-validation: Validación estricta de los datos de registro de usuarios.

Como ya hemos desarrollado antes, nuestro proyecto tiene como objetivo extender las funcionalidades de un sistema de gestión de datasets existente (repositorio base). A través de este desarrollo, implementamos nuevas funcionalidades organizadas como work items, garantizando el cumplimiento de buenas prácticas en la gestión del cambio, manejo de incidencias, gestión de código, construcción e integración continua, pruebas automatizadas y despliegue.

Utilizamos Zenhub integrado con GitHub para organizar el flujo de trabajo, siguiendo un enfoque basado en un tablero Kanban. Las issues las clasificamos y gestionamos según la "Política de Issues", garantizando una estructura clara para identificar prioridades y estados. Los estados principales del tablero fueron:

• ToDo: Tareas programadas pero aún no iniciadas.
• In Progress: Tareas en desarrollo.
• In Review: Tareas en proceso de prueba y revisión.
• Closed: Tareas finalizadas y issues cerradas.

Además, las issues estaban etiquetadas con prioridades (#priority:critical, #priority:medium, #priority:low) y categorías (#incidence, #documentation, #enhancement, entre otras).

Se siguió una estrategia basada en Gitflow, con una estricta política de ramas que promovió claridad y organización. Los nombres de las ramas seguían la estructura:

<tipo>/<WI[1-6]>-<nombre-del-WI>

• feat: Para añadir nuevas funcionalidades.
• fix: Para solucionar errores.
• docs: Para documentación.

Ejemplos:

• feat/WI1-remember-my-password
• fix/WI2-generate-api-token

El versionado del repositorio principal siguió el formato A.B.C:

• A: Incrementa al completar un work item.
• B: Incrementa con nueva funcionalidad que no completa un work item.
• C: Incrementa al corregir errores.

Las releases se realizan al finalizar work items o solucionar bugs críticos.

Seguimos conventional commits y además usamos un workflow que compruebe la validez del mensaje de commit.

El proyecto incluyó pruebas automatizadas para garantizar la calidad del software:

• Pruebas unitarias
• Pruebas de cobertura
• Pruebas de interfaz utilizando Selenium
• Pruebas de carga con Locust

Estas pruebas estaban integradas en los workflows de GitHub Actions, asegurando que cada cambio propuesto pasara por validaciones automáticas antes de ser fusionado.

• Editor: Visual Studio Code.
• Automatización: Workflows de GitHub Actions.
• Análisis de calidad: Codacy.
• Despliegue: Render.
• Comunicación: WhatsApp y Discord.

Las decisiones importantes fueron registradas en actas de reuniones (disponible en el Diario de Equipo), asegurando claridad y consenso en el equipo.

Además, nuestro documento de políticas de salmorejo-hub, está disponible en la carpeta docs del repositorio o también puedes acceder a través de este enlace

El entorno de desarrollo del proyecto fue diseñado para facilitar el trabajo colaborativo y garantizar una configuración reproducible para todos los miembros del equipo.

El equipo utilizó Linux (Ubuntu y Fedora) como sistemas operativos principales. Además, se configuraron entornos virtuales de Python para aislar las dependencias del proyecto.

El proyecto empleó una variedad de herramientas y bibliotecas, incluyendo:

• Lenguaje de programación: Python.
• Framework principal: Flask.
• Base de datos: MariaDB.
• Bibliotecas específicas añadidas a las que ya existían (todas las dependencias y sus versiones están detalladas en el archivo requirements.txt).

Se ofrecen dos opciones para instalar el sistema:

1. Instalación manual: Los pasos detallados están disponibles en la documentación oficial.
2. Uso de Docker: Hay un Dockerfile para una configuración rápida y estos son los pasos a seguir

• Configuración de variables de entorno necesarias para la conexión a la base de datos y servicios externos

• Creación de un entorno virtual con Python

• Configuración de la base de datos y migraciones

• Editor: Visual Studio Code con extensiones para Python y Lint.
• Docker: Uso de Docker para añadir otras alternativas de despliegue.

Versión de Python

Se recomienda utilizar Python versión 3.12 o superior.

Soporte solo para Ubuntu

Este tutorial está diseñado para su uso en Ubuntu 22.04 LTS o superior.

sudo apt update -y
sudo apt upgrade -y

Para clonar el repositorio original utilizando HTTPS:

git clone https://github.com/EGCETSII/uvlhub.git
cd uvlhub

Necesitamos una base de datos relacional para nuestra aplicación. Utilizaremos MariaDB.

MariaDB está disponible en los repositorios oficiales de Ubuntu, por lo que puedes instalarlo fácilmente con apt:

sudo apt install mariadb-server -y

Inicia el servicio de MariaDB para trabajar con la base de datos:

sudo systemctl start mariadb

Después de instalar MariaDB, es recomendable ejecutar el script de seguridad para realizar configuraciones iniciales:

sudo mysql_secure_installation

Durante la ejecución, ingresa los siguientes valores:

- Enter current password for root (enter for none): (presiona Enter)
- Switch to unix_socket authentication [Y/n]: `y`
- Change the root password? [Y/n]: `y`
  - New password: `uvlhubdb_root_password`
  - Re-enter new password: `uvlhubdb_root_password`
- Remove anonymous users? [Y/n]: `y`
- Disallow root login remotely? [Y/n]: `y`
- Remove test database and access to it? [Y/n]: `y`
- Reload privilege tables now? [Y/n]: `y`

Accede a la consola de comandos de MariaDB:

sudo mysql -u root -p

Introduce uvlhubdb_root_password como contraseña de root y luego ejecuta:

CREATE DATABASE uvlhubdb;
CREATE DATABASE uvlhubdb_test;
CREATE USER 'uvlhubdb_user'@'localhost' IDENTIFIED BY 'uvlhubdb_password';
GRANT ALL PRIVILEGES ON uvlhubdb.* TO 'uvlhubdb_user'@'localhost';
GRANT ALL PRIVILEGES ON uvlhubdb_test.* TO 'uvlhubdb_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Copia el archivo .env en el directorio raíz del proyecto:

cp .env.local.example .env

El módulo webhook está diseñado para entornos de preproducción que utilizan Docker. Para evitar problemas en otros entornos, añade webhook al archivo .moduleignore en el directorio raíz del proyecto:

echo "webhook" >> .moduleignore

Es recomendable utilizar un entorno virtual para aislar las dependencias de la aplicación:

sudo apt install python3.12-venv
python3.12 -m venv venv
source venv/bin/activate

*Nota: si quieres salir del entorno virtual:

deactivate

Con el entorno virtual activado, instala las dependencias listadas en requirements.txt:

pip install --upgrade pip
pip install -r requirements.txt

Para facilitar el desarrollo, instala las dependencias en modo editable:

pip install -e ./

Para comprobar que Rosemary se ha instalado correctamente, usa este comando:

rosemary

Crea las tablas necesarias en la base de datos:

flask db upgrade

Para añadir datos de prueba:

rosemary db:seed

Inicia el servidor de desarrollo de Flask:

flask run --host=0.0.0.0 --reload --debug

La aplicación estará disponible en http://localhost:5000/.

Para más detalles, se puede consultar la wiki del repositorio y la documentación oficial.

Caso práctico: Modificar el nombre del commando de discord token_config a token_config_on_dm.

1. Crear una tarea en la sección Issues del repositorio correspondiente.
2. Completar la plantilla asociada con la descripción, pasos e información necesaria para realizar y documentar la tarea.
3. Asignarle etiquetas de state: to-do, priority:${prioridad}, y otras opcionales según el tipo que sea. También asignar a alguien del equipo para completarla.

4. Cuando la persona encargada se ponga a hacer la tarea, debe cambiar la etiqueta de state: to-do a state: in-progress. También deberá crear una nueva rama para la funcionalidad según el formato acordado.
5. Después debe implementar la funcionalidad solicitada.
6. Cuando termine, deberá subir los cambios y notificar al responsable de pruebas de que la funcionalidad está lista.

7. El responsable de pruebas deberá implementar las pruebas asociadas a la funcionalidad. Pueden ser pruebas unitarias, de integración, de interfaz...
8. El tester comprueba que funciona y que las pruebas pasan.
9. El tester notifica a la persona encargada de revisar y cambia la etiqueta de state: in-progress a state: in-review

10. La persona encargada de revisar es notificada y comprueba minuciosamente que el código y las pruebas son correctos.
11. El reviewer abre una pull request desde esa rama a main
12. Comprueba que los workflows se ejcutan correctamente. Si hay conflictos los soluciona o lo notifica al equipo de desarrolladores. Si no hay conflictos, acepta la pull request
13. También revisa la documentación técnica y la actualiza en caso de ser necesario.

14. Otro miembro del equipo estará pendiente y una vez los cambios lleguen a main del hijo, comprobará si el workflow de ci funciona, es decir, si los cambios se han subido a develop del padre.
15. Si hay problemas / conflictos, los soluciona o lo notifica al equipo. También puede crear / aceptar / rechazar una pull request manual si no funciona.
16. También revisa la documentación técnica y la actualiza en caso de ser necesario.

17. Finalmente, otro miembro del equipo actualiza main del padre con los cambios probados y revisados de develop.
18. Revisar que todo funciones correctamente y despliega los cambios. Además debe asegurarse que la aplicación funciona y que el cambio implementado se ha efectuado correctamente en la aplicación

Este proyecto ha permitido al equipo adquirir experiencia en herramientas avanzadas y mejorar habilidades de trabajo colaborativo. Para el futuro, se propone:

1. Implementar nuevos workflows y automatizaciones.
2. Mejora de la interfaz de usuario con tecnologías modernas.
3. Automatización completa del pipeline de despliegue.
4. Mejorar la integración con el repositorio padre.

Durante el desarrollo, hemos aprendido e intentado aplicar conocimientos de la asignatura avanzados sobre integración continua, gestión del cambio y la configuración, workflows de GitHub, Docker y metodologías colaborativas. También hemos enfrentado y superado desafíos relacionados con la integración de repositorios distintos que eran forks de otro padre, lo cual se convirtió más bien en problemas continuos que en integración continua. Tuvimos que darle muchas vueltas y probar distintas formas de conseguir automatizar los cambios entre repositorios mediante workflows de GitHub. Dio bastantes dolores de cabeza y fue todo un reto. Quizás tener 3 repositorios y usar git flow no fueron buenas decisiones para cumplir el objetivo de la asignatura de integración continua, pero ya que a principio de curso no teníamos conocimeintos suficientes, cuando nos dimos cuenta, ya no quedaba otra opción y tuvimos que tirar para adelante con lo que teníamos y hasta la fecha hemos hecho lo que hemos podido conseguir con lo que tenemos.

Este fallo (pero también aprendizaje) nos ha hecho darnos cuenta de la importancia de mantener estándares definidos en plantillas de issues, pull requests y commits, y, sobre todo, en pensar bien antes de elegir una metodología y tener en cuenta cuál es el verdadero objetivo del proyecto.