Acta Fundacional - pringa-uvlhub/uvlhub GitHub Wiki

Universidad de Sevilla

Escuela Técnica Superior de Ingeniería Informática

Pringa-Hub

Grado en Ingeniería Informática – Ingeniería del Software
Evolución y Gestión de la Configuración
Curso 2024 – 2025

Participantes

Nombre Grupo
Miguel Palomo Garcia pringa-hub-1
Luis Javier Periáñez Franco pringa-hub-1
Javier García Rodriguez pringa-hub-1
Jesús Fernández Rodríguez pringa-hub-1
Miguel González Ortiz pringa-hub-1
Javier Nieto Vicioso pringa-hub-2
Pablo Díaz Ordoñez pringa-hub-2
Manuel Palacios Pineda pringa-hub-2
Maria Escalante Ramos pringa-hub-2
Francisco Mateos Villarejo pringa-hub-2
Daniel Diañez Suarez pringa-hub-2

Índice

  1. Gestión de conflictos
  2. Política de mensajes de commit
  3. Política de ramificación
  4. Política de issues/incidencias
  5. Gestión del código fuente
  6. Pruebas automáticas
  7. Política de pull requests

1. Gestión de conflictos

Conflicto Acción por realizar
Ausencia no justificada en reuniones Hablar directamente con el miembro para entender la situación y buscar soluciones. Si persiste, informar al profesor.
Retraso en la entrega de work items Redistribuir temporalmente el trabajo y ofrecer apoyo. Si el problema continúa, comentar la situación con el profesor.
Incumplimiento de la política de commits o ramas Corregir el error junto al miembro afectado, explicar la política y asegurar comprensión.
Falta de respuesta o comunicación Contactar personalmente al miembro. Si no mejora, avisar al profesor.
Desinterés o falta de compromiso Reasignar tareas y proporcionar orientación. Consultar al profesor si es necesario.
Conflictos de opinión Realizar una reunión con el equipo. Si no se resuelve, consultar al profesor.
Diferencias de habilidades o interés Apoyar y motivar a los miembros menos experimentados, fomentando la colaboración.
Comportamiento irrespetuoso Hablar inmediatamente con el miembro, aclarar la situación en equipo y mediar.

2. Política de mensajes de commit

  • Buenas prácticas:

    • Contenido en inglés
    • Mensajes descriptivos, atómicos, cohesivos y coherentes.
    • Título limitado a 50 caracteres (excluyendo el 'tipo').

  • Estructura de un commit:

  • type puede ser:

    • Feat: Nuevas funcionalidades o cambios menores.
    • Test: Pruebas en la aplicación.
    • Fix: Solución de errores.
    • Config: Cambios en la configuracion del proyecto.
    • Docs: Adición o actualización de documentación.
    • Migrations: Para los commits automáticos en develop relacionados con las migraciones.

  • Cuerpo del mensaje: Párrafo explicativo siguiendo las reglas descritas.

3. Política de ramificación

  • Ramas principales:

  • main o master: Rama principal lista para producción.

  • develop: Última versión en desarrollo para la próxima release.

  • Ramas auxiliares:

  • feature: Para nuevas funcionalidades (creadas a partir de develop).

  • fix: Para corregir bugs (creadas a partir de develop).

  • configuration: Para implementar cambios en la configuración del repositorio (creadas a partir de develop).

  • test: Para implementar las pruebas asociadas a cada WI (creadas a partir de develop).

4. Política de issues/incidencias

Antes de comenzar a desarrollar cualquier característica de la aplicación, se debe crear una issue correspondiente. Estas podrán ser creadas por cualquier miembro del equipo, idealmente al inicio del milestone, pero se podrán añadir posteriormente también. Por cada característica/arreglo a implementar se creará una issue asignada al miembro/s del equipo que la vaya a desarrollar.

  • Tipos de issues:
  • WI - Feature: Funcionalidad asociada al WI.
  • WI - Test: Testeo de las funciones del WI.
  • FEAT: Incorporación de nuevas funcionalidades o elementos visuales en la aplicación, y sus tests asociados.
  • BUG: Problemas o bugs que afectan el funcionamiento normal de aplicación.
  • CONFIG: Para configuraciones del repositorio.
  • DOCS: Para temas relacionados con la documentación del proyecto.

La gestión se llevará a cabo mediante el tablón de tareas de GitHub, donde cada issue pasará por 4 estados:

  • Estados de las issues:
  1. ToDo: Tareas identificadas pero no iniciadas.
  2. In Progress: Tareas en desarrollo.
  3. In Review: Tareas resueltas listas para revisión.
  4. Done: Tareas completadas y verificadas.

5. Gestión del código fuente

  • Herramientas:
  • Repositorio: GitHub.
  • Control de versiones: Git (integrado en Visual Studio Code).

6. Pruebas automáticas

  • Herramientas y tipos de pruebas:
  • Locust: Pruebas de rendimiento.
  • Selenium IDE: Pruebas de interfaz de usuario.
  • Rosemary: Pruebas unitarias.
  • Coverage Rosemary: Medición de cobertura de pruebas.

7. Política de pull requests

Se han definido varios tipos de pull requests para el desarrollo de este proyecto:

El formato seguido es del tipo type/<Descripción>, siendo type los tipos definidos a continuación:

  • Feature: Para el desarrollo de la funcionalidad de los working items.
  • Fix: Para corrección de bugs aparecidos durante el desarrollo del sistema.
  • Config: Destinadas a la configuración del proyecto, como workflows.
  • Test: Para el desarrollo de los tests asociados a cada work item.
  • Release: Destinada a crear la release del proyecto, de develop a main.

Pringa-Hub - Curso 2024/2025